Encryption

8 min read

In a Nutshell

Encryption transforms readable data into scrambled ciphertext that only someone with the right key can reverse — it's the primary tool for keeping data confidential from anyone who shouldn't see it. In system design, you encrypt data in two states: in transit (moving over networks, via TLS) and at rest (stored on disk or in databases). There are two families of algorithms: symmetric (one shared key, fast, for bulk data) and asymmetric (a public/private key pair, slower, for key exchange and signatures). Understanding when and how to apply each — and the related tools of hashing and key management — is fundamental to protecting sensitive data.

2D minimalistic diagram showing readable plaintext ("Hello") passing through an encryption function with a key, becoming scrambled ciphertext ("X8#kP"), traveling safely across an untrusted channel, then being decrypted with the key back into the original plaintext, illustrating confidentiality in transit

How It Actually Works

Symmetric vs Asymmetric Encryption

	Symmetric	Asymmetric
Keys	One shared secret key	Public/private key pair
Speed	Fast	Slow (100–1000× slower)
Key distribution	Hard (must share the secret securely)	Easy (public key is public)
Use	Bulk data encryption	Key exchange, digital signatures
Examples	AES, ChaCha20	RSA, ECC (Elliptic Curve)

The genius of modern crypto is combining both: use slow asymmetric crypto to securely exchange a symmetric key, then use fast symmetric crypto for the actual data. This is exactly how TLS works.

TLS handshake (hybrid):
  1. Asymmetric: authenticate the server + agree on a shared secret
     (ephemeral Diffie-Hellman → forward secrecy)
  2. Symmetric: encrypt all the actual traffic with that shared key (AES)
  → Best of both: secure key exchange + fast bulk encryption.

Encryption in Transit vs At Rest

State	Protects Against	Mechanism
In transit	Eavesdropping/tampering on the network	TLS/HTTPS (see HTTP & HTTPS)
At rest	Stolen disks, DB dumps, backup theft	Disk/DB/field-level encryption

In transit: every network hop should be encrypted — client↔server (HTTPS) and service↔service (mTLS). "Encrypt everywhere" is the modern default.
At rest: encrypt disks (transparent), databases (TDE), or specific sensitive fields (application-level). Field-level encryption protects the most sensitive data (SSNs, card numbers) even from someone with database access.

Encryption vs Hashing — Not the Same Thing

A critical distinction that's often confused:

Encryption:  reversible — plaintext ⇄ ciphertext (with the key)
             Use for data you need to READ BACK (messages, files, PII).

Hashing:     one-way — plaintext → fixed digest, NOT reversible
             Use for verification without storing the original
             (passwords, integrity checks). Cannot be "decrypted."

Passwords are hashed (you only need to verify, never retrieve — see Authentication); credit-card numbers you must charge later are encrypted (you need them back).

Digital Signatures (Asymmetric, Reversed)

Asymmetric keys also provide integrity and authenticity: sign with the private key, verify with the public key. Anyone can verify the signer's identity and that the data wasn't altered — this underpins TLS certificates, JWT signatures, and code signing.

Key Management: The Hard Part

Encryption is only as strong as its key management. The algorithms are solid; keys are where things break:

Concern	Practice
Storage	Keys in a KMS/HSM, never in code or config (see Secrets Management)
Rotation	Rotate keys periodically; support re-encryption
Separation	Data and keys stored separately (stealing the DB ≠ stealing the keys)
Envelope encryption	Encrypt data with a data key, encrypt the data key with a master key in a KMS

Envelope encryption is the standard cloud pattern: a master key (in a hardware security module) never leaves the KMS and only encrypts small data keys, which in turn encrypt the bulk data.

Don't Roll Your Own Crypto

The universal rule: use vetted, standard libraries and algorithms (AES-GCM, TLS 1.3, libsodium), never invent your own. Cryptography is extraordinarily easy to get subtly, catastrophically wrong. Use the right modes (authenticated encryption like AES-GCM, not ECB), current algorithms, and well-audited implementations.

2D minimalistic diagram illustrating envelope encryption: bulk data encrypted by a data key (fast, symmetric); the data key itself encrypted by a master key that lives inside a KMS/HSM and never leaves it; to decrypt, the encrypted data key is sent to the KMS to be unwrapped, keeping the master key isolated

Seeing It in Action

Scenario: Protecting sensitive data in a fintech app — layered encryption.

In transit (encrypt everywhere):
  - Client ↔ API: TLS 1.3 (HTTPS). No plaintext on the public network.
  - Service ↔ service: mTLS (mutual auth + encryption internally too).
  - DB connections: TLS. Even the app↔database link is encrypted.

At rest (defense in depth):
  - Disk-level: full-disk / volume encryption (transparent baseline).
  - Database: TDE (transparent data encryption) for the whole store.
  - Field-level: the MOST sensitive fields (card numbers, SSNs) encrypted
    at the APPLICATION layer with AES-GCM before they ever hit the DB.
    → Even an attacker with full database access sees ciphertext for these.

Key management (envelope encryption via cloud KMS):
  - A master key lives in the KMS/HSM and NEVER leaves it.
  - Each record's sensitive field is encrypted with a per-record data key.
  - The data key is itself encrypted by the master key and stored beside
    the data. To read a field: KMS unwraps the data key → decrypt the field.
  - Keys rotated on a schedule; data and keys stored in separate systems.

Right tool per data type:
  - Passwords → HASHED (Argon2), never encrypted — only need to verify.
  - Card numbers → ENCRYPTED (need to charge later) — or better, TOKENIZED
    via a PCI-compliant vault so raw numbers never touch your systems.
  - Session traffic → TLS in transit.

Why the layering matters: each layer defends against a different threat. TLS everywhere defeats network eavesdroppers (including on the internal network via mTLS). Disk and database encryption protect against stolen hardware and backup theft. Field-level application encryption protects the crown-jewel data even from an attacker who has already breached the database — a database dump yields only ciphertext for card numbers. Envelope encryption ensures the master key never sits next to the data it protects, so stealing the database doesn't compromise the keys. And using the right primitive per data type — hashing for passwords, encryption (or tokenization) for retrievable secrets, TLS for transit — reflects the fundamental rule that confidentiality is achieved not by one switch but by applying the correct, standard, well-managed cryptographic tool to each state and sensitivity of data. The one thing you never do is invent the crypto yourself.

Interview Questions

Q: What's the difference between symmetric and asymmetric encryption, and why do systems combine them? Hint: Symmetric uses one shared key — fast, ideal for bulk data, but hard to distribute the secret. Asymmetric uses a public/private key pair — easy key distribution and enables signatures, but slow. Systems combine them (e.g., TLS): asymmetric crypto securely exchanges/agrees on a symmetric session key, then fast symmetric crypto encrypts the actual data. Best of both: secure key exchange + fast bulk encryption.
Q: Explain encryption in transit vs at rest, and give mechanisms for each. Hint: In transit protects data moving over networks from eavesdropping/tampering — via TLS/HTTPS (client↔server) and mTLS (service↔service). At rest protects stored data from stolen disks, DB dumps, and backup theft — via full-disk encryption, database TDE, or application/field-level encryption for the most sensitive fields. Modern practice: encrypt everywhere in both states.
Q: What's the difference between encryption and hashing, and when do you use each? Hint: Encryption is reversible (plaintext ⇄ ciphertext with a key) — use for data you must read back (messages, retrievable PII, card numbers to charge). Hashing is one-way and irreversible (plaintext → digest) — use for verification without storing the original (passwords, integrity checks). Passwords are hashed (only verified), not encrypted; a value you need back later is encrypted.
Q: What is envelope encryption and why is it used? Hint: Encrypt bulk data with a (fast, symmetric) data key, then encrypt that data key with a master key that lives inside a KMS/HSM and never leaves it. To decrypt, send the wrapped data key to the KMS to unwrap. It keeps the master key isolated (stealing the data/DB doesn't reveal it), enables scalable per-record keys, and supports rotation — the standard cloud key-management pattern.
Q: Why is "don't roll your own crypto" a rule, and what does good practice look like? Hint: Cryptography is extremely easy to get subtly, catastrophically wrong (weak modes like ECB, timing attacks, bad randomness, key reuse). Use vetted standard algorithms and audited libraries (AES-GCM, TLS 1.3, libsodium), authenticated encryption modes, current key sizes, and proper key management (KMS/HSM, rotation, separation). The strength comes from correct use and key management, not novelty.

References

OWASP Cryptographic Storage Cheat Sheet — practical encryption guidance
Cloudflare: What is encryption? — symmetric/asymmetric primer
AWS KMS & envelope encryption — key management in the cloud

Dive Deeper

Cryptographic Right Answers (Latacora) — which algorithms to actually use
Serious Cryptography by Jean-Philippe Aumasson — a modern, readable deep dive
TLS 1.3 explained — hybrid encryption in practice