Encryption in transit & at rest

A private journaling app has 2 million users writing daily entries, some with photos. One entry travels from a phone, through a load balancer, to an API server, into a database and object storage, and from there into nightly backups. Along that path it can be read in three different states:

Each kind of encryption answers a specific attacker, and none answers all of them:

TLS (Transport Layer Security), the S in HTTPS, gives a connection three properties:

• Authentication: the server always proves its identity with a certificate; the client can too, but usually doesn't.
• Confidentiality: only the two ends can read the data.
• Integrity: any change in transit is detected.

TLS 1.3, the current version, completes its handshake in one round trip:

Those key shares are generated fresh for every connection and thrown away afterward. That gives TLS 1.3 forward secrecy: if someone records the journal app's traffic today and steals the server's private key next year, the recordings stay unreadable, because the key never decrypted traffic, it only proved identity. TLS 1.3 removed static RSA and static Diffie-Hellman, so every full handshake has forward secrecy; resuming a session from a pre-shared key without a fresh key share, and 0-RTT early data, don't.

Two details deserve care:

• 0-RTT resumption lets a returning client send data in its very first message, but that early data can be replayed by an attacker. Allow it only for requests that are safe to repeat (Idempotency).
• Downgrade to plain HTTP. An attacker on the network can try to keep a user on unencrypted HTTP. The Strict-Transport-Security (HSTS) header tells browsers to use only HTTPS for the site from then on.

A certificate is a statement, signed by a certificate authority, that a public key belongs to a domain. Certificates now expire faster on purpose, which limits how long a stolen key stays useful and makes manual renewal impossible:

A common setup ends TLS at the load balancer and sends plain HTTP to the servers behind it, on the theory that the internal network is trusted. That theory fails whenever anything inside is compromised, misconfigured or shared with other tenants, and the traffic between data centers often crosses links you don't own. The current practice, part of what's called zero trust (Network segmentation & zero trust), is to encrypt every hop and authenticate both ends.

Between services, that means mutual TLS (mTLS): both sides present certificates. When the API server calls the database proxy, each learns the other's identity cryptographically, not from an IP address that changes with every deploy (Service discovery & registration). Systems such as SPIFFE give each workload an identity like spiffe://journal.example/api and issue it short-lived certificates that rotate automatically.

Doing this by hand in every service is error-prone, which is one reason service meshes exist: a proxy beside each service performs mTLS and rotates the certificates, and the application talks plain HTTP to localhost. Either way, the certificates must be renewed automatically: an internal certificate that expires unnoticed breaks every call that depends on it.

Stored data is encrypted with a symmetric cipher, commonly AES-256 in GCM mode, which also detects tampering. The hard part is the key. If every journal entry were encrypted with one key stored next to the database, stealing the database would mean stealing the key too. And sending every entry to a key vault to be encrypted would be slow and limited by the vault's capacity.

Envelope encryption solves both. Each object or partition gets its own data key (DEK), which encrypts the data locally. The data key is itself encrypted ("wrapped") by a key encryption key (KEK) that lives in a key management service (KMS) backed by hardware security modules and never leaves it in plaintext:

The design pays off in operations:

• Rotation is cheap. A new KEK means re-wrapping small data keys, not re-encrypting terabytes.
• Access is auditable. Reading data requires a logged call to the key service, which can be restricted to specific services.
• Deleting a key deletes data. Destroying the key that wraps one user's data keys makes that data unrecoverable everywhere, backups included: crypto-shredding. Because that is irreversible, AWS KMS, for example, enforces a waiting period of 7 to 30 days before a deletion takes effect.

Most cloud storage and managed databases now encrypt everything at rest by default, transparently: data is encrypted on its way to disk and decrypted on its way back. That defeats someone who walks off with a drive. It does nothing against someone who queries the database through the application, because the database decrypts for any authorized query, including one from an attacker holding stolen credentials. The deeper the encryption sits in the application, the more it protects and the more it costs:

The journal app has to choose for entries. End-to-end encryption means a breach of its servers exposes nothing readable, but it also means no server-side search, no recovery if a user loses every device and recovery key, and more work to share an entry. Apple's Advanced Data Protection shows the trade in practice: it end-to-end encrypts 25 categories of iCloud data and makes users set up a recovery contact or key first, while Mail, Contacts and Calendars stay outside it because the standards they must interoperate with don't support it.

A common middle ground is field-level encryption of the entry text with per-user data keys, plus transparent encryption for everything else. Entries stay unreadable in database dumps and to administrators, and deleting a user's key erases their journal, including every copy in backups (Disaster recovery & backups).

Encryption converts a data-protection problem into a key-protection problem. The rules that keep it solved:

• Never put keys in code, images or config repositories. Keep them in a KMS or secrets manager and fetch them with the service's own identity.
• Least privilege on decryption. Only the journal API may unwrap journal keys; analytics jobs get none.
• Separate keys per environment, per region and, where it matters, per tenant or user.
• Rotate on a schedule, and immediately on suspicion.
• Plan for key loss as for data loss. Backups encrypted with keys that didn't survive the disaster are useless.

One threat changes the timeline. An attacker can record encrypted traffic today and wait for a quantum computer able to break today's key exchange: harvest now, decrypt later. Journal entries must stay private for decades, so this matters now.

The response is hybrid key exchange, which combines classic X25519 with the post-quantum ML-KEM, standardized as FIPS 203 in August 2024. By late October 2025, more than half of the human-initiated traffic Cloudflare sees already used it. Post-quantum certificates and signatures are less urgent and less mature, since forging a signature later can't reach back into recorded traffic.