In March 2015, a team of researchers showed they could sit between your browser and a bank, force the connection down to encryption weak enough to break for about a hundred dollars, and read everything. The weakness they exploited wasn’t a new bug. It was a policy decision from 1992 that everyone thought had been switched off around the turn of the millennium. It hadn’t. It had just been sitting in the code, dormant, for fifteen years, waiting for someone to turn it back on.
This is the story of export-grade cryptography — the closest thing we have to a controlled experiment in what happens when a government mandates a deliberately weakened encryption mode “for the good guys.” The experiment ran for two decades. The result is unambiguous, and it is worth remembering every time the idea comes back, which it does, roughly once a legislative session.
The law that shipped a backdoor
Until 1996, the United States classified strong cryptography as a munition — the same export category as fighter jets and guided missiles, under the State Department’s arms-control regime. You could use good crypto at home, but shipping it abroad required an arms-export license you weren’t going to get. The practical compromise the industry struck was ugly and specific: software sold internationally had to cripple its own encryption. RSA key exchange was capped at 512 bits. Symmetric ciphers were capped at 40 bits. Netscape literally shipped two builds, a “U.S. edition” and an “International edition,” and the international one was breakable by design.
Breakable by whom, exactly? That was the point. A 40-bit key or a 512-bit RSA modulus was beyond what a hobbyist could crack in 1995 but comfortably within reach of an intelligence agency with a room full of hardware. The export ciphers were a legibility guarantee: foreign traffic would stay readable to the people who wrote the rules. Call it what it was — a lawful-access backdoor, negotiated into the protocols themselves. SSL 3.0 and TLS 1.0 carry the fingerprints in their cipher suite lists to this day: the suites with EXPORT in the name, RSA_EXPORT and DHE_EXPORT, the deliberately feeble ones.
The crypto wars mostly ended in the software industry’s favor. Daniel Bernstein sued the government, arguing source code was speech protected by the First Amendment, and the Ninth Circuit’s handling of Bernstein v. United States helped knock the legal footing out from under the export regime. Crypto moved from the State Department’s munitions list to Commerce Department control in 1996, and in 2000 the rules were relaxed enough that mass-market and open-source software could ship real encryption. The war was won. Everyone went home.
And nobody deleted the code.
Dead crypto is not gone crypto
Here is the thing that turns a resolved policy fight into a fifteen-years-later security disaster: the export cipher suites were never ripped out of the implementations. Why would they be? They still worked. Some old client somewhere might still ask for one. Removing code is scary and thankless, and “we support an extra cipher suite nobody negotiates anymore” doesn’t feel like a vulnerability. It feels like backward compatibility.
So OpenSSL kept the export suites. Apple’s SecureTransport kept them. Microsoft’s SChannel kept them. Servers kept advertising them. A capability built to satisfy a 1990s regulation quietly rode along in the world’s TLS stacks into the 2010s, off but not absent — the software equivalent of a decommissioned door that’s still in the wall, unlocked, just painted over. In 2015 two research teams walked up and gave it a push.
FREAK: factoring keys the government sized for you
The first push was FREAK — Factoring RSA Export Keys, CVE-2015-0204, disclosed on March 3, 2015 by the miTLS group at INRIA and Microsoft Research. It began as one of a family of TLS state-machine bugs: a large number of clients, it turned out, would accept a message they had never asked for. Specifically, if a server sent a ServerKeyExchange containing a weak 512-bit export RSA key, a vulnerable client would take it — even though the client had offered only strong, normal RSA and there was no legitimate reason for that message to exist in the handshake.
That bug is the pry bar. The attack goes like this. You get in the middle of a connection. When the client sends its ClientHello asking for strong RSA, you rewrite it to request RSA_EXPORT instead. The server — if it still supports export suites, and a third of them did — happily obliges and signs a 512-bit ephemeral RSA key. The buggy client accepts the weak key as though everything is normal. Now you have a 512-bit RSA modulus standing between you and the plaintext, and 512-bit RSA has not been safe for a very long time.
How unsafe? The researchers factored one on Amazon EC2 in about 7.5 hours for roughly $104 of compute. Other estimates put it under twelve hours for about fifty dollars. And there was a brutal force-multiplier: many servers generated a single export-grade key when the process started and reused it for every connection until restart. Factor it once — one afternoon, one hundred dollars — and you can impersonate that server or decrypt its export sessions for as long as it stays up. A scan of roughly 14 million HTTPS sites found that about 36% of browser-trusted servers still supported the export RSA suites that made this work. Not obscure servers. A third of the trusted web, carrying a weakness commissioned in the Clinton administration.
Logjam: the same idea, but worse where it counts
Two and a half months later, in May 2015, came Logjam (CVE-2015-4000), from a larger team spanning INRIA, Microsoft Research, Johns Hopkins, Michigan, and Pennsylvania. Logjam did to Diffie-Hellman what FREAK did to RSA — a man-in-the-middle downgrade to the 512-bit DHE_EXPORT suites — and on the surface it’s the same story. But the mechanism underneath is more alarming, and it’s the part worth internalizing.
Breaking Diffie-Hellman means solving the discrete logarithm problem for a given prime. The best known method, the number field sieve, has a property that is either elegant or terrifying depending on which side you’re on: the overwhelming bulk of the work depends only on the prime itself, not on any particular key exchange. You do one gigantic precomputation for a prime, and afterward each individual connection using that prime can be broken quickly. The cost is front-loaded and then amortized across every session that shares the prime.
Now recall how Diffie-Hellman parameters actually got deployed. Nobody generates their own prime; it’s fiddly and easy to get wrong, so implementations ship defaults. For 512-bit export DH, a handful of hardcoded primes — baked into Apache, into mod_ssl — covered almost everything. The Logjam team found that a single precomputation against the most common 512-bit prime let them attack 80% of the servers that supported DHE_EXPORT. One prime, cracked once, unlocked the overwhelming majority of the vulnerable internet. About 8.4% of the top million HTTPS sites were exposed.
And then the researchers did the math on the size everyone actually used for real Diffie-Hellman: 1024 bits. A 1024-bit precomputation is enormously more expensive — beyond academic budgets, into the range of a nation-state building special-purpose hardware over a year or more. But it is not impossible, and here is the kicker: just like the 512-bit case, most of the internet leaned on a tiny number of common 1024-bit primes. Precompute against one of them, once, and you could passively decrypt a meaningful fraction of the world’s HTTPS, VPN, and SSH traffic — no per-connection break-in, just quietly reading. The leaked intelligence-community documents describing large-scale VPN decryption suddenly had a mechanism that fit. It wasn’t proof. It was a blueprint that matched the reported capability so well that “we don’t know how they’d do it” stopped being an honest thing to say.
What the experiment actually proved
Line the two attacks up and the moral isn’t “512-bit crypto is weak.” Everyone knew that in 1998. The moral is about what happens to a deliberately weakened mode over time, and it comes in two parts.
First: a weakness built for one adversary is a weakness for every adversary, eventually. The export ciphers were engineered so that a specific, powerful, presumptively-lawful actor could read specific traffic. There is no cryptographic construction that grants that power to one party and withholds it from everyone else — a 512-bit key doesn’t check the attacker’s credentials. Once the weak mode exists in shipping software, the only thing standing between it and a graduate student with a cloud account is the cost of hardware, and the cost of hardware only goes one direction. The gap between “only the NSA can break this” and “anyone with $100 can break this” was about twenty years, which is to say it was one career.
Second: you cannot switch a capability off by not using it. The export suites were “retired” in the sense that healthy clients stopped negotiating them around 2000. They were not retired in the sense that mattered — removed from the code, refused by servers, made impossible. Fifteen years of dormancy ended the instant someone found a state-machine bug and a willingness to rewrite a ClientHello. Dead code that can still be reached is not dead. It’s a loaded weakness with the safety painted over.
This is why the recurring proposals for “responsible” or “lawful-access” encryption — a key escrow here, a mandated weak mode there, always with assurances that only the good guys will hold the keys — deserve to be met with FREAK and Logjam printed out and slid across the table. We already ran this experiment. We mandated a weakened mode for the good guys, in the actual protocols, for two decades. It did not stay confined to the good guys, it did not stay in its era, and cleaning it up took years of coordinated work across every major TLS implementation on earth — work that is, in the grand scheme, still not fully done, because there is always one more stack with the old suites still compiled in.
The 1990s got to make a decision about cryptography that the 2010s had to pay for. That’s the part that should stay with you. The people who mandate a backdoor and the people who eventually walk through it are almost never the same people, and the second group doesn’t need permission from the first.