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.

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 →.

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?