Encryption in Transit and at Rest

Encryption protects data from being read by anyone without the key. In system design it comes in two main forms: encryption in transit protects data moving over networks, and encryption at rest protects data stored on disks, databases and backups. Around both sits the hardest part: managing keys safely.

Encryption in transit: TLS

TLS (the S in HTTPS) encrypts traffic between two parties, protects it from tampering, and authenticates the server with a certificate signed by a trusted authority. TLS 1.3 needs a single round trip to set up and uses forward secrecy, so a stolen server key can't decrypt previously recorded traffic.

• At the edge: terminate TLS at a CDN, load balancer or API gateway, with automated certificate renewal (Let's Encrypt, ACM).
• Inside the network: don't assume the internal network is safe. Re-encrypt between services, ideally with mutual TLS (both sides present certificates), which a service mesh can automate. This is the basis of zero-trust networking.
• Databases and caches: enable TLS on database and Redis connections, especially across zones or providers.
• Use HSTS so browsers never fall back to plain HTTP.

Encryption at rest

Data at rest is encrypted so stolen disks, snapshots or backups are useless without the key. Layers, from broad to fine-grained:

Broad layers are cheap and transparent but protect only against physical theft; the service itself still sees plaintext. Fine-grained layers protect more but complicate querying (you can't index or search ciphertext easily).

Envelope encryption and KMS

Encrypting terabytes with one master key, and sending all that data to a key service, doesn't scale. Envelope encryption uses two levels of keys:

1. Ask the key management service (KMS) for a new data key. It returns the key in plaintext and also encrypted under a master key that never leaves the KMS (often backed by hardware security modules).
2. Encrypt the data locally with the plaintext data key (e.g. AES-256-GCM), then discard the plaintext key.
3. Store the ciphertext together with the encrypted data key.
4. To decrypt, send the encrypted data key to the KMS (which checks permissions and logs the request), get the plaintext key back, and decrypt locally.

Benefits: bulk data never goes to the KMS; access to keys is centrally controlled and audited; rotating the master key only re-encrypts small data keys; and deleting a per-user data key makes that user's data unreadable (crypto-shredding), a practical way to honour deletion requests in backups and logs.

Hashing is not encryption

• Passwords must be hashed with a slow, salted algorithm (Argon2, bcrypt, scrypt), never encrypted, so even the service can't recover them.
• Integrity and signatures: HMACs verify webhook payloads and tokens (see webhooks); digital signatures prove who created data.
• Secrets (API keys, database passwords) belong in a secrets manager (Vault, AWS Secrets Manager), not in code or environment files committed to a repository.