Crypto misuse

Cryptographic Misuse

Rules (for AI agents)

ALWAYS

• Use the language / platform's cryptographic library. Python: cryptography, secrets. JavaScript: Web Crypto, crypto.webcrypto, Node crypto. Go: crypto/*, golang.org/x/crypto. Java: JCE/Bouncy Castle. .NET: System.Security.Cryptography.
• Use a cryptographically secure RNG: Python secrets.token_bytes / secrets.token_urlsafe, JS crypto.getRandomValues / crypto.randomBytes, Go crypto/rand.Read, Java SecureRandom.
• Hash passwords with a slow KDF tuned for ~100 ms on production hardware: argon2id (preferred, RFC 9106 parameters: m=64 MiB, t=3, p=1), scrypt (N=2^17, r=8, p=1), or bcrypt (cost ≥ 12). Always with a per-user random salt.
• Encrypt with AEAD (authenticated encryption): AES-256-GCM, ChaCha20-Poly1305, or AES-256-GCM-SIV. Generate a fresh random nonce per encryption.
• Use TLS 1.2+ (TLS 1.3 strongly preferred). Disable TLS 1.0/1.1, SSLv3, RC4, 3DES, and export ciphers.
• Compare MACs / signatures / tokens with constant-time helpers: hmac.compare_digest, crypto.subtle.timingSafeEqual, subtle.ConstantTimeCompare, MessageDigest.isEqual, CryptographicOperations.FixedTimeEquals.
• For asymmetric keys: RSA ≥ 3072 bits, ECDSA P-256 or P-384, Ed25519, X25519.

NEVER

• Use MD5 or SHA-1 for signatures, certificates, password storage, or message authentication. (They remain valid for incidental non-security uses like ETag / file deduplication if explicitly documented.)
• Use DES, 3DES, RC4, or Blowfish for new code.
• Use ECB mode. Use CBC without HMAC over the ciphertext. Use CTR/GCM with a reused nonce.
• Use unsalted hashes for passwords. Use sha256(password) for password storage — it's a fast hash; brute force is trivial.
• Use Math.random(), Python random, rand() in C / Go for tokens, IDs, nonces, or passwords. They are predictable.
• Hardcode IVs/nonces, salts, or keys. Never reuse a GCM/Poly1305 nonce under the same key.
• Compare secrets with ==, ===, strcmp, bytes.Equal — these are timing-leaky.
• Roll your own crypto (custom XOR, custom HMAC, custom Diffie–Hellman, custom signature schemes). Use audited primitives.

KNOWN FALSE POSITIVES

• MD5 / SHA-1 in non-security contexts: HTTP ETag computation, content deduplication, cache keying for non-sensitive data, fixture fingerprinting. Annotate these uses with a // non-security use: ... comment.
• Test vectors and KAT (Known Answer Test) values intentionally hardcode IVs, keys, and plaintexts — they belong in tests/ not production.
• Legacy interop: some industry / government protocols still require specific legacy ciphers. Document the exception and isolate behind a feature flag.

Context (for humans)

NIST SP 800-131A Rev. 2 is the authoritative US-government deprecation roadmap for algorithms; OWASP's storage cheat sheet is the practical "do these things" companion. The recurring failure modes are: fast hash for passwords (CWE-916), predictable RNG for tokens (CWE-338), broken cipher choice (CWE-327), and non-constant-time comparison of secrets (CWE-208).

AI assistants tend to mirror whatever crypto example was popular on Stack Overflow circa 2014, which means lots of sha256(password) and AES-CBC with manual padding. This skill is the counterweight.

Verify & lock (triaging a finding)

A scanner/review hit is a candidate, not a confirmed bug. Confirm it, fix it, then lock it so it can't come back.

1. Confirm it's real (inspect the behavior/values, not a browser). Read the primitive at the call site and prove the weakness: encrypt repeated plaintext and show ECB yields identical ciphertext blocks; show the IV/nonce/salt is static, hardcoded, or reused across calls; confirm the digest is MD5/SHA-1 or that passwords go through a fast hash (sha256(pw)) instead of a salted KDF; trace the key/RNG source — a literal key, Math.random/random/rand(), or an undersized RSA/EC key is the bug; for compares, confirm ==/strcmp/ bytes.Equal over a secret instead of a constant-time helper. Rule out the known FPs first (MD5/SHA-1 ETag/dedup, test KAT vectors, flagged legacy interop).
2. Fix, then lock with a regression test (unit or integration — dev's call): assert encrypting the same plaintext twice gives different ciphertext (fresh random IV/nonce); the algorithm/mode resolves from an allowlist (AEAD, no ECB/DES/RC4); password verify uses the slow KDF with a per-user salt; keys load from a secret store (not a literal) and meet the size floor; secret comparison routes through the constant-time helper — plus a benign positive case (correct key/password/MAC still verifies). Commit it to CI so the guard can't be silently dropped in a later refactor.

References

• rules/algorithm_blocklist.json
• rules/key_size_minimums.json
• NIST SP 800-131A Rev. 2.
• OWASP Cryptographic Storage Cheat Sheet.
• CWE-327 — Broken or risky crypto.
• CWE-916 — Insufficient computational effort for password hash.