up:: Foundations MOC
Why Does Strong Cryptography Still Fail?
When people picture a cryptographic disaster, they imagine a lone genius in a dark room finally cracking the math, an unbreakable cipher yielding to a cleverer equation. I spent 8 years as a cryptographer, and the real record looks almost nothing like that. The ciphers usually held. What gave way was everything around the math. Code that ran it shipped with bugs, operators took forbidden shortcuts, trusted authorities got breached, and secret keys walked out the door. The biggest cryptographic failures on record broke at the human seams, in the narrow space where good math meets ordinary organizations.
That pattern is the most useful thing I can hand a team preparing for the quantum transition, because it tells them where their real risk lives. The story people tell about quantum is a pure-math story, Shor’s algorithm dissolving RSA, and that story is true as far as it goes. History says the decisive failures land one layer out from the algorithm, and the transition will land there too. Here are five well-documented cases, spanning more than 80 years, and the seam each one broke.
The bug that leaked the keys
In April 2014 the internet learned that a single missing check in OpenSSL had been quietly handing out server memory to anyone who asked. The flaw, named Heartbleed, lived in OpenSSL’s implementation of the TLS heartbeat extension, a small keep-alive feature.1 A peer could claim it was sending a short message while asking for as much as 64 kilobytes back, and the server would return whatever happened to be sitting in that memory, including private keys, session tokens, and user passwords.1
The RSA and TLS mathematics involved were entirely sound. The whole break came from a few lines of C that trusted a length field without confirming it matched the data actually sent, so affected versions from OpenSSL 1.0.1 through 1.0.1f leaked memory on demand.1 A server could run a perfectly strong cipher and still surrender the very private key that cipher depended on. This is the implementation seam, the distance between a correct algorithm and correct code that runs it, and it is the same territory where side-channel analysis does its work.
The keys anyone could guess
A well-meaning change to the same library had produced a quieter catastrophe 6 years earlier. In May 2008 Debian disclosed that a maintainer had removed a couple of lines from its OpenSSL package back in 2006, trying to silence a warning from a memory-analysis tool.2 Those lines fed unpredictable data into the random number generator that cryptographic key generation relies on. With them gone, nearly the only varying input left was the process ID, which on Linux tops out around 32,768 values.2
The result was that every RSA, DSA, and SSH key generated on an affected Debian or Ubuntu system for roughly 20 months came from a pool of about 32,000 possibilities of a given type and size, small enough for an attacker to enumerate in an afternoon.2 The math for RSA and DSA stayed exactly as strong as ever; the randomness underneath it, the thing that makes a specific key unguessable, had silently collapsed. This one carries a supply-chain fingerprint on top of the implementation one, because the weakness entered downstream in a distribution’s patch to upstream code, the kind of dependency that hides inside vendor-controlled surfaces.
The authority that vouched for a lie
In the summer of 2011 an intruder worked his way into a Dutch certificate authority called DigiNotar and used it to issue more than 500 fraudulent certificates, among them a wildcard certificate valid for Google.3 A certificate authority exists to keep one promise, that a given public key genuinely belongs to who it claims. The attacker turned that promise into a weapon, and the forged Google certificate was used to intercept the traffic of an estimated 300,000 users, almost all of them in Iran.3
Every one of those forged certificates validated perfectly in a browser, because each was signed by a key the world had been told to trust. The mathematics of the signatures did precisely what they were meant to do. The failure sat in governance, with weak internal security, a poorly segmented network, and detection so thin that the rogue certificates circulated before anyone caught them.3 Once the breach was understood, DigiNotar’s roots were pulled from browser and operating-system trust stores, and the company fell into bankruptcy within weeks. This is the PKI seam, where a certificate’s math is only ever as trustworthy as the human institution issuing it.
The signature that was perfectly real
The Stuxnet worm that surfaced in 2010 carried a detail that unsettled everyone who understood code signing. Its kernel drivers were signed with genuine, valid digital certificates stolen from two hardware companies, Realtek Semiconductor and JMicron, both based in the same science park in Taiwan.4 Code signing lets a vendor sign its software with a private key so a machine can confirm the code is authentic before running it.
Windows checked those signatures, found them cryptographically valid, and loaded the malicious drivers without a warning, exactly as designed, because the private keys behind the signatures had been taken from their rightful owners.4 The verification worked flawlessly and produced the wrong answer, since a signature only proves authorship while the signing key stays secret. The seam here is key management, which is an operational and physical problem, about where keys live and who can reach them, long before it is a mathematical one.
The oldest lesson, from before the transistor
The pattern is older than software. The clearest case I know is more than 80 years old, and it toppled one of the strongest ciphers of the Second World War. The German high command encrypted its most sensitive teleprinter traffic with the Lorenz SZ machine, which the codebreakers at Bletchley Park called Tunny, and its mathematics were genuinely formidable for the era. What opened it was an operator.
In August 1941 a German operator transmitted a message of about 4,000 characters, and when it arrived garbled, the receiving station asked him to send it again. He resent it using the same secret wheel settings, a shortcut the rules plainly forbade, and he typed the second version a little differently, abbreviating a few words along the way.5 That handed Bletchley two long messages enciphered under one identical key, a gift the cryptographers called a depth. John Tiltman pulled the raw key stream out of the pair, and William Tutte then reconstructed the entire internal structure of a machine the British had never laid eyes on.5 The cipher’s math held to the end. The break came from an operator repeating himself and from the predictability that repetition created, the same shape as every modern case above.
The seam is where the work is
Line these five up and one shape repeats across more than 80 years: strong cryptography, defeated at the point where it touched people, code, and institutions. Heartbleed and Debian broke on implementation. DigiNotar broke on governance. Stuxnet broke on key custody. Tunny broke on operator procedure. In each, the algorithm was a bystander to its own defeat, and the real control surface was the human and organizational system wrapped around it.
That is exactly why the quantum transition rewards the same attention. The math half is genuinely close to solved, the replacement algorithms are standardized, and a capable engineer can deploy them. The decisive questions are the ones the cases keep pointing at. Someone has to actually own the migration, which is the whole of cryptographic ownership. The new implementations have to be sound rather than merely present. The CA signing keys have to move on a real schedule, and the vendors who control most of the footprint have to ship. When migrations stall, they stall on those human seams, which is the argument of why post-quantum migrations stall and the psychology underneath it.
So the truest thing I can tell you about protecting data, in 1941 or in 2035, is that the mathematics is rarely the part that fails you. Give the human system around the cipher the same care you would give the cipher itself, and you close the seams where real cryptographic disasters have always come in.
The precedent
The Enigma machine was cryptographically strong for its era and it was never defeated as a piece of mathematics. It was defeated by the way it was used. German procedure required a doubled message key at the start of each transmission, which handed the Polish Cipher Bureau a structural foothold in the early 1930s. Messages opened with predictable formats and closed with standard sign-offs, and daily weather reports carried near-identical content, so Bletchley could guess plaintext and search against it. The machine’s reflector meant no letter could ever encrypt to itself, which discarded most candidate settings for free. And operators under pressure chose three-letter keys that were adjacent on the keyboard, or left the rotors where the previous shift had set them.
Enigma operational failures, 1932–1945
The moral: the cipher was never the weak part. The practice around it made the traffic readable.
A post-quantum migration inherits this exactly. ML-KEM and ML-DSA will hold, and the failures will come from a fallback left enabled for one partner, a key rotation nobody scheduled, a negotiation that quietly downgrades, and a parameter set chosen once and never revisited. None of those appear in an algorithm review, and all of them are visible on the wire. The German cryptographers were not wrong about their machine. They were measuring the wrong layer, and the layer they were not measuring was the one being read.
Everything here is the map, given freely. When your team needs the human side of the transition planned and run as carefully as the cryptography, so that ownership, implementation discipline, and vendor and key governance get the same rigor as the math, that’s the work I do.
Last verified 2026-07-26 · Updated 2026-08-25 · Maintained by Addie LaMarr, LaMarr Labs.
Footnotes
-
CVE-2014-0160 (Heartbleed), National Vulnerability Database, nvd.nist.gov; OpenSSL Security Advisory, “TLS heartbeat read overrun (CVE-2014-0160),” 7 April 2014, openssl.org. ↩ ↩2 ↩3
-
CVE-2008-0166, National Vulnerability Database, nvd.nist.gov; Debian Security Advisory DSA-1571-1, “openssl predictable random number generator,” 13 May 2008, debian.org. ↩ ↩2 ↩3
-
Fox-IT, “Black Tulip: Report of the investigation into the DigiNotar Certificate Authority breach,” commissioned by the Dutch government, 2012, rijksoverheid.nl. The interim findings, including the estimate of roughly 300,000 unique users targeted via the fraudulent *.google.com certificate and their concentration in Iran, were first published by Fox-IT in September 2011. ↩ ↩2 ↩3
-
N. Falliere, L. O Murchu, E. Chien, “W32.Stuxnet Dossier,” Version 1.4, Symantec Security Response, February 2011, broadcom.com. The stolen Realtek Semiconductor and JMicron Technology code-signing certificates are documented in the driver-analysis section. ↩ ↩2
-
B. Jack Copeland (ed.), “Colossus: The Secrets of Bletchley Park’s Codebreaking Computers,” Oxford University Press, 2006. The August 1941 depth that gave Tiltman the key and enabled Tutte’s reconstruction of the Lorenz machine is also recorded in the “General Report on Tunny” (1945), released by the UK National Archives under references HW 25/4 and HW 25/5. ↩ ↩2