Applied Cryptography

AES (Advanced Encryption Standard) in Galois/Counter Mode — the standard for symmetric encryption. Uses a single shared key for both encryption and decryption. GCM provides both confidentiality and integrity (authenticated encryption). 256-bit key is the recommended size.

"Secrets in the database are encrypted with AES-256-GCM. The encryption key is stored in a KMS, not in the application config. Each encrypted value stores the IV (initialisation vector) alongside the ciphertext — the IV is unique per encryption, preventing identical plaintexts from producing identical ciphertexts."

Public-key cryptography using mathematically related key pairs. RSA is based on integer factorisation; ECC (Elliptic Curve Cryptography) provides equivalent security with shorter keys (256-bit ECC ≈ 3072-bit RSA). Used for key exchange, digital signatures, and TLS.

"TLS certificates use ECDSA (EC-based signatures) rather than RSA for new deployments — the 256-bit key is smaller, handshakes are faster, and the security margin is equivalent to 3072-bit RSA. RSA-2048 is still accepted for compatibility but RSA-4096 is the minimum we issue for new certificates."

The protocol establishing an encrypted TLS connection. TLS 1.3 (1-RTT): client sends supported cipher suites and key share; server selects cipher, sends its key share and certificate; client verifies certificate and the encrypted session begins. Faster and more secure than TLS 1.2.

"TLS 1.3 reduced our API handshake latency by 100ms vs. TLS 1.2 — 1 round trip instead of 2. The server certificate chain is validated against our trusted CA bundle, OCSP checks the certificate hasn’t been revoked, and the ephemeral key exchange enables Perfect Forward Secrecy (PFS)."

The property that a session key cannot be derived from the server’s long-term private key. Ephemeral Diffie-Hellman key exchange generates a unique session key per connection — compromising the server private key does not decrypt past sessions.

"We enforce PFS by requiring ECDHE (ephemeral) cipher suites. An attacker recording encrypted traffic today cannot decrypt it later even if they eventually obtain our server private key — each session had its own ephemeral key pair, discarded after the session. TLS 1.3 mandates PFS; TLS 1.2 does not."

A CA is a trusted entity that signs digital certificates. An X.509 certificate binds a public key to an identity (domain, organisation) with the CA’s signature. Browsers and clients trust certificates signed by CAs in their trust store.

"Let’s Encrypt is our CA for public-facing services. The certificate chain: Let’s Encrypt root CA → intermediate CA → our leaf certificate. Clients validate the chain by verifying each signature up to a trusted root. Our internal services use our own private CA (HashiCorp Vault PKI) for mTLS — no commercial CA involvement."

A function that derives a cryptographic key from a source (password or master key). PBKDF2 and bcrypt are for password hashing (slow by design). Argon2 (winner of PHC) is the modern standard. HKDF derives keys from existing key material.

"Password hashing uses Argon2id with memory cost 64MB, 3 iterations, parallelism 4. The parameters are tuned so each hash takes ~100ms on our hardware — affordable for users but expensive for attackers. The salt is generated per-password; the stored hash includes the salt. Migrating from bcrypt was justified by Argon2’s better resistance to GPU attacks."

A dedicated hardware device that generates, stores, and uses cryptographic keys. Keys never leave the HSM in plaintext. Used for root CA key ceremonies, high-value signing operations, and payment processing (PCI-DSS compliance).

"The root CA private key lives in an HSM. Signing operations (issuing certificates) are performed inside the HSM — the key never leaves. For PCI compliance, the payment encryption key hierarchy has the KEK (Key Encryption Key) in an HSM. The FIPS 140-2 Level 3 certification required by our payment processor mandates HSM storage."