Encryption in Transit & at Rest

Encryption is how you keep data confidential and tamper-evident at a trust boundary you don’t control — a network you don’t own, a disk that might be stolen, a backup that might leak. There are two boundaries to defend, and they’re genuinely different problems: data in transit (moving between machines) and data at rest (sitting in storage). Conflating them is a classic gap; a system can encrypt one and leave the other wide open.

First, the two building blocks

All of this rests on two flavors of cryptography. You don’t need the math — you need to know what each buys you.

   SYMMETRIC                         ASYMMETRIC
   ─────────                         ──────────
   one shared key encrypts & decrypts   a key PAIR: public + private
   FAST (good for bulk data)            SLOW (good for small data / setup)
   problem: how do both sides            solves it: encrypt with the public key,
   get the same secret key?              only the private key can decrypt
   e.g. AES                              e.g. RSA, elliptic curve (ECDSA/ECDH)

Symmetric encryption is fast but has a key-distribution problem: both parties need the same secret, and shipping a secret over an insecure channel is the very problem you’re trying to solve. Asymmetric encryption breaks the deadlock — you can hand out your public key freely, and only your private key can undo what it locks. The catch: asymmetric is far too slow for streaming gigabytes.

The resolution, used everywhere, is hybrid encryption: use slow asymmetric crypto once to safely agree on a shared symmetric key, then use fast symmetric crypto for the actual data. This is exactly what TLS does.

In transit: TLS

TLS (Transport Layer Security, the “S” in HTTPS) protects data as it crosses the network. It gives you three properties at once:

• Confidentiality — eavesdroppers see ciphertext, not your data.
• Integrity — tampering in flight is detected and the connection fails.
• Authentication — you can verify you’re really talking to bank.com, not an impostor.

The handshake is hybrid crypto in action:

1. Client says hello, lists supported ciphers
2. Server presents its CERTIFICATE (its public key, signed by a trusted CA)
3. Client verifies the cert chains up to a Certificate Authority it trusts
4. Both sides use asymmetric crypto to agree on a fresh SYMMETRIC session key
5. All further traffic is encrypted with that fast symmetric key

The certificate is what makes authentication work. A Certificate Authority (CA) vouches that this public key really belongs to bank.com; your browser ships with a list of CAs it trusts, so the trust is transitive. Without the CA, an attacker could present their public key and you’d encrypt your secrets straight to them — that’s the man-in-the-middle attack the cert prevents.

TLS terminates somewhere — know where

TLS protects the hop, not the whole journey. A load balancer often terminates TLS, decrypting traffic before forwarding it inward. If that inner network isn’t also encrypted, data travels in the clear between your own services — fine inside a locked-down VPC, dangerous otherwise. For sensitive systems, mutual TLS (mTLS), where both sides present certificates, secures service-to-service hops too. Always ask: where does the plaintext exist?

At rest: encrypting stored data

Encryption at rest protects data that isn’t moving — databases, files, backups, disk images — against a different threat: someone gaining physical or storage-level access. If a drive is stolen, a backup tape is lost, or a cloud volume is misconfigured, encryption at rest means the attacker holds ciphertext, not your customers’ records.

It comes in layers, each defending against a different reach:

   FULL-DISK / VOLUME   →  protects against a stolen physical disk
                           (but a running, mounted system sees plaintext)
   DATABASE / TDE       →  the DB encrypts files on disk transparently
   FIELD / COLUMN       →  encrypt specific sensitive columns (SSNs, tokens)
                           so even a DB compromise doesn't expose them

The honest caveat: full-disk encryption protects a powered-off disk, but does nothing against an attacker who’s compromised the running application — the OS hands them plaintext. That’s why sensitive fields are often encrypted at the application layer, narrowing what any single compromise reveals. Layered, again, by blast radius.

The part that actually matters: key management

Here is the uncomfortable truth: encryption converts a data-protection problem into a key-protection problem. Your ciphertext is only as safe as the key that unlocks it. Store the key next to the data — a depressingly common mistake — and you’ve encrypted nothing; you’ve just added a step. Lose the key entirely and your data is gone forever, encryption working against you.

So real systems manage keys deliberately:

• Separation — keys live somewhere other than the data they protect (a KMS or HSM), so one breach doesn’t yield both.
• Envelope encryption — data is encrypted with a data key, and that data key is itself encrypted by a master key held in the KMS. To rotate, you re-encrypt the small data key, not petabytes of data.
• Rotation — keys change on a schedule and after any suspected exposure, limiting how much data a single compromised key can ever unlock.

Keys are simply a very high-value secret, which is why this hands directly to the next page, Secrets Management — the discipline that keeps them safe.

What this buys us, and what it costs

Encryption buys confidentiality and integrity across boundaries you don’t control — the wire, the disk, the backup. It costs CPU (modest, with hardware acceleration), latency (a TLS handshake adds a round trip), and — far more significantly — the operational burden of key management: rotation, backup, access control, and the genuine risk that a lost key means lost data. Encryption is rarely the hard part; living with the keys is.

By the numbers — what the handshake actually costs in round trips

The “TLS adds latency” cost is paid in round trips, and the protocol version decides how many.

TLS 1.2 full handshake     →  2 round trips before the first byte of app data
TLS 1.3 full handshake     →  1 round trip          (the major win of the 2018 redesign)
TLS 1.3 resumption (0-RTT)  →  0 round trips         (send data with the first packet)

On a link with 60 ms of round-trip time, that’s the difference between roughly 120 ms, 60 ms, and 0 ms of handshake tax before any real data flows. This is why TLS 1.3 and session resumption matter so much for latency-sensitive systems — and why the cost side of encryption is mostly setup, not the bulk symmetric crypto, which modern CPUs do with hardware acceleration (AES-NI) at gigabytes per second.

It actually happened — Heartbleed (2014, CVE-2014-0160)

Heartbleed was a bug in OpenSSL’s implementation of the TLS “heartbeat” keep-alive: a missing bounds-check let an attacker ask the server to echo back more memory than they had sent, leaking up to 64 KB of whatever happened to be in the process’s RAM — session cookies, passwords, and, most damaging, the server’s TLS private key itself. The lesson lands directly on this page’s core point: encryption converts a data problem into a key problem, and once the private key leaks, every past and future session it protected is compromised. The remediation wasn’t just “patch OpenSSL” — it was reissue and revoke every certificate, because you had to assume the keys were already stolen. TLS was sound; the code at the boundary was not.

The thread

Defend the two boundaries data crosses: in flight (TLS, with certificates anchoring trust to a CA) and at rest (layered, by blast radius). Both reduce to hybrid cryptography — slow asymmetric to agree on a key, fast symmetric for the payload — and both collapse to a single question: who can reach the key? Answering that well is Secrets Management →.

The architect’s lens

Encryption defends boundaries you don’t control — run it through the five questions:

• Why does it exist? Because data crosses places you can’t trust — a network you don’t own, a disk that might be stolen, a backup that might leak — and you need it confidential and tamper-evident there.
• What problem does it solve? Two distinct boundaries: in transit (TLS gives confidentiality, integrity, and authentication via a CA-signed certificate, defeating man-in-the-middle) and at rest (layered by reach — full-disk vs. column-level — so a stolen drive or misconfigured volume yields ciphertext).
• What are the trade-offs? Pure symmetric is fast but can’t distribute keys; pure asymmetric solves distribution but is too slow for bulk — so everything uses hybrid (asymmetric once to agree a symmetric key). The real cost isn’t CPU (AES-NI does GB/s) or the handshake round trips (2 for TLS 1.2, 1 for 1.3); it’s key management.
• When should I avoid it (or recognize its limits)? Full-disk encryption is useless against a compromised running app — the OS hands it plaintext — so it’s no substitute for field-level encryption of truly sensitive columns. And TLS protects only the hop: if it terminates at the load balancer and the inner network is clear, know where the plaintext lives (or use mTLS).
• What breaks if I remove it? Eavesdroppers read your wire traffic and a stolen disk or leaked backup exposes raw records. But note the inversion: store the key next to the data and you’ve encrypted nothing; lose the key and the data is gone forever (Heartbleed leaked the private key itself, forcing every cert to be reissued).

Check your understanding

1. Distinguish data in transit from data at rest, and the different threat each one defends against.
2. Why do real systems use hybrid encryption instead of pure symmetric or pure asymmetric?
3. What role does a Certificate Authority play in TLS, and which attack does it prevent?
4. Full-disk encryption protects against what, and is useless against what?
5. Why is “encryption is a key-management problem” the most important sentence on this page?

Show answers

1. In transit = data moving between machines (defended with TLS) against an eavesdropper or tamperer on a network you don’t own. At rest = data sitting in storage (databases, files, backups, disk images) against someone gaining physical or storage-level access — a stolen drive, a lost backup tape, a misconfigured cloud volume. Conflating them is a classic gap: a system can protect one and leave the other wide open.
2. Symmetric is fast (good for bulk data) but has a key-distribution problem — both sides need the same secret, and shipping it over an insecure channel is the very problem you’re solving. Asymmetric breaks that deadlock (hand out the public key freely) but is too slow for streaming gigabytes. Hybrid uses slow asymmetric crypto once to agree on a shared symmetric key, then fast symmetric crypto for the data — exactly what TLS does.
3. A Certificate Authority vouches that a public key really belongs to bank.com, and your browser ships with a list of CAs it trusts, making the trust transitive. This prevents the man-in-the-middle attack: without the CA, an attacker could present their public key and you’d encrypt your secrets straight to them.
4. Full-disk encryption protects against a stolen, powered-off physical disk (the attacker holds ciphertext). It’s useless against an attacker who’s compromised the running, mounted system — the OS hands them plaintext. That’s why sensitive fields are often encrypted at the application layer, narrowing what any single compromise reveals.
5. Because encryption converts a data-protection problem into a key-protection problem — your ciphertext is only as safe as the key that unlocks it. Store the key next to the data and you’ve encrypted nothing; lose the key and your data is gone forever. What does encryption buy us? Confidentiality across boundaries you don’t control. What does it cost? Living with the keys — separation (KMS/HSM), envelope encryption, and rotation.