Encryption

Key features

• TLS protects data between two endpoints (client-to-server, service-to-service) — it does not protect the data once it is written to disk at either end
• Encryption at rest protects stored data — database files, backups, snapshots, log files — from anyone who gets the raw storage medium without going through the application
• A stolen laptop, an exposed S3 bucket, or a leaked database backup all bypass TLS entirely — TLS was never in the request path for those
• TLS 1.3 (RFC 8446) is the current baseline; TLS 1.0 and 1.1 are deprecated and should be rejected by any service that still accepts them
• At-rest encryption is usually transparent to the application (disk- or database-level, e.g. AES-256) — the app reads and writes plaintext and the storage layer handles the encrypt/decrypt step

Command

// In transit: negotiated per connection
client --TLS 1.3 handshake--> server
       <---- encrypted channel ---->

// At rest: applied to the storage layer, not the request
disk / database volume: AES-256 encryption
backup snapshot: AES-256 encryption
(application reads/writes plaintext; storage layer
 handles encrypt/decrypt transparently)

Key features

• A cryptographic hash is one-way: there is no key, secret, or process that reverses it back to the input — this is the property that makes it correct for passwords
• Encryption is two-way by design: it exists so an authorized holder of the key CAN recover the original — the opposite property from what a password needs
• Purpose-built password hashes (bcrypt, scrypt, Argon2) are deliberately slow and memory-hard, which makes brute-forcing every possible password prohibitively expensive
• General-purpose hashes (MD5, SHA-256) are built for speed — billions of hashes per second on commodity GPUs — which makes them fast for an attacker to brute-force, not just for you to verify
• A per-password random salt (built into bcrypt/scrypt/Argon2 by default) stops an attacker from using one precomputed rainbow table against every stored hash at once

Command

import bcrypt

# hash once, at signup -- salt is generated
# and stored inside the returned hash itself
hashed = bcrypt.hashpw(password.encode(), bcrypt.gensalt())
# store `hashed` (bytes) in the database

# verify at login -- never decrypt, always re-hash and compare
bcrypt.checkpw(login_attempt.encode(), hashed)  # -> True / False

Key features

• A KMS (e.g. AWS KMS, Google Cloud KMS) manages keys as a service — applications call an API to encrypt/decrypt or to get a data key, and never see or store the underlying key material directly
• An HSM (Hardware Security Module) is dedicated tamper-resistant hardware that generates and stores keys such that they cannot be exported in plaintext, even by administrators — used directly, or as the backing layer under a KMS
• Envelope encryption is the common pattern: a KMS-held master key encrypts a per-object "data key," and the data key (not the master key) encrypts the actual data — this avoids sending bulk data through the KMS itself
• Key rotation replaces a key on a schedule (e.g. annually, or immediately after suspected compromise) so a leaked or aging key has a bounded window of usefulness to an attacker
• Separation of duties means the person or role that can decrypt data is not the same person or role that controls audit logging of decrypt events — one compromised or malicious actor should not be able to both act and erase the record of acting

Command

// Envelope encryption with a KMS
1. app calls KMS.GenerateDataKey(masterKeyId)
   -> KMS returns { plaintextKey, encryptedKey }
2. app encrypts the actual data with plaintextKey
   (locally, never sends bulk data to the KMS)
3. app discards plaintextKey from memory,
   stores encryptedKey alongside the data
4. to decrypt later: app calls
   KMS.Decrypt(encryptedKey) -> plaintextKey
   (only succeeds if the caller's IAM role
   is authorized to use masterKeyId)