Five months of wall-clock time. 1,380 CPU core-years. A 1024-bit RSA signature that verified on the far end while the private key never left its vault. That receipt is public now, and it will land in your cybersecurity channel as if number theory just ate every VPN you run. Treat it as a priced cleanup bill for the padding modes and key sizes you still allow to prove authenticity.

Funded labs can buy that compute. Your change calendar can retire the keys. Only one of those is under your control this quarter.

Skip Padding and Compute Turns Into a Forgery

Bruce Schneier unpacked the paper after Ars Technica billed it as a new attack against RSA that bypasses factoring. The research is from 2007. The fresh piece is a working implementation with a runtime you can put on a budget line.

Handle it like an incident commander. This is a signature forgery. An attacker spends cycles and produces a message plus a signature that a verifier accepts under a public key you already published. The private key stays put. Hunt a signed object that should not exist, and a verifier that still accepts raw RSA.

The shot is narrow. It needs pure signatures: RSA with no formatting and no padding. Production stacks sign with PKCS#1 or PSS. TLS libraries, ordinary code-signing, and any API that refuses raw mode sit outside that window. The leftovers live in HSM partitions labeled legacy, vendor checkboxes named compatibility, smart-card profiles from a prior contract, and the in-house service that hashed a blob and called a decrypt-style verify because a 2011 post made it look tidy.

Login brute-force is noisy and cheap. This is quiet and expensive. The algorithm is subexponential, somewhat faster than factoring, still a lab purchase. A spray against SSH is a different class of problem, and you already have controls for that racket.

The authors were able to forge messages for 1024-bit RSA with 1380 CPU core-years (over five real-world months).

Bruce Schneier

1024-bit RSA has been a retirement candidate for years. Teams kept it because an appliance image would not take 2048, because an internal CA still minted it, because a code-signing cert lasts until 2028 and re-signing the catalog looks like a quarter-long outage. This implementation hangs a number on that delay. A determined forger now has a published price for one valid signature on an unpadded 1024-bit key.

Read that price twice. You are not looking at a weekend hobby. You are looking at a project a well-funded shop can run while your exception ticket sits in a queue labeled “wait for the next hardware refresh.”

Cybersecurity Inventories Catch Raw RSA. Packet Captures Don’t.

Open a ticket that is not titled “RSA is broken.” Name the owners of every service that verifies RSA. Force three fields onto the same form those owners already dodge: modulus size, padding, and whether “none” is even a legal value in the API they call.

Do the first sweep today. Keep the rest on a calendar.

• Export every RSA public key your PKI, HSMs, code-signing services, JWT issuers, and appliance admin planes still serve. Flag 1024-bit and smaller. Flag any verify path documented as raw, none, RSA_NO_PADDING, or legacy digest. Put the list in the ticket, not in a slide.
• Disable raw RSA verify in libraries you control and fail closed. If a vendor binary still offers it, isolate that listener, require an authenticated jump, and write a dated exception with a named owner. Security hardening here is a verifier setting, not a new agent.
• Rotate remaining 1024-bit certificates and signing keys on a scheduled outage this cycle. If the business slips the date, record the delay as accepted risk with an expiry, then put the same item on the next CAB agenda before the paper fades from chat.
• Prove the control. Add a test that feeds an unpadded blob to every RSA verify path you own and expects a hard fail. Run that test in CI for anything that wraps an HSM. Point incident response at disable-verify, rotate-key, and rebuild-trust when a signed object is authentic by math and wrong by intent.

After the sweep, keep a crypto bill of materials next to your software one. Key size, algorithm, padding, where the private key lives, who can request a signature. Review it when you rotate certs. Defense in depth includes that list. A glossy threat-protection dashboard does not, and last-fired detections on your SIEM will not invent a padding field you never logged.

Tabletop the failure while you can still argue about change windows. A firmware image, a license file, or an internal token that “verifies fine” is the symptom. The cause is a verifier you never inventoried. Write the playbook so the first page is disablement, not a request for pcap.

Your Firewall Will Approve a Signature That Already Verifies

Packet filters see a session. They do not see whether the integers inside a signature came from a private key or from a five-month compute run. A firewall allow rule for your update channel will pass a forged package if the verify step says yes. IP bans, geo blocks, and rate limits belong on the problems they actually solve. Leave them there. They do not get a vote on this one.

Threat detection tuned for credential stuffing stays dark. There is no spray and no lockout counter. There is a single object that looks correctly signed. Your cyber security story has to treat the verifier as a control you can prove: tests, last-run dates, and an owner who can kill raw mode without waiting on a vendor SE.

If you still issue or accept 1024-bit RSA for anything that implies authenticity, you now have a public compute budget for forging it on the unpadded path. Spend the next change window on the inventory. The paper already spent five months printing the receipt.

Sources

• New Attack Against RSA