Encryption — Key Agreement, Forward Secrecy, Certificates, TLS Attacks & At-Rest

The slice leans everywhere on "the key is never sent" and "hybrid crypto," but never derives how two parties agree a secret over a public wire. This page derives Diffie-Hellman/ECDHE, defines forward secrecy from it, then builds out the operational crypto a senior is expected to know: key management (envelope encryption, rotation), the certificate lifecycle and its failure modes, the TLS attack surface, and encryption-at-rest choices. (The step-by-step TLS/mTLS handshake has its own page; this one is the "why" underneath it.)

1. Diffie-Hellman key agreement, derived

Everyone agrees on public values: a large prime p and generator g. Alice picks a secret a and sends A = g^a mod p; Bob picks secret b and sends B = g^b mod p. Both then raise the other's value to their own secret: Alice computes B^a = g^(ba), Bob computes A^b = g^(ab) — the same number g^(ab) mod p, now a shared secret. An eavesdropper sees g, p, A, B but recovering a from g^a mod p is the discrete-logarithm problem, computationally infeasible for large p. So the secret is agreed, never transmitted — that is the "key never sent" the whole slice rests on. ECDHE is the same protocol over an elliptic-curve group (smaller keys, faster) with ephemeral per-session secrets.

2. Forward secrecy

If the ephemeral secrets a, b are freshly generated per session and discarded after, then even if an attacker later steals the server's long-term private key, they still cannot decrypt past recorded sessions — the per-session DH secret is gone and the long-term key was only used to authenticate the exchange, not to encrypt data. That property is forward secrecy: compromise of the long-term key does not retroactively expose old traffic. It's why TLS 1.3 mandates ephemeral (EC)DHE and dropped static-RSA key exchange (where stealing the key unlocked every captured session ever).

3. Key management: envelope encryption

You don't encrypt terabytes directly with a KMS-held master key (throughput, blast radius, rotation cost). Instead, envelope encryption: a per-object/per-tenant Data Encryption Key (DEK) encrypts the data locally (fast, symmetric AES); the DEK is then wrapped (encrypted) by a Key Encryption Key (KEK) that lives in a KMS/HSM and never leaves it. You store the wrapped DEK next to the ciphertext. To read, you send the wrapped DEK to the KMS, it returns the plaintext DEK, you decrypt.

Rotation then becomes cheap: rotate the KEK and re-wrap the (small) DEKs — you don't re-encrypt the data. True data re-encryption (new DEK) is only needed if a DEK is compromised. An HSM protects the KEK in tamper-resistant hardware; the KMS mediates access and audit. This is the standard pattern (AWS KMS, GCP KMS, Vault) and the expected answer to "how do you rotate keys without re-encrypting everything?"

4. Certificate lifecycle and its failure modes

A cert binds a public key to a hostname, signed by a CA. The validation and failure modes seniors probe:

• Hostname/SAN match — the requested host must be in the cert's Subject Alternative Name; a mismatch is a MITM signal (modern clients ignore the legacy CN).
• Expiry — short-lived certs (e.g. 90-day ACME/Let's Encrypt) reduce revocation dependence but make auto-renewal a hard operational requirement; a missed renewal is a self-inflicted outage.
• Revocation — CRL (big lists, slow), OCSP (per-cert query, latency + a privacy leak to the CA), and OCSP stapling (server attaches a fresh signed OCSP response, removing the client's CA round-trip) — the practical answer.
• Rogue CA / MITM — any trusted CA can mint a cert for any domain; Certificate Transparency (public append-only logs) lets domain owners detect mis-issuance, and pinning (trust only a specific key/CA) defends high-value apps at the cost of brittleness on rotation.

5. TLS attack surface

• Downgrade / version negotiation — an active attacker strips ClientHello to force a weaker version/cipher. Defense: TLS 1.3's simplified negotiation and downgrade-sentinel values in the server random that a client checks.
• 0-RTT replay (TLS 1.3) — early data sent in the first flight can be replayed by an attacker; safe only for idempotent requests, never for state-changing ones.
• Renegotiation DoS — a client repeatedly triggering handshakes forces the server into expensive asymmetric crypto — which ties encryption to DoS: the TLS handshake is CPU-asymmetric (the server does far more work than the client), so a flood of handshake requests is a cheap way to exhaust server CPU. Defense: rate-limit/curb client-initiated renegotiation, offload TLS to dedicated terminators.

6. Encryption at rest — the options

• Full-disk / volume — transparent, protects against stolen disks, but data is plaintext to anyone with OS access (a compromised app sees cleartext). Cheapest, coarsest.
• TDE (transparent DB encryption) — the DB encrypts files/pages; protects the media, but the running DB decrypts for every query, so a compromised DB is still exposed.
• Field/application-level — encrypt specific columns before storage; protects even from a compromised DB, but you lose the ability to index/range-query the ciphertext normally. Deterministic encryption lets you equality-match (and leaks equality/frequency); searchable encryption schemes trade performance/leakage for query capability. The trade-off: the closer to the data you encrypt, the stronger the protection and the more you give up in query power.

7. mTLS vs the alternatives (service auth)

• mTLS — both sides present certs; strong cryptographic identity, no shared secret to leak, works at the transport layer. Cost: a full certificate lifecycle for every service (issuance, rotation, revocation) — this is the thing that makes it operationally hard, and why service meshes (Istio/Linkerd) exist to automate it.
• Bearer tokens / JWT — easy to issue and pass, but a stolen token is game over until expiry (bearer = whoever holds it); needs short TTLs + rotation (see the Authorization deep-dive).
• API keys — simplest, but long-lived shared secrets, easily leaked, coarse.
• Network isolation — VPC/security-group boundaries; necessary defense-in-depth but not identity (anything inside the boundary is trusted — the flaw zero-trust rejects).

Rule of thumb: mTLS for service-to-service identity in a zero-trust mesh; short-lived tokens for user/edge auth; never long-lived API keys for anything sensitive.

Takeaways

• DH/ECDHE agrees a secret from values sent in the clear because discrete log is hard — the key is computed on both ends, never transmitted.
• Ephemeral keys give forward secrecy: stealing the long-term key doesn't expose recorded past sessions (why TLS 1.3 mandates (EC)DHE).
• Envelope encryption (DEK wrapped by KMS-held KEK) makes rotation cheap — rotate/rewrap keys, don't re-encrypt data.
• Certificates fail at expiry, revocation, SAN match, and rogue-CA; OCSP stapling + Certificate Transparency are the practical defenses. The TLS handshake's CPU-asymmetry is also a DoS lever.

Re-authored/Deepened for this guide.