8 Cryptographic Applications and Secure Implementation

Match cryptography to the security goal

Cryptography is useful only when the algorithms, keys, and surrounding application workflow are used correctly. First identify whether the goal is confidentiality, integrity, authenticity, or some combination, and consider where threats occur. Use established cryptographic libraries and protocols rather than designing custom algorithms.

Protect stored data

Encryption at rest can protect files, database records, backups, and other stored data if an attacker gains access to the storage. Prefer Authenticated encryption, which encrypts data and detects unauthorized changes. If authentication fails during decryption, reject the data; do not use or return partially decrypted plaintext.

For example, an application can encrypt a confidential report before writing it to object storage. The stored package needs the ciphertext and information required for decryption, such as the nonce and key identifier. When the chosen library supports associated data, information such as a record ID or format version can be authenticated without being encrypted. Supply associated data consistently during decryption.

For large files, use a vetted streaming or file-encryption format rather than splitting data into improvised chunks. The format must authenticate chunks and relevant ordering or file metadata; otherwise, an attacker might rearrange, remove, or substitute chunks without detection.

Manage keys separately

Envelope encryption separates the key used to encrypt data from the key used to protect that data key:

1. Generate a random data-encryption key (DEK) for the data.

2. Encrypt the data with the DEK using authenticated encryption.

3. Protect the DEK with a separately managed key-encryption key (KEK), often held by a key-management service or hardware security module.

4. Store the ciphertext and protected DEK together, but keep the KEK under separate access controls.

This arrangement supports key rotation: a DEK can be rewrapped under a new KEK without re-encrypting all the data. Define how keys are generated, accessed, rotated, revoked, backed up, and retired. Restrict decryption permissions to services and users that need them.

Encryption does not replace authorization, backups, or secure deletion. An application that can decrypt data may expose it if its access controls or runtime are compromised. Encrypted backups also need recoverable keys; losing the keys can make the data permanently unavailable.

Protect APIs and data in transit

Use HTTPS with correctly configured Transport Layer Security (TLS) for API connections. Clients must verify the server certificate and hostname. Disabling certificate validation defeats protection against impersonation. TLS protects data in transit and helps authenticate the service, but it does not authorize a caller or protect data after the receiving service stores it.

Keep three checks distinct:

• Authentication: Who is making the request?

• Authorization: Is that identity allowed to perform this action on this resource?

• Transport protection: Is the connection protected and the service authenticated?

An API key or signed token does not replace endpoint-level authorization. Validate token signatures and relevant claims, such as issuer, audience, and expiration, using a maintained implementation. Mutual TLS may be appropriate for sensitive service-to-service connections.

Certificates bind a public key to an identity through a trusted certificate authority. Applications should validate the certificate chain, validity period, and intended hostname or identity, and handle revocation according to the environment’s requirements. A certificate is public; its corresponding private key must remain confidential. A Digital signature can provide integrity and evidence that the holder of a private key signed data, but it does not encrypt that data.

Choose the right cryptographic mechanism

Choose a cryptographic mechanism that matches the task:

• Encryption protects confidentiality; use authenticated encryption when data must also be protected from tampering.

• A Cryptographic hash produces a digest but does not conceal data or prove who created it.

• A Message authentication code (MAC) lets parties sharing a secret key verify message integrity and authenticity.

• A Digital signature lets recipients verify data using a public key and attributes the signature to control of the corresponding private key.

• Password storage requires a salted, deliberately slow password-hashing scheme, not reversible encryption or a fast general-purpose hash.

In a payment workflow, TLS protects the request while it travels to the service. The service separately authenticates the caller and checks permission to make the payment. If the payment record must remain confidential in storage, the service encrypts it with a managed key. If requests might be replayed, the application also needs workflow controls, such as unique request identifiers and duplicate detection: encryption or a valid signature alone does not necessarily prevent replay.

Avoid common implementation failures

Sound implementation requires attention to the details surrounding the algorithm. Common failures include:

• Reusing a nonce or initialization vector: Modes that require uniqueness can be compromised if a nonce or initialization vector is reused with the same key. In AES-GCM, reuse can seriously undermine security. Use library-supported nonce generation and follow the mode’s usage limits across every system sharing the key.

• Encrypting without authentication: Ciphertext may be altered unless the scheme detects tampering. Prefer authenticated encryption; do not invent a combination of encryption and a MAC.

• Using weak randomness: Generate keys, nonces, and security tokens with a cryptographically secure random-number generator, not a general-purpose random function or guessable values.

• Hard-coding or mishandling keys: Keep secrets out of source code, logs, and client applications. Use managed secret or key storage and least-privilege access; do not store keys beside plaintext.

• Treating hashes as encryption: A hash is not reversible, but an unkeyed hash of guessable data, such as a password, can be attacked by trying candidates. Use password hashing for passwords and a MAC or signature when authenticity is needed.

• Ignoring decryption failures: Reject invalid authentication tags and malformed ciphertext. Avoid error behavior that reveals sensitive details or accepts unauthenticated plaintext.

• Assuming TLS solves every security problem: TLS protects a connection, not access permissions, stored data, compromised endpoints, or replay-sensitive business operations.

• Building cryptographic formats or protocols from scratch: Prefer maintained, well-reviewed libraries and established formats. Plan key rotation and recovery before deployment.