Encryption fundamentals

Encryption, hashing, and encoding solve different problems

Suppose an API returns this value:

c2VjcmV0

It looks opaque, but it is Base64 for secret. Base64 represents binary data as text so it can pass through systems that expect ASCII-compatible input. It has no key and offers no confidentiality.

Wrong "The value is safe because a person cannot read it at a glance."

Right "Encoding changes representation. Anyone who has the encoded value can decode it."

Encryption turns plaintext into ciphertext under a key. Decryption uses the required key to recover the plaintext. Its security depends on the algorithm, the key, and how the key is protected.

A fixed-output cryptographic hash function maps input of arbitrary length to a fixed-length value. Secure cryptographic hashes are designed for preimage and collision resistance: given a digest, finding a corresponding input should be computationally infeasible, as should finding two inputs with the same output. Extensible-output functions such as SHAKE can produce variable-length output. There is no decryption key. Hashing is useful when a system needs a digest, but a bare hash does not hide a guessable password well and does not prove who supplied a message.

Password verification is a special case. NIST requires centrally verified passwords to use a suitable password-hashing scheme with a salt and cost factor. The cost makes each offline guess more expensive. A fast general-purpose digest such as a single SHA-256 operation does not meet that requirement.

Symmetric and asymmetric keys

Symmetric encryption uses one secret key for encryption and decryption. Every party that can decrypt with that key can also use it to encrypt. The hard operational problem is getting the secret key to the right parties while keeping it secret.

Asymmetric cryptography uses a mathematically related public and private key pair. The public key may be distributed; the private key must remain secret. Depending on the algorithm, the pair can support digital signatures, encryption, or key establishment. These capabilities are not interchangeable for every public-key algorithm.

Real protocols often combine both families. NIST describes the common hybrid approach: asymmetric operations handle signatures and initial key establishment, while faster symmetric algorithms protect larger amounts of data.

Wrong "HTTPS encrypts the response with the server's certificate public key from start to finish."

Right "TLS authenticates the handshake and establishes shared keying material, then symmetric traffic keys protect application records."

At rest and in transit describe locations

Data is in transit while it moves between endpoints. TLS can protect a connection's confidentiality and integrity, but its boundary ends where that TLS connection terminates. HTTPS from a browser to a load balancer says nothing about a separate load-balancer-to-application hop.

Data is at rest while stored on media. Full-disk, volume, and file encryption cover different storage boundaries. NIST's storage guidance makes the limitation concrete: full-disk encryption protects an unbooted device, assuming pre-boot authentication, but no longer supplies that protection after the device boots and the operating system can access plaintext.

Neither label means "safe everywhere." A service usually handles plaintext while processing a request. The useful question is which attacker and which point in the data path a control is meant to stop.

What happens in a TLS 1.3 handshake

A full TLS 1.3 handshake is easier to explain when you keep four jobs separate: negotiate parameters, establish shared keying material, authenticate the peer, and confirm the transcript.

The client starts with ClientHello. It offers protocol versions, symmetric cipher and HKDF hash pairs, and usually a Diffie-Hellman key share. The server selects acceptable parameters and returns ServerHello with its key share. The two key shares let both sides derive shared keying material. The shared secret itself does not travel across the connection.

RFC 8446 divides the handshake into key exchange, server parameters, and authentication. Everything after the key-exchange phase is encrypted with keys derived from the handshake traffic secret.

With certificate authentication, the server then sends:

• Certificate, which supplies the certificate and its public key.
• CertificateVerify, a signature over the handshake made with the corresponding private key.
• Finished, a MAC over the handshake transcript. It provides key confirmation and handshake integrity.

The client validates the server's identity according to the certificate rules it applies, verifies the signature, and checks Finished. The client sends its own Finished, plus certificate messages if the server requested client authentication. Both peers derive application traffic keys, and the TLS record layer uses authenticated symmetric encryption for application data.

Wrong "The certificate contains an encrypted symmetric key that the client extracts."

Right "The certificate supports authentication. Key exchange establishes shared material, and the TLS key schedule derives traffic keys."

Why encryption alone is incomplete

Confidentiality answers whether an unauthorized party can read the data. Integrity answers whether the data changed. Source authentication gives assurance about its source. NIST explicitly warns that encryption does not by itself assure authenticity.

Modern TLS 1.3 cipher suites use authenticated encryption for records. This combines confidentiality with an authentication check. A receiver must reject data when authentication fails; decrypting bytes is not enough to establish that a message is valid.

A bare unkeyed hash is also insufficient against an active attacker. An attacker who can replace a message can compute a new hash for the replacement. NIST recommends a MAC with a secret key or a digital signature when adversarial modification is in scope. A MAC can provide integrity and source authentication to parties that know the shared key. A digital signature uses a private key to sign and a public key to verify.

Wrong "Attach SHA-256(message) and tampering becomes impossible."

Right "An attacker can replace both the message and an unkeyed hash. Use an authentication mechanism suited to the trust model."

Forward secrecy limits later damage

An ephemeral Diffie-Hellman exchange uses fresh secret values for the connection. Forward secrecy means that later compromise of long-term keying material does not expose past session keys covered by that property, provided the per-connection secrets have been erased. In a certificate-authenticated handshake, stealing the server's certificate private key later should not let an attacker decrypt previously recorded sessions that used the ephemeral exchange and erased those secrets.

The qualification matters. TLS 1.3 can resume a session with a pre-shared key. PSK plus a fresh (EC)DHE exchange can provide forward secrecy. PSK-only key establishment does not provide the same protection against later PSK compromise. RFC 8446 also describes single-use PSK deployments that delete the PSK after use, but that lifecycle guarantee is separate from an ephemeral key exchange.

TLS 1.3 0-RTT early data is another exception worth memorizing. RFC 8446 states that early data is not forward secret because its keys derive solely from the offered PSK. It also has no non-replay guarantee between connections. Operations with replay-sensitive effects need application-level handling or must wait for ordinary 1-RTT protection.

Review the protection boundary, not the feature name

"Encrypted at rest" is incomplete without a threat and an unlock boundary. Full-volume encryption can protect offline media from disclosure. Once the host has booted and the volume is unlocked, the operating system and authorized applications can read plaintext. A compromise that gains the application's data access may sit inside that boundary.

Field-level or application-level encryption moves the decryption boundary, but it also changes who must hold the key. If the same compromised process can fetch both ciphertext and the decryption key, encryption cannot stop that process from decrypting. The control may still protect backups, storage snapshots, logs, or operators that lack key access. State the exact threat instead of claiming that one layer covers every path.

Transit protection has the same shape. A TLS connection protects records between its two TLS endpoints. If TLS terminates at a proxy, a later plaintext hop is a different connection. Protect that hop when its network or intermediaries are in scope. Also inspect queues, database connections, replication links, administrative exports, and backups. Data often crosses more boundaries than the public request path suggests.

Wrong "The database volume and public endpoint are encrypted, so the system has end-to-end encryption."

Right "List each place plaintext exists, each connection it crosses, and which principal can obtain each key."

Key management is part of the cryptosystem

NIST describes key management across generation, storage, establishment, use, and destruction. Strong encryption with exposed or badly generated keys does not preserve confidentiality. Secret and private keys require confidentiality protection; all key information requires integrity protection.

A defensible design records at least these decisions:

• Which component generates a key and which approved random source it uses.
• Which principals can use the key, whether they can export it, and how access is audited.
• The key's purpose, cryptoperiod, rotation path, recovery requirements, and destruction path.
• How old ciphertext remains decryptable during migration without leaving retired keys broadly available.

Separate keys by purpose. NIST warns that reusing one key across different cryptographic processes may weaken one or both. Encryption, message authentication, signing, and key establishment are separate purposes unless a reviewed construction explicitly combines them, as an authenticated-encryption mode does.

Failure modes that survive an algorithm checklist

The first is confidentiality without authenticity. Ciphertext can be unreadable and still be replaceable or modifiable. NIST recommends authenticated encryption when encryption and authentication are needed together. The application must treat authentication failure as rejection, before it consumes plaintext.

The second is treating a human password as a cryptographic key or a fast digest as a password verifier. Passwords have low and uneven entropy. NIST's current SP 800-63B-4 requires a suitable password-hashing scheme that accepts a password, salt, and cost factor. Store the salt, algorithm reference, and cost so the verifier can migrate work factors. This is intentionally different from hashing a file for a checksum.

The third is losing track of TLS exceptions. A normal certificate-authenticated TLS 1.3 handshake with fresh ephemeral key exchange has a different exposure profile from PSK-only resumption, assuming its per-connection secrets are erased. A single-use PSK that is deleted after use can narrow PSK-only exposure, but ordinary PSK-only establishment lacks the protection of fresh (EC)DHE. 0-RTT is weaker again: no forward secrecy for the early data and no cross-connection non-replay guarantee.

Wrong "TLS 1.3 means every byte has identical security properties."

Right "Name the handshake mode, where TLS terminates, and whether the data is 0-RTT or ordinary application data."

Good cryptographic review follows the data and the keys together. Data at rest, data in transit, and data in use are different states, but a key crossing the wrong boundary can collapse the distinction.