Data Encryption

Symmetric Encryption

One shared key encrypts and decrypts data. Extremely fast and efficient for bulk data, but the key distribution problem is the central challenge.

• AES-256-GCM — gold standard; authenticated encryption provides both confidentiality and integrity
• AES-128-CBC — older mode; still secure but lacks built-in authentication (requires separate HMAC)
• ChaCha20-Poly1305 — faster than AES on hardware without AES-NI; used in TLS 1.3 and WireGuard
• Key insight: the key is the secret, not the algorithm — algorithms are public by design

Asymmetric Encryption

Two mathematically linked keys: a public key (share freely) and a private key (never share). Slower than symmetric but solves key distribution.

• RSA-2048/4096 — widely deployed; 2048-bit is minimum acceptable today, 4096-bit for long-lived keys
• ECC (Curve25519, P-256) — smaller keys with equivalent security; Curve25519 preferred for key exchange
• Hybrid encryption — asymmetric to exchange a symmetric key, then symmetric for data (how TLS works)
• Key insight: key management is harder than encryption — most breaches exploit key handling failures

Key vs. Algorithm

A fundamental principle: the security of an encrypted system rests entirely on the secrecy of the key, not the secrecy of the algorithm (Kerckhoffs's principle).

• Using secret or proprietary algorithms is "security through obscurity" — dangerous
• All widely-used algorithms (AES, RSA, ECC) are public and extensively vetted
• Key rotation reduces the blast radius of key compromise
• Key length determines security margin — longer keys = more work for attackers

TLS 1.2 vs TLS 1.3

Transport Layer Security is the foundation of secure communication on the internet. TLS 1.3 represents a major security and performance improvement.

• TLS 1.3 — 1-RTT handshake, 0-RTT resumption, removes weak cipher suites, mandatory forward secrecy
• TLS 1.2 — still acceptable with proper configuration; requires careful cipher suite selection
• TLS 1.0/1.1 — deprecated by all major browsers and NIST; do not use
• SSLv3 — vulnerable to POODLE attack; must be disabled everywhere

Certificate Infrastructure

X.509 certificates bind a public key to an identity and are signed by a trusted Certificate Authority (CA).

• Certificate chain — end-entity cert → intermediate CA → root CA; browsers trust root CAs
• Let's Encrypt — free, automated DV certificates via ACME protocol; 90-day validity forces automation
• Certificate Transparency (CT) — public append-only logs of all issued certs; enables misissuance detection
• HSTS — HTTP Strict Transport Security; tells browsers to only connect over HTTPS, even on first visit (preload list)

Mutual TLS (mTLS)

Standard TLS only authenticates the server. mTLS requires both client and server to present certificates — critical for service-to-service authentication.

• Zero-trust network architectures rely heavily on mTLS for east-west traffic
• Service meshes (Istio, Linkerd) automate mTLS for microservices
• Short-lived certificates (hours vs years) eliminate revocation complexity
• SPIFFE/SPIRE for workload identity and certificate issuance

Full Disk Encryption (FDE)

Encrypts all data on a storage device at the block level. Protects against physical theft but not against attacks on a running, unlocked system.

• BitLocker (Windows) — TPM-backed FDE; Group Policy managed; recovery keys in Azure AD or AD DS
• FileVault 2 (macOS) — AES-XTS 128-bit; recovery key escrowed via MDM
• dm-crypt/LUKS (Linux) — Linux Unified Key Setup; supports multiple key slots and key rotation
• Self-encrypting drives (SED) — hardware encryption; verify TCG Opal compliance and don't rely on vendor claims alone

Database Encryption

Multiple layers of database encryption serve different threat models — from storage theft to compromised application credentials.

• TDE (Transparent Data Encryption) — encrypts data files and backups at rest; available in SQL Server, Oracle, PostgreSQL, MySQL
• Column-level encryption — encrypt only sensitive columns (SSN, CC numbers); app decrypts as needed
• Application-level encryption — data encrypted before it reaches the database; DB never sees plaintext
• Always encrypt database backups with a separate key from the data encryption key

Cloud Storage Encryption

Cloud providers offer multiple encryption options with varying control levels over key management.

• SSE-S3 — AWS manages keys; simplest but least control
• SSE-KMS — keys in AWS KMS; audit trail, key rotation, access policies
• SSE-C — customer provides key with each request; AWS never stores the key
• Key rotation: schedule automatic annual rotation at minimum; immediate rotation after suspected compromise

Key Management Services (KMS)

Managed services for creating, storing, rotating, and auditing cryptographic keys — eliminates the hardest part of encryption at scale.

• AWS KMS — regional, FIPS 140-2 Level 2 validated; integrates with all AWS services; CloudTrail audit log
• Azure Key Vault — keys, secrets, and certificates; Premium tier backed by HSM; Managed HSM for dedicated hardware
• GCP Cloud KMS — software and HSM key versions; Cloud EKM for external key manager
• HashiCorp Vault — open source/enterprise; Transit secrets engine for encryption-as-a-service

Hardware Security Modules (HSM)

Dedicated hardware devices designed specifically for cryptographic operations. Keys generated in and never leave the HSM.

• FIPS 140-2 Level 3+ validated — cryptographic module security standard
• Physical tamper-evidence and tamper-response (zeroizes keys on attack detection)
• Cloud HSM options: AWS CloudHSM, Azure Dedicated HSM, GCP Cloud HSM
• Required for PKI root CA keys, payment card industry (PCI-DSS), and high-assurance use cases

Envelope Encryption Pattern

The standard pattern for encrypting data at scale using a two-level key hierarchy.

• Data Encryption Key (DEK) — unique per object/record; generated locally; used for actual data encryption
• Key Encryption Key (KEK) — stored in KMS; never leaves KMS; encrypts/wraps the DEK
• The encrypted DEK is stored alongside the ciphertext; re-encryption only requires re-wrapping the DEK, not re-encrypting all data
• BYOK (Bring Your Own Key) — you generate the root key; provider cannot decrypt data without your authorization

Generation

Use a cryptographically secure random number generator (CSPRNG). Hardware entropy sources are preferred. Never derive keys from low-entropy sources like passwords without KDF (PBKDF2, bcrypt, Argon2).

Distribution & Storage

Keys must be distributed securely — asymmetric key exchange or pre-shared keys via out-of-band channels. Store keys separately from the data they protect. Never log keys or store in source code.

Rotation & Revocation

Rotate keys on a schedule (annual minimum) and immediately after any suspected compromise. Maintain previous key versions for decrypting old data during rotation periods. Revoke immediately when compromise is confirmed.

Homomorphic Encryption

Computation directly on ciphertext without decrypting — the holy grail of cryptography. Results, when decrypted, match operations performed on plaintext.

• Fully Homomorphic Encryption (FHE) — supports arbitrary computation; computationally expensive (100x-1000x overhead)
• Partially Homomorphic — supports limited operations (addition OR multiplication): Paillier, ElGamal
• Use cases: privacy-preserving ML inference, secure voting, medical data analytics
• Libraries: Microsoft SEAL, OpenFHE, HElib; increasingly practical but not yet mainstream production use

Confidential Computing

Hardware-enforced Trusted Execution Environments (TEEs) that protect data and code in use — even from the cloud provider or hypervisor.

• Intel SGX — application enclaves; attestation proves code integrity to remote parties
• AMD SEV/SEV-SNP — VM memory encryption; hardware-isolated VMs; Azure Confidential VMs, GCP Confidential VMs
• ARM TrustZone — secure world isolated from normal world; widely used in mobile devices
• AWS Nitro Enclaves — isolated EC2 enclaves for sensitive processing

Post-Quantum Cryptography (PQC)

Current asymmetric algorithms (RSA, ECC) are vulnerable to Shor's algorithm on a sufficiently powerful quantum computer. NIST standardized PQC algorithms in 2024.

• CRYSTALS-Kyber (ML-KEM) — key encapsulation; replaces ECDH for key exchange
• CRYSTALS-Dilithium (ML-DSA) — digital signatures; replaces ECDSA/RSA signatures
• SPHINCS+ (SLH-DSA) — hash-based signatures; more conservative, larger signatures
• Harvest now, decrypt later attacks: adversaries are collecting encrypted data today to decrypt once quantum computers arrive