Cheatsheet
A condensed reference for everyday crypto decisions: which primitive to pick, which library, which dangers to refuse. Pin it next to the security cheat sheet.
Crypto choices in one page
EXAMPLE
# ===== Hashing (general-purpose) ===== # Use: SHA-256 / SHA-3-256 / BLAKE3 # Avoid: MD5 / SHA-1 for anything security relevant # ===== Password hashing ===== # Use: Argon2id (preferred). bcrypt cost >= 12 if argon2 not available. # Avoid: SHA-256, SHA-3, custom 'salted hash + lots of rounds' # ===== Symmetric encryption ===== # Use: AES-256-GCM. ChaCha20-Poly1305 on mobile / older CPUs. # Avoid: AES-CBC without HMAC, AES-ECB, DES, 3DES, RC4 # ===== Key derivation ===== # Use: HKDF for deriving multiple keys from a master. # Argon2id for password-derived keys. # Avoid: SHA(password + salt) manual derivation. # ===== Asymmetric encryption ===== # Use: X25519 ECDH + AEAD (libsodium boxes do both) # Avoid: RSA-PKCS1v1.5 padding (use RSA-OAEP if RSA at all) # ===== Digital signatures ===== # Use: Ed25519 (deterministic, fast, no nonce-reuse risk) # Avoid: ECDSA without RFC 6979 deterministic nonces # ===== Randomness ===== # Use: secrets.token_bytes (Py) / crypto.randomBytes (Node) / Random.org for stones # Avoid: random.random(), Math.random(), rand(), java.util.Random for security # ===== Constant-time compare ===== # Use: hmac.compare_digest (Py), crypto.timingSafeEqual (Node), subtle (Go), hash_equals (PHP) # Avoid: == on secrets, MACs, tokens # ===== JWTs ===== # Use: RS256 / EdDSA with hardcoded alg list and audience check # Avoid: 'alg: none', HS256 against a public key, accepting any alg from the header # ===== TLS ===== # Use: TLS 1.2 + TLS 1.3 only, modern cipher suites, strong key exchange # Avoid: TLS 1.0/1.1, RC4, 3DES, MD5 in handshakes, sslmode=prefer for DB clients # ===== Webhook signatures ===== # Use: HMAC-SHA256 over the body + timestamp; constant-time compare; 5-min window # Avoid: 'shared secret' in a query parameter; no timestamp; non-CT compare # ===== Cookies ===== # Use: Secure + HttpOnly + SameSite=Lax (or Strict) on session cookies # Avoid: cookies without Secure on HTTPS sites; SameSite=None without Secure # ===== Library cheat sheet ===== # Python cryptography + argon2-cffi + pyjwt # Node node:crypto + argon2 + jose # Go crypto/* stdlib + golang.org/x/crypto/argon2 + golang.org/x/crypto/curve25519 # Rust ring or RustCrypto crates + ed25519-dalek + argon2 # PHP sodium_* + password_hash + hash_equals + openssl_* where sodium does not cover # Java Bouncy Castle + bcprov for argon2 + JDK crypto # ===== Patterns that LOOK safe but are NOT ===== # - Encrypt-then-don't-authenticate (use AEAD instead) # - Roll-your-own AES-CBC with custom IV scheme # - 'We use https everywhere' as the only line of defence # - 'We use AES-256, so we're safe' (the mode + AEAD matter more than key size) # - 'We pinned the cert in v1.0' (then never rotated it) # ===== Rotation ===== # - TLS certs: rotate annually (Let's Encrypt is 90 days, automate it) # - HMAC secrets: rotate when staff leaves; trust BOTH old+new during overlap # - JWT signing keys: rotate yearly OR on compromise; publish via JWKS endpoint # - Database creds: dynamic via Vault or short-lived via OIDC # ===== Audit signal ===== # Trust libraries with public audits (ring, libsodium, BoringSSL, BouncyCastle). # A library without a published audit is asking you to trust without verification. # In crypto, that is the worst trade you can make.
Why it matters
When you have to choose between a familiar primitive and an audited library, choose the library. Libsodium, ring, BoringSSL, and the RustCrypto crates have been examined by people whose full-time job is to find bugs in them. The "elegance" or "performance" of a hand-rolled version is never worth the audit budget you skip.
Tip: Tweak the snippet with Try it Yourself », then sit the quiz at the bottom of the page.
Example
Example
// CSPRNG | AES-GCM / ChaCha20-Poly1305 | argon2id passwords | HKDF for derivation // Ed25519 signatures | HMAC with timingSafeEqual | TLS 1.3 + HSTSTry it Yourself »
Discussion
Loading…