🔒 Cryptography Vulnerabilities in AI-Generated Code
AI-generated code may introduce significant risks in the domain of cryptography if not carefully reviewed. Large Language Models (LLMs) are trained on vast datasets that often contain outdated, insecure, or misused cryptographic examples. Because these models prioritize patterns over security, they tend to reproduce code that "looks correct" but is fundamentally unsafe.
Below we analyze the most frequent cryptographic flaws that LLMs generate, why they happen, how they amplify risks, insecure vs. secure code samples, CWE references, and services that can help mitigate them.
1. Use of Weak or Broken Algorithms
LLMs frequently recommend broken algorithms such as MD5, SHA-1, or DES. This occurs because these algorithms dominate older tutorials and code samples in the training data. By suggesting them, LLMs propagate obsolete practices, exposing systems to collisions, brute-force, and preimage attacks.
AI Insecure Example (Java):
MessageDigest md = MessageDigest.getInstance("MD5");
byte[] hash = md.digest(password.getBytes());
Safe Solution (Java):
String hash = BCrypt.hashpw(password, BCrypt.gensalt());
Detection: SonarQube static analysis rules, expert Source Code Review.
2. Poor Randomness or Key Generation
LLMs often suggest predictable random number generators like Math.random() or Random() with fixed seeds.
This happens because examples of "simple random" are more common than cryptographic-grade randomness in training datasets.
The result: AI-generated code produces predictable keys and tokens, making authentication and encryption trivial to break.
AI Insecure Example (Java):
Random rand = new Random(1234);
byte[] key = new byte[16];
rand.nextBytes(key);
Safe Solution (Java):
SecureRandom sr = new SecureRandom();
byte[] key = new byte[16];
sr.nextBytes(key);
Detection: SonarQube randomness rules, Source Code Review.
3. Hard-Coded or Reused Cryptographic Keys
Since many open-source snippets include hard-coded keys for simplicity, LLMs replicate this dangerous practice. Developers copying such AI outputs risk embedding permanent secrets directly in their code, leading to catastrophic leaks when repositories are exposed.
AI Insecure Example (C#):
string secretKey = "mySecretKey123";
Encrypt(data, secretKey);
Safe Solution (C#):
string secretKey = Environment.GetEnvironmentVariable("ENCRYPTION_KEY");
Encrypt(data, secretKey);
Detection: Repository scanning, Source Code Review, SCA tools.
4. Misuse of Cryptographic Libraries
LLMs copy-paste patterns like AES in ECB mode or missing initialization vectors because those appear in legacy code online. The AI cannot distinguish between secure and insecure usage, causing developers to implement crypto that is functionally correct but insecure in practice.
AI Insecure Example (Java):
Cipher cipher = Cipher.getInstance("AES/ECB/PKCS5Padding");
Safe Solution (Java):
Cipher cipher = Cipher.getInstance("AES/GCM/NoPadding");
Detection: Software Composition Analysis, Source Code Review.
5. Disabled Certificate or TLS Validation
Because test code examples online frequently disable SSL validation for convenience, LLMs reproduce this anti-pattern. AI suggests "accept all certificates," which if deployed to production, allows trivial man-in-the-middle interception.
AI Insecure Example (Java):
TrustManager[] trustAllCerts = new TrustManager[]{
new X509TrustManager() {
public void checkClientTrusted(...) {}
public void checkServerTrusted(...) {}
public X509Certificate[] getAcceptedIssuers() { return null; }
}
};
Safe Solution (Java):
SSLContext sc = SSLContext.getInstance("TLS");
sc.init(null, null, new SecureRandom());
Detection: Source Code Review, TLS security audits.
6. Improper Padding and Error Handling
LLMs generate encryption code without secure padding or with improper error handling (e.g., exposing detailed crypto exceptions). This can lead to padding oracle attacks, enabling attackers to decrypt data without knowing the key.
AI Insecure Example (Python):
cipher = AES.new(key, AES.MODE_CBC)
plaintext = cipher.decrypt(ciphertext) # no padding check
Safe Solution (Python):
cipher = AES.new(key, AES.MODE_GCM, nonce=os.urandom(12))
plaintext = cipher.decrypt_and_verify(ciphertext, tag)
Detection: Source Code Review, SCA, cryptography-focused audits.
7. Insufficient Key Length
Many training examples use short keys (e.g., 56-bit DES or 128-bit RSA) simply because they run faster in demonstrations. LLMs replicate this unsafe practice, leading developers to unknowingly generate encryption that can be brute-forced with modern hardware.
AI Insecure Example (RSA):
KeyPairGenerator kpg = KeyPairGenerator.getInstance("RSA");
kpg.initialize(512); // insecure
Safe Solution (RSA):
KeyPairGenerator kpg = KeyPairGenerator.getInstance("RSA");
kpg.initialize(2048); // secure
Detection: SonarQube static analysis, Source Code Review.
⚙️ How Our Services Can Help
We provide end-to-end assistance in securing AI-generated and manually written code:
- SonarQube Setup Assistance: Configuration of rules to detect weak crypto, hard-coded keys, and disabled TLS checks.
- Source Code Review: Expert cryptography engineers validate complex cases that automated tools miss.
- Software Composition Analysis: Detects insecure libraries, outdated dependencies, and licensing risks.
- Software Licence Analysis: Ensures open-source license compliance and reduces legal risks.
By combining automation (SonarQube, SCA) with expert reviews, we ensure that insecure AI-suggested cryptographic code never reaches production.