Encryption in Transit & at Rest

Two complementary protections. Encryption in transit secures data moving over a network (TLS for HTTP, mTLS between services) so anyone sniffing the wire sees ciphertext. Encryption at rest secures stored data (disk/volume encryption, database/field-level encryption, encrypted backups) so anyone who obtains the physical media or files can't read them. Symmetric crypto (AES) does the bulk work; asymmetric crypto and key management handle key exchange and rotation.

Data is exposed in two places: while moving and while sitting still. A network attacker can intercept unencrypted traffic; a thief, insider, or misconfigured bucket can expose unencrypted storage. In-transit encryption defeats eavesdropping and tampering on the wire; at-rest encryption defeats stolen-disk, leaked-backup, and snapshot-exposure scenarios. Compliance regimes (PCI-DSS, HIPAA, GDPR) generally mandate both.

In transit: TLS does an asymmetric handshake to authenticate the server (via certificates) and agree a symmetric session key, then encrypts the stream with AES; mTLS adds client-cert authentication for service-to-service. At rest: data is encrypted with a symmetric data key before hitting disk; that data key is itself encrypted by a master key held in a KMS/HSM (envelope encryption), enabling rotation without re-encrypting everything. Sensitive fields can be encrypted at the application layer so even the database never sees plaintext.

• In-transit (TLS/mTLS) defeats eavesdropping and man-in-the-middle on the network
• At-rest defeats stolen disks, leaked backups, and exposed snapshots
• Envelope encryption + a KMS lets you rotate keys and revoke access without re-encrypting all the data

• Key management is the hard part: lose the key and the data is gone; leak it and encryption is moot
• At-rest disk encryption doesn't protect a running, compromised app, since the data is decrypted in memory for live access
• Crypto and handshake overhead add latency/CPU (small with modern hardware, but real for high-throughput or microsecond systems)

• Payment Gateway →

  TLS on every API call plus at-rest encryption of card data in the ledger; both are hard PCI-DSS requirements

• WhatsApp →

  End-to-end encryption means messages are encrypted on the sender's device; even the server stores only ciphertext in transit and at rest

• Amazon S3 (Object Storage) →

  Server-side encryption with KMS-managed keys encrypts every object at rest; TLS protects it in transit to and from the store

• At-rest encryption does nothing against a compromised live application: the app holds the decryption key and serves plaintext. It defends against stolen media, not against an attacker who's already inside.
• Key management is the whole game. Hardcoded keys, keys in the repo, or keys next to the data defeat the purpose, so use a KMS/HSM and envelope encryption so you can rotate and revoke.
• TLS termination at the load balancer leaves traffic plaintext on the internal network. If that network isn't trusted (multi-tenant, compliance scope), use mTLS end-to-end, not just at the edge.
• End-to-end encryption (WhatsApp-style) is different from server-side at-rest encryption: with E2EE the server can't read the data at all, which also means it can't search, index, or recover it.