A Hobbyist Factored a 1990s Certificate Authority in 61 Hours. The Nostalgic Coverage Is Missing the Actual Story.

A hobbyist with a Ryzen 9 5950X desktop and 61 hours of CPU time just published the private keys of a Certificate Authority that once shipped in Netscape 4.51. He factored two 512-bit RSA roots from E-Certify, a defunct Canadian CA that was removed from browser trust stores in 2002. He then built a custom Go TLS server — because no modern TLS stack supports SSLv3 with 40-bit RC4-MD5 — and demonstrated that the recovered private keys would sign valid certificates accepted by a real copy of Netscape running in a VM with its clock set to the year 2000.

The reaction on Hacker News was warm and nostalgic. People marveled at the digital archaeology. The original Netscape product manager appeared in the thread to explain that weak keys were deliberate: the NSA required export-grade cryptography to be decipherable, and the government enforced that requirement on every browser vendor selling outside the United States. The thread collected over 400 points in twelve hours and generated careful technical discussion about the gap between 512-bit and 1024-bit RSA, the cost of factoring at various key sizes, and the role of quantum computing in the long-term future of RSA.

I found the reaction more troubling than the hack itself. The dominant framing — ancient keys, zero practical impact, fun weekend archaeology — is exactly the story the security industry tells itself to avoid looking at the structural rot underneath. The specific certificates are expired and revoked. But the mechanisms that make expiry and revocation meaningful are the same mechanisms that are quietly failing on certificates that are neither expired nor revoked. The E-Certify story is not history. It is a preview.

What 512-bit RSA Actually Tells Us About 1024-bit RSA

The author did not just crack an antique. He demonstrated a factoring pipeline — CADO-NFS on consumer hardware — that is now routine for sub-1024-bit RSA. The work required 32 hours for the first E-Certify key and 29 hours for the second. Steve Weis, a researcher who factored the VeriSign test root mentioned in the same post, used a GPU cluster and finished in approximately one hour. CADO-NFS is open source, freely available, and actively maintained. The barrier to entry for 512-bit RSA factoring is now a fast desktop computer and two days of patience.

The natural next question is what 1024-bit RSA costs. The author quoted Weis’s estimate directly in the HN comments: approximately 2,000 GPU-years. That number sounds prohibitive until you do the arithmetic on contemporary infrastructure. OpenAI trained GPT-4 on roughly 25,000 A100 GPUs for approximately 90 days. A well-funded attacker running 2,000 GPUs for a year — renting that capacity from a major cloud provider — would spend somewhere between $5 million and $15 million depending on instance type and negotiated rates. One commenter in the thread pointed out that if you have access to 100,000 Blackwell GPUs, the scale reportedly used in training a frontier model, you could factor a 1024-bit key in roughly seven days.

These numbers describe a threat profile that is firmly within the operational range of nation-states, serious criminal organizations backed by state resources, and large intelligence agencies. They are not within reach of an individual with a desktop. But the jump from 512-bit (individual, desktop, two days) to 1024-bit (organization, significant budget, months) is smaller than the jump that separated 512-bit from being theoretical a decade ago. Progress in both algorithms and hardware is not linear, and the trajectory has consistently surprised people on the optimistic end.

The gap between RSA-260 (factored this week at 862 bits) and 1024-bit RSA is about 4 bits of symmetric equivalent security. The factoring challenge series — RSA-220 in 2016, RSA-230 in 2018, RSA-240 in 2019, RSA-260 in 2026 — has been progressing at a rate of roughly 7–10 bits of RSA per two years, driven by both algorithmic improvements in GNFS and hardware improvements. If that rate holds, and there is no strong reason to expect it will slow, the 1024-bit threshold becomes reachable within a decade using hardware that exists today at research-scale. The timeline for nation-state-level factoring of 1024-bit RSA is shorter than the time most enterprise CA root certificates have left in their validity periods.

Here is the part that should concentrate minds: 1024-bit RSA did not disappear from the internet when browsers deprecated it in the early 2010s. It went underground. It persists in embedded devices that have never received a firmware update, IoT sensors in industrial facilities, SCADA systems controlling physical infrastructure, internal enterprise CAs deployed a decade ago and forgotten, code-signing pipelines for legacy software, SSH host keys on servers that have not been rebooted since 2014, and VPN concentrators running software that predates current key size recommendations. NIST deprecated 1024-bit RSA for federal government use in 2010. Sixteen years later, Shodan scans and internet-wide certificate surveys consistently find millions of services still advertising 1024-bit public keys. Many of these keys are not expired. No browser is checking them because they are not in the public WebPKI. Nobody is watching.

Revocation Is the Silent Failure Everyone Is Ignoring

The E-Certify keys were revoked in 2002. When the author demonstrated the recovered private keys against a running Netscape VM, the connection succeeded. Revocation did not stop anything.

The obvious response is that this is not a meaningful test — the certificates are twenty-four years old and no revocation infrastructure is still running to check them. That is true. But it illustrates a principle that applies to revocation generally: revocation is only as reliable as the infrastructure checking it, and that infrastructure is fragile in ways that are consistently underestimated.

X.509 revocation has two primary mechanisms. Certificate Revocation Lists are files that CAs publish listing all certificates they have revoked, signed by the CA. Clients download the CRL and check whether a certificate appears on the list. The problem with CRLs is size and freshness: as CAs grow, CRLs become large files that are expensive to download on every TLS handshake. The solution to size was caching, which created a freshness problem: cached CRLs may be hours or days old, meaning a revoked certificate is still trusted locally until the cache expires. The solution to freshness was OCSP.

OCSP is a protocol for querying a CA’s responder about the status of a specific certificate in real time, rather than downloading the full CRL. This fixes the size and freshness problems but introduces new ones: OCSP checks add latency to every TLS connection, they are a privacy leak (your browser tells the CA which websites you are visiting), and they create a hard dependency on the CA’s responder availability. If the OCSP responder is down, clients must decide whether to fail the connection or proceed. The standard behavior, implemented in both Firefox and most operating system TLS libraries, is soft-fail: if the OCSP responder cannot be reached, the connection proceeds as if the certificate were valid.

Soft-fail means that an attacker who can block OCSP traffic — not a sophisticated requirement; a simple firewall rule or BGP route manipulation accomplishes it — gets a revocation bypass for free. The attacker presents a certificate that has been revoked, blocks the client’s OCSP query, and the client proceeds with the connection. This attack has been demonstrated repeatedly in academic research. It is not theoretical.

OCSP stapling was designed to fix the availability and privacy problems: instead of the client querying the CA, the server fetches a signed OCSP response from its CA and staples it to the TLS handshake. The client receives the revocation status directly from the server, without a separate network round-trip. Stapling eliminates the privacy leak and the latency. But stapling is optional, and many servers do not implement it. When a server does not staple, clients fall back to direct OCSP queries, which reintroduces all the problems stapling was designed to solve.

In 2020, Google announced it was removing real-time OCSP checks from Chrome entirely, citing both the privacy concerns and the performance cost. Chrome now relies on CRLSets: a compressed, curated list of high-priority revocations that Google maintains and pushes to browsers through the component update system. CRLSets are not comprehensive. Google selects which revocations to include based on their judgment of impact and urgency. A certificate revoked by an obscure enterprise CA for an internal application will not appear in CRLSets. A certificate from a major public CA that has been compromised in a way Google considers important will appear. The selection criteria are not public and are not subject to external review.

Firefox retains OCSP checks with soft-fail. The result is a browser ecosystem where Chrome provides no real-time revocation checking for most certificates, and Firefox provides revocation checking that can be bypassed by blocking a single network endpoint. This is the state of certificate revocation in 2026, twenty-five years after OCSP was first standardized.

I have operated TLS infrastructure at companies where the CA’s OCSP responder ran at 99.2% uptime. That 0.8% downtime was distributed across off-hours and random intervals. It was uniformly invisible to end users and silent to the monitoring systems that were watching for certificate errors. Nobody ever noticed, because Firefox soft-fails through OCSP downtime, and Chrome does not check at all. The security property that revocation was supposed to provide — the ability to immediately invalidate a compromised certificate — was not present in either browser for the certificates I was managing. I knew this. The security team knew this. We relied on short certificate lifetimes and rapid reissuance instead. That is not a solution to revocation being broken; it is an acknowledgment that revocation is broken, operationalized as a workaround.

The PKI Trust Model Has a Hidden Assumption

X.509 certificate chains encode a specific trust model: a root CA vouches for intermediate CAs, which vouch for end-entity certificates. The vouching is cryptographic and unforgeable — you cannot produce a certificate that chains to a trusted root without either having access to the root’s private key, or breaking the underlying cryptographic primitive. The trust model assumes both that root keys are kept secret and that the cryptographic primitive is computationally hard to reverse.

The E-Certify story challenges the second assumption directly for a small key size. But the first assumption — root keys are kept secret — is challenged by the revocation problem in a subtler way. If an attacker factors a root key, they can issue fraudulent certificates. Those fraudulent certificates will appear legitimate to every client that trusts the root, unless revocation works reliably enough to propagate the compromise. Given what we know about Chrome’s CRLSet approach and Firefox’s soft-fail OCSP, “reliably enough” is not guaranteed.

Certificate Transparency has substantially improved the situation for publicly-trusted CAs in the WebPKI. Browsers now require that TLS certificates issued by public roots be logged in CT logs before they will be trusted. CT monitoring services alert on unexpected certificate issuances. If an attacker factors a public root CA’s key and issues fraudulent certificates, those certificates will appear in CT logs — unless the attacker avoids submitting them, which is possible because CT submission is enforced by browsers at TLS-handshake time, not by the CA. An attacker issuing fraudulent certificates for use in a targeted attack — not deploying them to public-facing servers that would attract browser connections — can avoid CT logs entirely.

More significantly, CT does not cover privately-trusted CAs. Enterprise internal CAs, government intranet CAs, manufacturing facility CAs, and device manufacturer CAs are all outside the public CT system. These are exactly the CAs most likely to be running on 1024-bit RSA roots, because they were deployed when 1024-bit RSA was standard practice, they have not been audited or updated since, and they are not subject to the CA/Browser Forum requirements that have pushed the public WebPKI toward stronger key sizes and shorter certificate lifetimes.

The Export Crypto History Runs Deeper Than the Anecdote

The Netscape product manager’s comment in the HN thread — that weak keys were required by the NSA — is a reminder that cryptographic weakness in deployed systems is not always the result of ignorance or negligence. Sometimes it is the result of deliberate policy. The US export control regime on cryptography treated strong encryption as a munition, subject to the same export restrictions as firearms and missiles. Software shipped outside the United States was required to use key sizes that the NSA could factor or brute-force. The practical result was SSL implementations with 40-bit symmetric keys and 512-bit RSA for key exchange — keys that were known to be breakable at the time, not keys that became breakable later.

This policy was litigated in the 1990s, most famously through Phil Zimmermann’s prosecution for distributing PGP and Daniel Bernstein’s lawsuit against the State Department. The export restrictions were substantially relaxed in 2000 after the Bernstein case established that cryptographic source code was protected speech under the First Amendment. By that point, the internet had been built on deliberately weak cryptography for six years.

The legacy of export-grade crypto extended long past the policy change. RC4 export suites, DES, and 40-bit key exchange remained negotiable options in SSL and TLS implementations for backward compatibility reasons for another fifteen years. The FREAK attack (2015) and LOGJAM attack (2015) both exploited this: a man-in-the-middle attacker could downgrade a modern TLS connection to export-grade cipher suites, which could then be broken using the GPU clusters that had become affordable by 2015. The vulnerability was not in any code written after 2000. It was in code written before 2000 to comply with a government mandate, retained for compatibility, and finally exploited twenty years after the mandate was lifted.

The pattern is now repeating with 1024-bit RSA. The keys were not weak by policy design — they were the consensus best practice of the late 1990s and early 2000s. But they were deployed in systems that have not been updated, and those systems are not on any public registry. The transition from 512-bit RSA (known broken since 1999) to 1024-bit RSA was not clean: systems using 512-bit keys persisted for years after the academic factorings. The transition from 1024-bit RSA to 2048-bit will be slower because the operational cost is higher and the urgency is less visible. The keys are not broken yet. They are only approaching the point where they become breakable by well-funded adversaries.

History suggests that “well-funded adversaries can break it” and “everyone upgrades” are separated by a gap of five to fifteen years, during which attacks escalate from theoretical to demonstrated to actively exploited before the transition completes. The export-grade crypto timeline ran from “policy change” in 2000 to “actively exploited in FREAK/LOGJAM” in 2015. The 1024-bit RSA timeline is running from “NIST deprecated” in 2010 toward a demonstrated factoring that will be publicly confirmed before 2035, with the exploitation window somewhere in the middle of that interval.

What I Have Actually Seen in Production Environments

I have done infrastructure work at multiple companies where internal CAs were treated as plumbing — configured once, forgotten, renewed manually when someone noticed an expired certificate causing a service outage. The pattern is consistent across companies of different sizes and industries.

The internal root CA key was generated by whoever set up the PKI. In environments provisioned between 2008 and 2014, that frequently meant 1024-bit RSA, because 1024-bit was the default in the tools being used and nobody changed defaults. In some cases the root key was generated on a freshly provisioned server with insufficient entropy in the random number pool, which is a separate problem that compounds the key size issue. The key was then buried in a credential management system or an HSM with documentation that described the HSM’s location but not the key’s properties, and it was not touched again until something broke.

Nobody audits internal CA key sizes the way they audit external certificate configurations. Qualys SSL Labs will report on your public-facing TLS stack. There is no equivalent service for internal CAs, because internal CAs are not accessible from the public internet. Security teams running periodic vulnerability assessments do not always enumerate internal CA key sizes, either because the CA endpoint is not in scope or because the assessment framework does not include a check for it. The result is that 1024-bit internal CA roots can persist in organizations that score well on external security assessments, are SOC 2 certified, and consider themselves security-mature.

I found 1024-bit internal CA roots at companies that considered themselves security-conscious. In one case the CA was signing certificates for internal API endpoints that handled payment processing data. The argument against replacing it was operationally honest: the migration would require reissuing every certificate that chained to the root, updating trust stores on hundreds of hosts across multiple environments, coordinating the cutover across teams that had different deployment cadences, and accepting some service disruption during the transition. Those costs are real, visible, and attributable to the person who initiates the migration. The cost of not migrating is invisible until it becomes a breach, and the attribution at that point is diffuse. Organizations rationally defer this work. That is not a moral failure. It is a consequence of how security costs and security risks are distributed across organizational time horizons.

The Revocation Crisis Will Arrive Before the Factoring Does

There is a sequence of events that is more likely than a dramatic 1024-bit factoring demonstration. A CA — not a public WebPKI CA, but an internal enterprise CA or a device manufacturer CA — is compromised through a conventional attack: a phishing email, a supply chain compromise, or an insider. The attacker obtains the CA’s private key through operational means, not cryptographic means. They begin issuing fraudulent certificates. The certificates are used in a targeted intrusion that runs for months before it is detected.

When the breach is discovered and the CA key is revoked, the revocation propagates through the channels that exist: the CA publishes a CRL and an OCSP response. The affected organization notifies its clients to remove the root from their trust stores. In an enterprise environment, this notification goes to IT administrators, who push the removal through device management systems. The rollout takes days to weeks. During that interval, every device that has not yet received the trust store update continues to trust certificates signed by the compromised CA. Any fraudulent certificate already issued before the revocation is still valid on those devices.

This is not a hypothetical. The DigiNotar compromise in 2011 followed this pattern exactly. A Dutch CA was breached, and the attacker issued fraudulent certificates for Google domains that were used in man-in-the-middle attacks against Iranian dissidents. The compromise ran for weeks before Google’s OCSP stapling implementation flagged an anomaly. Revocation was pushed through browsers rapidly because DigiNotar was a public WebPKI CA and browser vendors could pull the trust anchor quickly. The damage was still significant for the users who were targeted before revocation propagated. And DigiNotar was a public CA, subject to external audit and Browser Forum requirements. An internal enterprise CA compromised the same way has fewer detection mechanisms and slower revocation paths.

The argument for shorter certificate lifetimes — currently being advanced through CA/Browser Forum proposals to move from 398-day to 47-day maximum lifetimes — is a structural response to the revocation problem. If certificates expire in 47 days, the maximum window during which a compromised certificate remains valid is 47 days, regardless of whether revocation works. Shorter lifetimes are the right direction, but they are not a substitute for fixing revocation. They are a reduction in maximum blast radius that acknowledges revocation is not reliably controlling blast radius at all.

Post-Quantum Migration Is Harder and Further Away Than People Want to Believe

The RSA factoring story this week is entirely classical. No quantum computer is involved. Shor’s algorithm would, if implemented on a sufficiently large and stable quantum computer, factor RSA keys in polynomial time rather than sub-exponential classical time. But current quantum computers capable of running Shor’s algorithm against 1024-bit RSA do not exist. The largest demonstrations of quantum factoring have factored small numbers with a handful of qubits. The gap between current hardware and Shor-relevant scale is measured in orders of magnitude of qubit count and error-correction fidelity.

NIST finalized the first post-quantum cryptography standards in August 2024: CRYSTALS-Kyber for key exchange and CRYSTALS-Dilithium for signatures, with Falcon and SPHINCS+ as alternatives. These algorithms are designed to resist both classical and quantum attacks. The migration from classical RSA/ECDSA to post-quantum algorithms is the long-horizon work that security teams need to be planning now, not because quantum computers are imminent threats to RSA, but because the migration will take longer than the threat takes to materialize.

The history of cryptographic transitions is not encouraging about timelines. MD5 was known to be broken for collision resistance in 2004. Certificate authorities were still issuing MD5-signed certificates that were accepted by browsers in 2008 and 2009. SHA-1 was deprecated for certificate signing by the CA/Browser Forum in 2014, with enforcement deadlines that slipped multiple times. SHA-1 certificates were still being accepted by some browsers in 2017. These transitions involved widely-used, highly-visible algorithms where the deprecation was driven by browser vendors with strong leverage over the CA ecosystem. Post-quantum migration involves replacing the key exchange and signature algorithms in every TLS stack, SSH daemon, code signing pipeline, and certificate authority worldwide. The scope is larger, the timeline pressure is lower (because quantum computers are not yet capable of the attack), and the organizational willpower to execute multi-year cryptographic migrations without immediate threat pressure is historically limited.

The right frame for post-quantum migration is not “we have plenty of time.” It is “the transition will take ten to fifteen years from when we start, and the threat will arrive faster than we expect.” Organizations that begin planning now will complete their migrations around the same time organizations that begin planning in five years will be starting theirs. The E-Certify story, and the broader 1024-bit RSA situation, are dress rehearsals for that migration. If we cannot complete the 1024-bit to 2048-bit transition for internal enterprise CAs after sixteen years of NIST deprecation, post-quantum migration for internal infrastructure is going to be a very long project.

What I Actually Predict

Within three years, a public proof-of-concept will demonstrate 1024-bit RSA factoring at a cost under $2 million, using a GPU cluster that is commercially available and can be rented from a public cloud provider. This will not be done by a nation-state. It will be done by a university research group or a well-funded security research team making a public point. The demonstration will be reported as a technical milestone, it will generate a week of coverage in security publications, and most organizations will continue running 1024-bit internal CAs because the remediation cost is real and the threat remains distant.

Within five years, there will be a confirmed breach — not a proof-of-concept, an actual intrusion that causes material damage — that is attributed, after months of forensic analysis, to a factored or stolen 1024-bit RSA internal CA key. The attribution will be contested because the forensic evidence will be ambiguous between classical factoring and conventional key theft. The affected organization will have had internal security recommendations to migrate the CA that were deferred for operational reasons. The breach will finally produce enough organizational urgency to fund and complete the migration that the security team had been requesting for years before the event.

The revocation problem will not be resolved by either of these events. It will be addressed at the margins through continued pressure to shorten certificate lifetimes, mandatory OCSP stapling for specific certificate classes, and incremental improvements to Chrome’s CRLSets. The structural problem — that revocation is a soft-fail system in a context where failure means a breached certificate remains trusted — will persist because fixing it properly requires coordination across all browser vendors, all CAs, and all server operators simultaneously, and that level of coordination has never been achieved in the WebPKI’s thirty-year history.

The E-Certify keys factored this weekend are harmless relics. Nobody is running Netscape 4.51 with a trusting clock set to 2001. But the researcher who factored them used the same tools, the same algorithm, and the same reasoning that someone targeting live infrastructure would use. The distance between “harmless archaeology” and “live threat” is not a difference in technique. It is a difference in which keys you target and whether revocation works well enough to stop you after the fact. On both of those dimensions, the situation is worse than the nostalgic thread on Hacker News made it look.