McPherrin demonstrates that what took a coordinated international team seven months in 1999 can now be done by one person in days using rented cloud hardware. His step-by-step writeup of the general number field sieve — coefficient selection, sieving, linear algebra, square root — is meant to show the factorization is routine, not exotic, and that any 512-bit key still floating around should be treated as fully exposed.
The editorial frames the 1997 Entrust roots as artifacts of an era when 512-bit RSA was the export-controlled ceiling and breaking it was considered a nation-state-scale problem. It argues the sub-exponential scaling of the number field sieve means every generation of hardware compounds the erosion of yesterday's 'adequate' key sizes — a structural warning, not just a historical curiosity.
The editorial notes that both Entrust roots were removed from Mozilla, Microsoft, and Apple trust stores by the early 2010s, so no live TLS handshake today chains to them. The significance is pedagogical and cautionary about key-size lifetimes rather than an active exploit vector against modern browsing.
Security researcher Ryan McPherrin published a writeup showing he factored the 512-bit RSA public keys of two Entrust Certificate Authority roots issued in the mid-1990s — recovering the private keys from nothing but the public certificates that shipped in every browser trust store of that era. The keys weren't stolen, phished, or exfiltrated from a forgotten HSM; they were simply computed, using the general number field sieve on rented cloud hardware.
The two roots in question date from 1997 and were part of the first commercial PKI rollout — the infrastructure that made SSL, and therefore online commerce, possible. At the time, 512-bit RSA was the export-controlled ceiling the U.S. government would allow to leave the country, and even inside the U.S. it was considered adequate for CA roots because the estimated cost to break it was measured in the tens of millions of dollars and required a nation-state. Both roots were long ago removed from Mozilla, Microsoft, and Apple trust stores — the last of them in the early 2010s — so no live TLS handshake today chains to them.
McPherrin's writeup walks through the factorization: coefficient selection, sieving on a modest cluster, the linear algebra step, and the square root that pops out the two primes. He's not the first person to factor a 512-bit key — that milestone dates to 1999, when a team at CWI did it in seven months across hundreds of workstations. What's notable is how routine it has become. A single practitioner, on commodity cloud compute, can now do in days what a coordinated international team needed the better part of a year to accomplish 27 years ago.
The cryptographic community has known 512-bit RSA was dead for a long time. What this writeup makes visceral is the shape of the curve. RSA security scales sub-exponentially — the number field sieve runs in roughly exp((64/9)^(1/3) · (ln N)^(1/3) · (ln ln N)^(2/3)) time — which means every doubling of key size buys you a lot more than double the work, but the constant factor on the outside keeps shrinking as hardware improves and implementations get sharper. The 1999 CWI factorization used custom-tuned code on Alpha and SPARC workstations. Today, `cado-nfs` is an apt-get away and runs on any x86 box you can rent by the hour.
The instructive part isn't that a 30-year-old key fell — it's that the practical cost to break it has dropped roughly six orders of magnitude in that window, and the curve hasn't flattened. 768-bit RSA fell in 2009, took two years of academic effort, and was estimated at roughly 1,500 CPU-years. In 2020, a team factored an 829-bit key. Extrapolating naively, 1024-bit RSA — which some certificate chains and a distressing number of embedded devices still use — is inside the reach of a well-funded adversary today and likely inside the reach of a determined individual by the early 2030s.
The HN thread on the writeup captured the practitioner reaction well: half the comments were engineers noting that their SSH `authorized_keys` file still contains 1024-bit RSA entries from a laptop they built out in 2008, and the other half were people pointing at IoT vendors, industrial control systems, and legacy S/MIME certificates that were signed with keys of that size and treated as immortal. The mental model most developers carry — "if the key was strong when it was generated, it's strong now" — is exactly backwards for asymmetric crypto.
There's also a signal here about the post-quantum transition timeline. NIST finalized ML-KEM and ML-DSA as the first standardized post-quantum algorithms in 2024, and the general industry posture has been "start planning for a 10-15 year migration." That timeline assumed classical attacks on 2048-bit RSA remained impractical. The Entrust demonstration doesn't change the 2048-bit threat model directly, but it does make the point that the classical curve keeps moving, and "we have plenty of time" is a claim that needs continuous re-verification, not an assumption you get to make once.
Grep your infrastructure for anything shorter than 2048-bit RSA and treat every hit as a P1. That includes: SSH host keys (`ssh-keygen -l -f /etc/ssh/ssh_host_*.pub`), user SSH keys (audit `~/.ssh/authorized_keys` across your fleet), TLS certificates on internal services that were never externally audited, code-signing certificates issued years ago and rolled forward without regeneration, S/MIME certificates in your directory, and GPG subkeys on release-signing identities. The `openssl x509 -in cert.pem -text -noout | grep 'Public-Key'` one-liner is your friend here.
For new keys, 2048-bit RSA is the floor, 3072-bit is the reasonable default for anything with a multi-year lifetime, and Ed25519 is what you should be reaching for by default for SSH and any new signing use case where you control both ends. Ed25519 is not post-quantum secure either, but it's smaller, faster, and doesn't have the same key-size scaling anxieties baked into its threat model. The operational win is that key rotation is the mitigation for every one of these classes of risk — if you can't rotate a key in under a day, that's a bigger problem than the key size itself.
For CA and PKI operators specifically, the writeup is a reminder that the trust-store cleanup work the browser vendors did in the 2010s was necessary, not paranoid. Any private PKI still trusting roots older than about 15 years should be treated with suspicion until proven otherwise, and any embedded product with a hardcoded trust anchor from that era is a candidate for a security advisory.
The Entrust factorization is a fire drill for the shift that's actually coming. Post-quantum migration is the headline threat, but the more mundane story is that classical cryptanalysis never stops improving, and every key you generate today has a shelf life. Treat cryptographic agility — the ability to swap algorithms and rotate keys without a six-month project — as the actual security property you're buying, and the specific choice of RSA-2048 vs. Ed25519 vs. ML-DSA becomes a much less anxious decision.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.