In the 1990s, the United States government classified strong encryption as a munition and required export licenses for cryptographic software shipped overseas. To meet export controls, software vendors built versions of TLS that used deliberately weakened cryptography: 512-bit RSA, 56-bit DES, and 512-bit Diffie-Hellman parameters that could be broken with the computing power available to nation-states. The export restrictions were largely lifted by 2000, but the weakened crypto did not entirely disappear. Code paths and configuration options for export-grade ciphers remained in TLS implementations and in deployed servers, mostly forgotten.
In 2015, two attacks demonstrated that this forgotten code was still active. FREAK, disclosed in March 2015 as CVE-2015-0204, exploited a TLS state machine bug that let an attacker downgrade connections to use export-grade RSA. Logjam, disclosed in May 2015, used a similar downgrade trick to force connections to use export-grade Diffie-Hellman, then broke the resulting weak handshake using precomputed mathematical work. Together, the two attacks affected an estimated tens of thousands of public web servers and required substantial cleanup work across the Internet.
This post examines both attacks, explains the mathematical and protocol details that made them possible, and draws lessons for how cryptographic transitions should handle the long tail of legacy support. The post-quantum migration in particular needs to avoid the trap that the export-grade crypto era set for the TLS ecosystem.
The Export Era Background
US export controls on cryptography in the 1990s split TLS implementations into two flavors. The unrestricted flavor used 1024-bit or 2048-bit RSA, 1024-bit Diffie-Hellman, and 128-bit symmetric ciphers, which is what we would consider normal cryptography today. The export flavor used 512-bit RSA, 512-bit Diffie-Hellman, and 40-bit or 56-bit symmetric ciphers, which were deliberately set at levels considered breakable by US intelligence agencies.
Major web browsers shipped with both sets of ciphers. The browser advertised the unrestricted ciphers when the export controls did not apply and the export ciphers when they did. The TLS handshake negotiated which set to use. Servers responded based on their configured cipher suite list.
When the export restrictions were lifted in 2000, the strong crypto became standard. The export-grade ciphers were not removed from the protocol, however. They remained as supported ciphersuites in the TLS specifications, and many servers and clients continued to advertise them for compatibility. Nobody actively used them, but the code paths and configuration entries were still there, dormant.
FREAK: Factoring RSA Export Keys
FREAK stood for Factoring RSA Export Keys. The attack was published by Karthikeyan Bhargavan and a team of researchers including Benjamin Beurdouche, Alfredo Pironti, Pierre-Yves Strub, and Cedric Fournet. The technical paper, "A Messy State of the Union: Taming the Composite State Machines of TLS," appeared at IEEE S&P 2015.
The attack exploited a state machine bug in OpenSSL and several other TLS implementations. A correctly implemented client requesting normal RSA key exchange should reject any server response that uses RSA-EXPORT, the export-grade variant. The vulnerable implementations did not perform this check. They accepted RSA-EXPORT responses regardless of what the client originally requested.
This let an attacker on the network perform the following downgrade. The client connects and offers strong RSA. The attacker, sitting between client and server, modifies the offered ciphersuites to include only RSA-EXPORT. The server agrees to RSA-EXPORT and generates an export-grade RSA ephemeral key, typically 512 bits. The attacker passes this through to the client. The client, due to the state machine bug, accepts the 512-bit RSA without error.
Now the attacker has the client encrypting the pre-master secret under a 512-bit RSA key. Factoring 512-bit RSA in 2015 was achievable. The Logjam team demonstrated factoring on Amazon EC2 in roughly seven hours for $75 in cloud cost. With the factored key, the attacker decrypts the pre-master secret, derives the same session keys as both endpoints, and now reads or modifies the encrypted traffic.
The vulnerable client base was substantial. Major browsers including Safari, Internet Explorer, and BlackBerry browsers had the state machine bug. Android's default TLS stack was vulnerable. The OpenSSL versions widely deployed on Linux servers were vulnerable in their client mode.
Logjam: Diffie-Hellman in the Crosshairs
Logjam, published in May 2015 by Adrian Bhargavan, Beurdouche, and others, took a similar approach but targeted Diffie-Hellman key exchange instead of RSA. The technical paper, "Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice," was presented at CCS 2015.
The Logjam attack had two phases. The first phase was the downgrade. Like FREAK, the attacker manipulated the TLS handshake to force the use of DHE_EXPORT, the export-grade Diffie-Hellman variant. This used a 512-bit prime modulus, in contrast to normal Diffie-Hellman which uses 1024-bit or 2048-bit moduli.
The second phase was the cryptanalysis. Breaking a 512-bit Diffie-Hellman key exchange requires solving the discrete logarithm problem in a 512-bit group. The number field sieve algorithm, the fastest known approach for this problem, has a key property: the bulk of its computational cost depends on the prime modulus, not on the specific session keys.
The Logjam team observed that real-world TLS deployments overwhelmingly used a small number of standard 512-bit primes, hardcoded in libraries or configuration files. By performing precomputation against those standard primes, the team built tables that turned the per-session attack into a relatively quick lookup. The precomputation cost weeks of CPU time, but once done, individual handshakes could be broken in roughly 90 seconds.
The implications extended beyond export-grade Diffie-Hellman. The Logjam paper also analyzed the security of normal 1024-bit Diffie-Hellman. The team estimated that breaking a single 1024-bit prime would cost a few hundred million dollars in compute, well within the reach of nation-state adversaries. Because real-world TLS deployments shared a small number of standard 1024-bit primes, breaking those primes once would compromise vast numbers of past and future TLS connections that used them.
The Logjam paper accelerated the migration to elliptic-curve Diffie-Hellman, which uses different mathematics where the per-prime precomputation does not apply, and to larger prime moduli for any deployments that retained traditional DH.
The Mitigation
The fix for FREAK was straightforward in principle: remove the state machine bug and ensure clients reject RSA-EXPORT responses unless they were specifically requested. OpenSSL released patched versions in March 2015. Apple, Google, Microsoft, and other major vendors patched their TLS stacks in their March-April 2015 update cycles.
The fix for Logjam was more involved. Server administrators had to update their TLS configurations to remove DHE_EXPORT ciphersuites entirely. The OpenSSL and Apache documentation was updated to recommend specific cipher strings that excluded the export ciphers. Browser vendors raised the minimum acceptable Diffie-Hellman prime size, with Mozilla settling on 1024 bits and Google going to 1024 bits and then later 2048 bits.
Some vendors and protocols moved to mandatory ECDHE for forward-secret key exchange, eliminating the traditional DH issue entirely. ECDHE uses elliptic curves where the per-prime precomputation that broke Logjam does not apply, and where standard curves like P-256 and Curve25519 have well-studied security properties.
Internet scanning in the months after Logjam disclosure found tens of thousands of vulnerable servers. The cleanup took years. Some embedded devices, network appliances, and legacy systems continued to expose export-grade Diffie-Hellman well into 2017 and beyond.
What the Attacks Teach
FREAK and Logjam together illustrate several principles that have become standard guidance for cryptographic protocol design.
Removed features should be removed completely, not deprecated. Export-grade ciphers were officially deprecated for years before FREAK and Logjam exploited them. The deprecation status did not protect users because the code paths remained active and configurable. The lesson is that cryptographic features deemed insecure should be removed from implementations, not just left as fallback options.
Downgrade protection requires explicit signaling. RFC 7507 introduced TLS_FALLBACK_SCSV, a signaling mechanism that lets clients indicate they are deliberately falling back from a preferred protocol version. Servers that receive this signal can refuse the connection if they detect the fallback was forced rather than necessary. TLS 1.3 incorporates downgrade protection directly into the protocol.
Shared cryptographic parameters create shared vulnerabilities. The fact that real-world Diffie-Hellman deployments used a small number of standard primes amplified the impact of Logjam dramatically. Modern recommendations include either rotating primes regularly, using primes large enough to resist precomputation attacks, or using ECDHE which sidesteps the issue.
State machines must be explicit and verifiable. The FREAK bug was a state machine error: the client did not check that the server's response matched what the client had requested. Modern protocol implementations use formal models of their state machines and tools like miTLS and Tamarin to verify protocol-level invariants.
What This Means for Post-Quantum Migration
The post-quantum migration is currently in a phase that resembles the late 1990s for cryptography. Multiple candidate algorithms are being deployed in parallel. Hybrid modes combine post-quantum and classical primitives. Different deployments use different parameter sets and different combinations of primitives. Some early deployments used algorithms that have since been broken or weakened, like Rainbow and SIKE, which were withdrawn from the NIST process after cryptographic attacks reduced their security.
The Logjam-FREAK lesson for the post-quantum era is that early deployments will need careful management as the standards mature. The NIST FIPS 203 and 204 standards, finalized in 2024, define the parameter sets that should be used. Deployments using earlier draft parameters or using Round 3 algorithms that did not make the final standard need to be migrated.
The hybrid approach used by QNSQY combines ML-KEM with X25519 for key encapsulation and ML-DSA with Ed25519 for signatures. This dual-algorithm structure provides defense in depth: a weakness in either component does not compromise the overall security as long as the other component remains secure. To understand the hybrid construction, see Hybrid Encryption.
The hybrid construction does come with the responsibility to manage both primitives correctly. If a future weakness in ML-KEM is found, deployments need to be able to update to a stronger post-quantum primitive. If X25519 is eventually broken by quantum computers, the post-quantum component must hold up alone. Cryptographic agility is essential.
For broader context on post-quantum cryptography, see What is Post-Quantum Cryptography?.
The Long Tail Problem
Both Logjam and FREAK had long tails of vulnerable systems that persisted for years after disclosure. The pattern is consistent across cryptographic vulnerabilities: a fraction of deployed systems will not receive timely patches because they are operationally difficult to update, financially unmotivated to update, or simply forgotten.
For embedded devices, the long tail can be permanent. A network appliance from 2010 with no vendor support cannot receive a patch. The device continues to operate, with whatever cryptographic vulnerabilities it has from its original firmware, until it is physically retired.
For cloud infrastructure, the picture is better. Major cloud providers patch their managed services aggressively. Customer-managed services on cloud platforms vary, with sophisticated customers patching quickly and others lagging.
For the post-quantum migration, the long tail problem is significant. Devices deployed today will continue to operate for ten to twenty years. If they rely solely on classical cryptography and become subject to harvest-now-decrypt-later attacks, the data they handle will eventually be readable by future adversaries. Hybrid deployment from the start gives those devices a path forward without requiring firmware updates.
To understand the harvest-now-decrypt-later threat, see Harvest Now, Decrypt Later. For specific concerns about RSA-2048 in particular, see Why RSA-2048 Will Break.
The Internet Cleanup
The cleanup after Logjam involved coordinated work across many parties. The team that disclosed Logjam published a remediation guide that walked server administrators through the steps to disable export-grade ciphers and to use proper Diffie-Hellman parameter generation. The IETF accelerated work on TLS 1.3, which removed all the legacy ciphersuites that had enabled the attacks.
OpenSSL 1.0.2 and later included improved default configuration that made it harder to accidentally enable export-grade ciphers. Web server configuration guides from Mozilla, Cloudflare, and others were updated to specify modern, safe cipher strings.
The Logjam team also released a tool called Logjam Test that let server administrators check whether their deployments were vulnerable. The tool became part of standard server administrator workflows for years afterward.
For the post-quantum migration, similar coordinated work is in progress. The NIST PQC standards published in 2024 give vendors a clear target. The IETF TLS working group is actively designing post-quantum hybrid ciphersuites. Browser vendors are deploying hybrid ECDHE+ML-KEM in production traffic to a fraction of users to gather operational data.
FAQ
Are FREAK and Logjam still relevant in 2025? The specific attacks are not directly exploitable against modern systems because export-grade ciphers have been removed from TLS implementations and most deployed servers. Embedded devices and unmaintained systems may still expose vulnerable configurations. The lessons about downgrade protection and feature removal remain directly applicable.
Did the export controls actually weaken the Internet for decades? Yes. The export-grade ciphers introduced for compliance with US export controls in the 1990s remained as latent vulnerabilities into the 2010s. The cleanup after FREAK and Logjam took years and required updates to clients, servers, libraries, and standards.
How did Logjam's precomputation attack work? The number field sieve algorithm for discrete logarithms has a precomputation phase that depends only on the prime modulus, not on the specific session keys. By precomputing against the standard 512-bit primes used in DHE_EXPORT, the team turned subsequent attacks into much faster lookups against the precomputed tables.
Is ECDHE immune to similar attacks? ECDHE uses elliptic curves where the precomputation phase that broke Logjam does not have an equivalent. Different attack mathematics apply. The standard NIST curves and Curve25519 are well-studied and considered safe at their advertised security levels for current adversaries. Quantum computers would break ECDHE, which is why the post-quantum transition is necessary.
How does QNSQY avoid the export-grade trap? QNSQY does not have a fallback mode for weaker cryptography. There is no export-grade option, no compatibility mode for older versions, no downgrade path. The hybrid construction always uses both ML-KEM and X25519 at full strength. Any failure in either component fails the entire operation rather than silently weakening the overall security.
Sources
- Bhargavan, K. et al. "A Messy State of the Union: Taming the Composite State Machines of TLS." IEEE S&P 2015. https://hal.archives-ouvertes.fr/hal-01114250/document
- Adrian, D. et al. "Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice." CCS 2015. https://weakdh.org/imperfect-forward-secrecy.pdf
- CVE-2015-0204 (FREAK), CVE-2015-4000 (Logjam). https://cve.mitre.org/
- Moeller, B. and Langley, A. "TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks." RFC 7507. https://www.rfc-editor.org/rfc/rfc7507
- Rescorla, E. "The Transport Layer Security (TLS) Protocol Version 1.3." RFC 8446. https://www.rfc-editor.org/rfc/rfc8446
- NIST FIPS 203 and FIPS 204. 2024. https://csrc.nist.gov/
Related Articles
- Why RSA-2048 Will Break
- Harvest Now, Decrypt Later
- Hybrid Encryption
- What is Post-Quantum Cryptography?
- ML-KEM Explained
Protect Your Data Before Q-Day Arrives
QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats.