9 Applied Cryptography Practice

Match the tool to the security goal

Choose a mechanism according to the security goal. Encryption protects confidentiality; a message authentication code (MAC) or digital signature helps detect tampering and authenticate origin; and a certificate binds a public key to an identity under a trust system. A hash alone does not authenticate who created data.

Choose protection for common tasks

For a private customer record that only an authorized service should read, use authenticated encryption, such as AES-GCM, with a securely managed key. Authenticated encryption provides confidentiality and detects tampering. Follow the mode’s nonce requirements: never reuse a GCM nonce with the same key.

When two services share a secret key and the receiver must detect changes and know that the message came from someone holding that key, use a keyed MAC such as HMAC. A plain hash is insufficient because an attacker who changes a message can also compute a new unkeyed hash.

For a software release that users must verify as coming from its publisher and as unaltered, use a digital signature. Distribute the publisher’s public key or a trusted certificate through a verifiable channel.

To store user passwords so that the originals cannot be recovered, use a password-hashing scheme designed for passwords, with a unique salt and appropriate work settings. Do not use reversible encryption or a fast general-purpose hash such as plain SHA-256.

Understand what a hash can prove

A SHA-256 digest sent alongside a file in the same email does not prove that the file came from the sender. A digest can reveal accidental or malicious changes only when the expected digest itself is trusted. Anyone able to replace the file can also replace its unkeyed digest.

For authentication with a shared secret, use HMAC. To let recipients verify a publisher using a public key, use a digital signature. SHA-256 is a standardized hash, but a hash is not encryption and does not, by itself, prove authorship.

Encrypt and authenticate messages

For a confidential JSON message between services with a shared secret key, use a maintained cryptographic library’s authenticated-encryption API, such as AES-GCM. Generate a fresh nonce as required by the library and mode, and send the nonce, ciphertext, and authentication tag. If needed, bind unencrypted context—such as a protocol version or record identifier—as authenticated associated data.

The receiver must verify the tag before accepting or using the plaintext. Reject the message on any authentication failure; do not process partially decrypted or unauthenticated data. Keep keys in an appropriate secrets or key-management system, separate from the data they protect.

If authentication fails after a deployment, check in order whether both sides selected the same key and algorithm, whether the nonce and associated data were preserved exactly, and whether the ciphertext or tag was truncated or modified. Do not skip tag verification or reuse a nonce as a workaround.

Verify signatures and signer identity

Use a recognized signature-verification implementation with the correct algorithm and message-processing rules. Verify the signature against the exact document bytes and the intended public key. A valid signature shows that the document matches a signature made with the corresponding private key; it does not encrypt the document or, by itself, establish the signer’s real-world identity.

If identity matters, establish that the public key is trusted, for example through a valid certificate path or a separately authenticated key-distribution channel. Treat failed verification as rejection, not as a warning to ignore.

Validate certificates and trust paths

Certificate validation must connect the target certificate to an accepted trust anchor. The verifier checks certificate signatures, validity periods, relevant constraints and usages, and whether the certificate identifies the requested service name. The certificate’s public key must also be suitable for the intended use. A certificate is not trustworthy merely because it is well-formed or self-signed; trust depends on successful validation against an appropriate trust anchor and the application’s policy. RFC 5280 describes certificate-path validation, and TLS 1.3 refers certificate validation to that PKI framework.

If clients reject a server certificate that appears current, check the client’s clock, requested hostname, missing or incorrect intermediate certificates, trust-store contents, certificate usage constraints, and whether the service is presenting the intended certificate and private key. Do not disable certificate verification as a workaround.

Manage keys through rotation and recovery

When decryption stops after a key change, first determine whether the old key was merely rotated or may have been compromised. Preserve access to the old key only as needed to decrypt existing records, and restrict and audit that access. Encrypt new records with the new key, and identify each record’s key version so the application can select the correct decryption key. Re-encrypt old records when appropriate, then retire the old key according to the recovery policy.

If compromise is suspected, escalate and follow the incident-response plan. Rotation alone cannot undo exposure of data an attacker may already have decrypted. Maintain independent procedures for key generation, storage, rotation, recovery, and destruction.

• key rotation