In February 2017, Google and the CWI Amsterdam research institute produced two different PDF files with an identical SHA-1 hash, ending any argument that SHA-1 collisions were purely theoretical. The attack, dubbed SHAttered, took roughly 9,223,372,036,854,775,808 SHA-1 computations — about 6,500 CPU-years — and it was the direct result of algorithms that cryptographers had been warning about since 2005. Weak cryptography vulnerabilities are not exotic: they show up as MD5 password hashes, 512-bit RSA keys left over from export-grade restrictions in the 1990s, AES used in ECB mode, and random number generators with too little entropy. Each one quietly undermines confidentiality or integrity guarantees that an application depends on. This glossary post breaks down what qualifies as weak or broken cryptography, walks through real incidents — Adobe's 2013 breach, Logjam, SWEET32 — and explains how security teams can find these flaws before attackers do.
What counts as a weak cryptography vulnerability?
A weak cryptography vulnerability is any use of a cryptographic algorithm, key size, or implementation that no longer provides the protection it claims to, and it maps to three CWE categories: CWE-327 (Use of a Broken or Risky Cryptographic Algorithm), CWE-326 (Inadequate Encryption Strength), and CWE-338 (Use of Cryptographically Weak PRNG). CWE-327 covers algorithms like DES, RC4, and MD5 for integrity or password storage — DES's 56-bit keyspace was brute-forced in 22 hours by the EFF's "Deep Crack" machine back in 1999, and it has only gotten faster since. CWE-326 covers correct algorithms used with insufficient parameters, such as 512-bit or 1024-bit RSA keys; NIST's SP 800-131A formally disallowed 1024-bit RSA and 80-bit symmetric-equivalent strength for federal systems starting in 2014. CWE-338 covers predictable randomness, which breaks session tokens, nonces, and key generation even when the underlying cipher is sound. All three are static, code-level conditions — they exist whether or not an exploit is currently in the wild, which is why scanners flag them long before a CVE is assigned.
Why does a 2008 Debian bug still matter to cryptography audits today?
It matters because CVE-2008-0166 shows how a single line of removed entropy code can silently downgrade every key generated on affected systems for two years. In May 2008, Debian and Ubuntu maintainers were found to have inadvertently stripped the entropy-gathering code from OpenSSL's random number generator while cleaning up compiler warnings, reducing the effective keyspace for SSH and SSL keys to roughly 32,767 possible values per key type and architecture. Every key generated on Debian-based systems between September 2006 and May 2008 was affected, and researchers built complete lookup tables of every possible key within days of disclosure. The incident is still taught in security training because it demonstrates that weak cryptography isn't only about algorithm choice — a correct algorithm fed insufficient entropy is just as broken, and the flaw can sit undetected in production for years before anyone audits the PRNG source.
How did Adobe's 2013 breach expose 153 million passwords without a single hash being cracked?
It happened because Adobe encrypted passwords with 3DES in ECB mode instead of hashing them, and ECB mode leaves identical plaintext blocks as identical ciphertext blocks, so attackers didn't need to break the encryption at all. When Adobe disclosed the breach in October 2013, security researchers noticed that accounts sharing the same password produced identical encrypted values, letting them cluster the 153 million leaked records by password reuse and cross-reference the largest clusters against Adobe's own password hints, which were stored in plaintext alongside the encrypted data. Within a week, researchers had recovered the top hundred-plus passwords in the dataset — "123456" alone appeared over 1.9 million times — without ever touching the 3DES key. The lesson generalizes beyond passwords: any deterministic, unauthenticated block cipher mode (ECB in particular) leaks structural information about the plaintext, which is exactly why NIST guidance and PCI-DSS both explicitly prohibit ECB mode for sensitive data.
Can attackers really force a modern TLS connection to use 1990s-era encryption?
Yes — that's precisely what the Logjam attack (CVE-2015-4000), disclosed in May 2015, demonstrated against Diffie-Hellman key exchange. Logjam exploited leftover "export-grade" cipher suites, capped at 512-bit DH by 1990s U.S. export law, to trick a TLS client and server into negotiating a weak key exchange even when both sides supported stronger options. Researchers found that a single precomputed table for one commonly reused 512-bit prime let them break the resulting session key in under a minute, and at disclosure time an estimated 8.4% of the top one million HTTPS domains were vulnerable. Logjam sits alongside FREAK (CVE-2015-0204, disclosed March 2015, same export-cipher root cause) and POODLE (CVE-2014-3566, disclosed October 2014, which exploited SSLv3's padding to decrypt one byte at a time) as a family of downgrade attacks — proof that protocol negotiation logic, not just the cipher itself, is part of the cryptographic attack surface.
Does key size alone guarantee safety once an algorithm passes a certain bit length?
No — block size matters too, and SWEET32 (CVE-2016-2183, disclosed August 2016) proved it by targeting 3DES and Blowfish, both of which use a 64-bit block regardless of key length. Researchers Karthikeyan Bhargavan and Gaëtan Leurent showed that once roughly 785GB of data passes over a single 3DES-encrypted TLS or VPN connection, the birthday bound on 64-bit blocks produces colliding ciphertext blocks with high enough probability to recover plaintext fragments, including HTTP cookies. Major browsers and OpenSSL responded by deprecating 3DES cipher suites in 2016–2018, but the underlying lesson persists: a "strong" key length wrapped around an outdated block size is still a weak-cryptography finding, which is why CWE-327 audits check block size and mode alongside key length rather than key length in isolation.
How do security teams actually find weak cryptography before attackers exploit it?
Security teams find it through static analysis that flags specific API calls and constants — MD5(), DES.new(), Random() used for security tokens, RSA key generation calls under 2048 bits — combined with dependency and configuration scanning that catches inherited weak defaults in libraries and TLS configs. Because these vulnerabilities are deterministic code patterns rather than runtime behaviors, they are well suited to SAST and SCA tooling: a scanner can flag every MD5 call and every sub-2048-bit RSA key generation in a codebase in minutes, and infrastructure scanners can flag TLS listeners that still permit SSLv3, export ciphers, or 3DES. The harder problem is prioritization — a large codebase might return hundreds of "weak crypto" findings, and not all of them touch data that ever leaves the process or reaches an untrusted boundary.
How Safeguard Helps
Safeguard's platform is built to close the gap between finding a weak-cryptography finding and knowing whether it matters. Griffin AI triages CWE-327, CWE-326, and CWE-338 findings against the actual data flow around them, distinguishing an MD5 checksum on a static asset from an MD5 hash protecting stored credentials. Reachability analysis confirms whether the vulnerable cryptographic call is ever invoked on a path reachable from an entry point, cutting through noisy scanner output so teams fix the calls that matter first. Safeguard's SBOM generation and ingest capabilities track which dependencies bundle deprecated algorithms like DES, RC4, or MD5 as defaults, giving teams visibility across every service that pulls in a given library. When a fix is available — upgrading a hashing call, bumping a key size, or switching a cipher mode — Safeguard opens an auto-fix pull request so engineering teams can remediate without a manual audit of every call site.