Cryptography Checklist

This page distills the whole foundation into one actionable checklist. It is meant to be used, not just read: when you design a system, write code that touches crypto, or review someone else’s, run down these lists. The items are grouped to mirror the foundation’s sections so you can trace any check back to the page that explains why it matters.

Why This Matters

Cryptographic mistakes are quiet. Nothing crashes, tests pass, and the padlock still appears, right up until an attacker demonstrates otherwise. A checklist converts hard-won knowledge into a repeatable defense that does not depend on remembering every attack under deadline pressure.

Algorithm and Parameter Quick Reference

Use this as the default answer to “which algorithm and what size?”

Purpose	Use	Avoid
Symmetric encryption	AES-256-GCM or ChaCha20-Poly1305 (AEAD)	ECB, unauthenticated CBC/CTR, DES, RC4
Hashing	SHA-256, SHA-384, SHA-3	MD5, SHA-1
Password storage	Argon2id, scrypt, bcrypt	Plain SHA, unsalted hashes
Key derivation	HKDF (from keys), Argon2 (from passwords)	Raw passwords as keys
Asymmetric keys	Ed25519 / X25519, or RSA-3072+	RSA-1024, custom curves
Signatures	Ed25519, ECDSA P-256, ML-DSA (PQC)	MD5/SHA-1 signatures
Key exchange	ECDHE (X25519), hybrid X25519+ML-KEM	Static RSA key transport, non-ephemeral DH
Randomness	OS CSPRNG (getrandom, os.urandom, crypto/rand)	rand(), time-seeded PRNGs
TLS	1.3 (or 1.2 with ECDHE+AEAD)	TLS 1.0/1.1, CBC suites

Encryption and Data (Attacks & Pitfalls)

• All encryption uses an AEAD mode (GCM or ChaCha20-Poly1305), never ECB or unauthenticated CBC.
• Every nonce/IV is unique per key, from a CSPRNG or a guaranteed-unique counter.
• No home-rolled cipher, mode, or MAC anywhere in the codebase.
• Decryption returns one generic, constant-time error; no distinguishable padding failures.
• Secrets, tokens, and MACs are compared in constant time.

Keys and Randomness (Symmetric and Asymmetric)

• Keys come from a proper KDF, not from raw passwords or predictable inputs.
• Randomness comes from the OS CSPRNG in every path that needs it.
• Private keys are stored encrypted at rest, ideally in an HSM or KMS.
• Key rotation and revocation procedures exist and are tested.
• Symmetric keys are 256-bit and hashes are 384-bit where post-quantum resistance matters.

PKI and TLS (PKI & TLS)

• TLS 1.3 is the default; 1.0 and 1.1 are disabled and CBC suites are off.
• Servers present the full chain (leaf plus intermediates), not just the leaf.
• Hostnames are in the SAN extension; certificate verification is never disabled in code.
• Certificate expiry is monitored with alerts well before notAfter.
• mTLS trust stores are scoped to the specific issuing CA, and identity drives authorization.

Post-Quantum Readiness

• Long-lived confidential data is inventoried against harvest-now-decrypt-later risk.
• Hybrid key exchange (X25519 plus ML-KEM) is enabled where the stack supports it.
• The NIST PQC roadmap (ML-KEM, ML-DSA) is tracked for dependencies.

Verifying a Certificate Against the Checklist

cd ~/crypto-lab
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -ext subjectAltName -dates -checkend 604800

Expected output:

X509v3 Subject Alternative Name:
    DNS:*.example.com, DNS:example.com
notBefore=Jan 15 00:00:00 2026 GMT
notAfter=Jan 15 23:59:59 2027 GMT
Certificate will not expire

-checkend 604800 confirms the certificate is valid for at least another week, exactly the expiry check the PKI list demands. Pair this checklist with the sibling Further Reading page when you want the reasoning behind a check, and Next Learning Path for where to apply it.

Practical Guidance

1. Keep this checklist in your pull-request template so crypto-touching changes cannot merge without running it.
2. When in doubt on an algorithm, default to the quick-reference table’s “Use” column and justify any deviation in writing.
3. Automate the mechanical checks (TLS version, cipher suites, certificate expiry) with scanners rather than relying on human review.
4. Treat any unchecked box as a blocker, not a suggestion; crypto failures rarely announce themselves.
5. Revisit the post-quantum section periodically, since the recommended hybrid groups and standards are evolving quickly.