What does "encrypt everywhere" mean, and why isn't encrypting data in transit enough?
Protect data in both of its states — in transit and at rest — because they defend different attack points: transit encryption does nothing for a stolen backup, and at-rest encryption does nothing for a sniffed connection.
* Two independent barriers: TLS guards data on the wire, at-rest encryption guards it in storage — you need both. *
Two states, two independent layers:
- In transit — TLS on every connection, including internal service-to-service traffic (never assume the internal network is safe — that's the Zero Trust mindset). Stops eavesdropping and tampering on the wire.
- At rest — encrypt disks, databases, backups, and especially sensitive fields. Passwords are hashed (bcrypt/Argon2); secrets and PII are encrypted. Protects data if a disk, backup, or DB dump is stolen.
Why both: they're independent barriers (defense in depth). An attacker who gets past the network still meets encryption at the storage layer, and vice versa. Encrypting only one state leaves the other wide open.
The catch — it's only as good as key management: a key stored next to the data it protects gives no protection. Keep keys in a KMS/HSM, rotate them, and never hardcode them in source or config.
Tip: This principle leans on "use proven solutions" — reach for AES-GCM and TLS via vetted libraries, never a homemade cipher.
Go deeper:
Wikipedia — Encryption — symmetric vs asymmetric, and protecting data both in transit and at rest.- Wikipedia — Data at rest — why stored data needs its own encryption and key management.