Hanno Böck went looking for broken math, and he found it sitting in plain sight. His badkeys project pulls public keys from everywhere they leak into view: Certificate Transparency logs, internet-wide TLS and SSH scans, PGP keyrings, the lot. While building the tool, he and a collaborator noticed something strange in the pile. A cluster of RSA moduli stuffed with zeros. Sparse keys. And sparse keys, as their new research shows, can sometimes be factored outright.

Here’s the uncomfortable part of cybersecurity nobody puts on a conference slide: the keys protecting your traffic are already public, already collected, and already being scored by anyone curious enough to run a script. Your firewall doesn’t enter into it. The weakness ships inside the certificate.

Why A Key Full Of Zeros Falls Apart

RSA security rests on one bet, that nobody can factor a large number that’s the product of two big primes. Break the modulus into its two prime factors and the private key falls out. For a properly generated 2048-bit key, that’s computationally hopeless. The bet holds.

It stops holding when the number isn’t random. A modulus with long runs of zero bits is structurally sparse, and sparse numbers hand mathematicians a foothold that dense random numbers don’t. The researchers searched their massive real-world dataset for these unexpectedly thin moduli and found them in the wild, not in a lab, not as a thought experiment, but in keys that real systems are using to negotiate real sessions right now.

How does a key end up looking like that? Almost always the same culprit: bad entropy at generation time. Cheap embedded devices that boot, immediately generate a key, and have no real randomness to draw from. Faulty hardware RNGs. Buggy crypto libraries that quietly produce garbage. The device works, the handshake succeeds, the padlock shows up in the browser, and nothing screams. The flaw is invisible until someone goes hunting for the pattern. Someone just did.

Your Public Keys Were Catalogued Years Ago

The reason this research lands hard is the same reason it was possible at all. Every public key your infrastructure presents is, by design, public. Certificate Transparency logs every TLS certificate you’ve ever issued. Internet-wide scanners sweep the entire IPv4 space on a schedule and archive what they find. Your SSH host keys, your PGP keys, your TLS certs are all sitting in datasets that anyone can download. You published your attack surface and forgot you did it.

That same logic showed up in a quieter post this week. A SANS Internet Storm Center handler, mid-pentest, shared how he automates host reconnaissance using the favicon.ico method, hashing the tiny icon a site serves and matching it against known fingerprints to identify what’s running behind an address. It’s a small trick. It’s also the whole game in miniature. Attackers don’t start with a brute-force barrage against your login page. They start by cataloguing you from public breadcrumbs: favicons, certificates, banners, key material. Recon first, then the loud stuff.

So the weak-RSA finding and the favicon trick are the same story told twice. Your public-facing assets are being enumerated continuously, by researchers with good intentions and by people with worse ones, and the difference between those two groups is mostly who emails you first. Threat detection that only watches your perimeter for inbound attacks misses this entire phase, because the reconnaissance happens in datasets you’ll never see touched.

What To Actually Do About It

You can’t stop your keys from being public. You can stop weak ones from being yours. Start with the boring, decisive move: build an inventory of every key and certificate your organization presents to the internet. You almost certainly don’t have one, and you can’t rotate what you can’t name.

From there, a handful of concrete steps:

• Run your keys through a checker. The badkeys project is open source and screens public keys against known-vulnerable patterns, including the sparse-modulus class. Feed it your inventory. Anything flagged gets rotated, not debated.
• Treat weak-key findings as an incident response trigger. A factorable production key is a live exposure, not a tidy-up task. Rotate it, reissue the cert, and assume any traffic it protected could have been readable.
• Fix the source of the bad randomness. If a key was weak, the device or library that made it will make another weak one. Audit embedded gear, IoT, and appliances that self-generate keys on first boot, and prefer generating keys on hardware with a real entropy source.
• Set a generation standard and enforce it. Modern, well-sourced RSA at 3072 bits or higher, or Ed25519, generated by a maintained library. Make it policy, then verify the output instead of trusting it.

None of this replaces the rest of your stack. You still need brute-force throttling on every exposed login, real threat-protection at the edge, and defense in depth so one weak link doesn’t sink the whole boat. Security hardening of your key lifecycle is one more layer in that pile, not a substitute for the others. The point is that good cyber security treats cryptographic hygiene as an operational discipline with an owner and a schedule, the same way you treat patching.

The attackers already finished their inventory. The only question is whether you’ve done yours.

Frequently Asked Questions

Does this mean RSA is broken?

No. Properly generated RSA keys with strong randomness remain safe. The weakness is in specific keys that were generated with poor entropy, producing sparse moduli that can be factored. The algorithm is fine; the generation was not.

How would I even know if one of my keys is affected?

Pull your public keys and run them through an open-source checker like badkeys, which screens for the sparse-modulus pattern and other known-weak classes. There’s no need to expose private keys; the test works on the public ones already in circulation.

Why can’t my firewall protect me from this?

The weakness travels inside the key itself, which you hand out publicly during every handshake. A firewall filters traffic; it can’t fix math that was broken at generation. Rotation to a strong key is the only real remedy.

Sources

• Factoring RSA Keys with Many Zeros (Schneier on Security)
• Adding some Automation to the favicon.ico method of Host Recon (SANS Internet Storm Center)