Cryptography in production rarely fails because the algorithm is broken. AES-256-GCM is fine. RSA-2048 is fine for most uses. Argon2id is fine. The failures come from how these algorithms are used: ECB mode where GCM should be, no IV randomization, hardcoded keys, missing authentication tag verification, mode mismatches between encrypt and decrypt paths. Detecting these requires parameter-aware analysis at the call site, not library-level scanning. It is one of the places where Griffin AI's deterministic engine + Griffin reasoning approach diverges visibly from Mythos-class general-purpose AI-for-security tools.
What "crypto misuse" actually means
Five common patterns, all of which appear in real production code:
- Wrong mode for the job. AES-ECB used for messages longer than one block.
- Reused or predictable IVs. GCM with the same nonce on multiple messages with the same key — catastrophic for confidentiality.
- Missing authentication. AES-CBC encryption without a separate MAC, or with the MAC verified after decryption rather than before.
- Weak parameters. RSA below 2048 bits, ECB mode, MD5 or SHA-1 in security-relevant contexts, key derivation with insufficient iterations.
- Hardcoded secrets. Keys, IVs, or salts baked into source code.
Each of these compiles cleanly. Each passes a basic library-level scan that just checks "is the AES library imported?" Detection requires looking at how the library is called, not whether it is called.
Where pure-LLM tools struggle
Mythos-class tools that analyse code at the function level can recognise hardcoded secrets and weak algorithm names from training data. The pattern recognition works.
The structural failures happen on parameter awareness:
- A
Cipher.getInstance("AES")call in Java defaults to ECB mode. The model has to know this default to flag it. - A
crypto.createCiphercall in Node.js without an explicit IV uses a derivation that is broken-by-design. The model has to know this, and has to recognise the absence of an explicit IV. - A
cipher.doFinal(data)call in Java without verifying the GCM authentication tag is a mistake. The model has to track that doFinal returns plaintext including any forgery the attacker constructed.
Each of these requires parameter-aware reasoning and library-default knowledge. LLMs can have this knowledge but do not reliably apply it across all call sites.
How Griffin AI handles it
Three deterministic steps:
Library-default tracking. The engine maintains a registry of cryptographic library defaults across major languages. Java's Cipher.getInstance("AES") defaults to AES-ECB. Python's Crypto.Cipher.AES.new(key, mode) requires an explicit mode. Node.js's crypto.createCipheriv requires an IV; createCipher derives one and is deprecated. Each library's behaviour is encoded.
Parameter flow analysis. When a cryptographic call is detected, the engine traces backward to determine where each parameter (mode, key, IV, salt, iteration count) comes from. Hardcoded values are flagged. Derivable values (predictable counters, time-based IVs) are flagged.
Pair tracking. Encrypt-decrypt pairs in the same codebase are checked for consistency. A function that encrypts with AES-CBC and a function that decrypts with AES-GCM (or vice versa) is a finding even if both sides individually look correct.
The output is a finding annotated with the specific misuse class, the parameter that is wrong, and the suggested fix.
Concrete examples
Two patterns from real customer codebases:
Pattern 1. A Spring Boot service uses Cipher.getInstance("AES") to encrypt session tokens. The default mode is ECB, which leaks structure for any token longer than 16 bytes. Griffin AI surfaces this with the specific recommendation to use "AES/GCM/NoPadding" and provides the IV-management pattern.
Pattern 2. A Node.js service uses crypto.createCipheriv("aes-256-cbc", key, iv) for encryption and crypto.createCipheriv("aes-256-gcm", key, iv) for decryption. The mismatch was introduced during a refactor; both sides individually look correct. Griffin AI surfaces the mismatch.
A sink-first scanner flags the AES calls but doesn't distinguish between safe and unsafe parameter combinations. A pure-LLM tool catches some patterns and misses others depending on what the model recognises.
Coverage across crypto-related issues
Parameter-aware analysis applies to:
- Symmetric encryption — mode, IV, padding, authentication.
- Asymmetric encryption — key size, padding scheme, hash function.
- Hashing — algorithm choice, salt, iteration count, work factor.
- Random number generation —
Math.randomfor security purposes, predictable seeding, non-cryptographic RNG. - Key derivation — PBKDF2 iterations, Argon2 parameters, scrypt cost factor.
- JWT signing — algorithm choice, none-algorithm acceptance, kid validation.
- TLS configuration — version, cipher suite, certificate validation.
Each follows the same parameter-flow pattern.
What to evaluate
Three concrete checks:
- Show the platform a
Cipher.getInstance("AES")call. Is the ECB-by-default behaviour flagged? - Show the platform a hardcoded HMAC key. Is the hardcoding flagged with the specific parameter named?
- Show the platform an encrypt-decrypt pair where the modes don't match. Is the mismatch identified across the two functions?
The answers separate platforms that understand cryptographic primitives from platforms that recognise cryptographic library names.
How Safeguard Helps
Safeguard's crypto-misuse detection is built around library-default tracking and parameter-flow analysis across major languages and crypto libraries. Findings include the specific misuse class, the parameter at fault, and a fix recommendation that respects the existing API surface. Griffin AI's reasoning step adds context about why the misuse matters — confidentiality vs integrity vs forward secrecy — so engineers triaging the finding understand the threat model. For organisations whose code has been touched by multiple generations of engineers using different conventions, this is one of the highest-leverage detection categories.