I've factored the RSA keys of a Certificate Authority from the 90s

Original Article ↗ Hacker News Discussion ↗

Factoring a 512‑bit RSA key from a 1990s certificate authority on modern consumer hardware highlights how weak legacy “export‑grade” cryptography has become and raises questions about the long‑term confidentiality of historical encrypted traffic. Commenters contrast the cost of breaking 512‑, 1024‑, and 2048‑bit RSA keys, explain how advances in factoring algorithms and GPUs make 1024‑bit RSA potentially reachable for well‑resourced actors, and note that symmetric algorithms remain far more resistant. The thread also touches on the history of government‑mandated weak crypto, the shift toward stronger and post‑quantum TLS, and concerns about relying on AI‑generated code and custom TLS implementations in security‑sensitive work.

RSA key strength and factoring feasibility

  • Multiple comments discuss how factoring scales:
    • Symmetric keys effectively double work per extra bit; RSA is weaker per bit due to sub‑exponential factoring (e.g., General Number Field Sieve).
    • Estimates cited: ~2000 GPU‑years to factor 1024‑bit RSA; 2048‑bit RSA projected as hundreds of thousands to millions of years with current techniques.
    • 2048‑bit RSA is often mapped to ~112 bits of symmetric security; 3072‑bit RSA to ~128 bits.
  • Factoring a 512‑bit key in ~2 days on consumer hardware is seen as consistent with historical projections.
  • Some highlight that memory and matrix steps, not just raw compute, are major bottlenecks.

Quantum computing and future risk

  • Shor’s algorithm is mentioned as a theoretical endgame for RSA, but practical quantum hardware with enough stable qubits is seen as far off.
  • Some suggest looking at “stable qubit” trends versus RSA cost; intersection is unclear.

TLS, old browsers, and custom crypto

  • Modern TLS libraries dropped SSLv3, SSLv2 client hellos, and export ciphers; the article’s author implemented a minimal SSLv3 stack (RC4, DES/3DES, MD5, SHA‑1) to talk to Netscape 4.x.
  • Others describe similar efforts to support “retro internet” services, often requiring custom OpenSSL builds.

Export‑grade crypto and historical policy

  • Export‑grade 512‑bit RSA and 40‑bit symmetric ciphers were intentionally weak so agencies could decrypt them.
  • Root certificate slots in 1990s browsers were monetized, and there was pressure from incumbents to limit competition.
  • Some recall national rules (e.g., forced key escrow, bit‑length caps).

AI tools (“slop machine”) in the workflow

  • Debate over using LLMs:
    • Critics dislike outsourcing “interesting” parts and warn about unverifiable, plausible output.
    • Defenders argue AI is fine for intermediate, non‑security‑critical steps if final results are independently checked.
    • Strongly negative and strongly positive attitudes toward AI both appear.

RNGs, rolling your own crypto, and system design

  • Conventional wisdom: don’t roll your own crypto; use kernel RNGs (getrandom, /dev/urandom).
  • Counterpoint: a hand‑rolled RNG in a long‑lived project is claimed to have had no vulnerabilities, while widely used libraries have had many; argues context and careful design matter.
  • Discussion touches on POSIX constraints, chroot environments, and performance vs. security in RNG design.

PKI, DNS, and alternatives

  • Some advocate publishing public keys in DNS (ACME/DNS‑01 style) and question the need for traditional CAs.
  • Others note this shifts trust to DNS and DNSSEC, and MITM at the DNS layer remains a concern.

Surveillance, forward secrecy, and stored traffic

  • Concern that governments may have recorded historical encrypted traffic to decrypt later as factoring or quantum improves.
  • Forward secrecy and symmetric crypto robustness are emphasized; post‑quantum TLS deployment stats are cited as encouraging.
  • A proposed extra defense: negotiate a PSK over a “clean” connection and use it to harden future sessions, assuming the adversary cannot monitor everything.