Cracking a 512-bit DKIM key for less than $8 in the cloud

Original Article ↗ Hacker News Discussion ↗

Email and DKIM security context

  • Many argue email is still weaker than people assume; others counter that with TLS between MTAs plus DKIM/DMARC, it’s “good enough” for most users, with real failures often being passwords and account takeover.
  • Several participants stress that the real risk here is domain spoofing (spammers forging DKIM on your domain), not confidentiality of message content.
  • DKIM-512 is rare in the wild, but still present: roughly ~0.3% of observed DKIM keys in a 1M-domain sample, and likely higher on the broader internet.

RSA key sizes and factorization difficulty

  • Broad agreement: 512‑bit RSA is long broken and trivial to factor with today’s tools and commodity hardware.
  • Most say 1024‑bit RSA is on the edge: not broken publicly, but considered weak and being phased out; attackers with nation-state resources might manage it.
  • Disagreement and confusion over scaling:
    • Some claim GNFS cost grows roughly with the square of bit length and dramatically understate the cost of 1024/2048 factoring.
    • Others correct this, pointing to GNFS’s super‑polynomial behavior and giving cost estimates for 1024‑bit factoring in the tens of millions of dollars or more.
  • Consensus: 2048‑bit RSA is currently safe against classical attacks; long‑term future belongs to non‑RSA schemes and post‑quantum algorithms.

Migration, standards, and alternative algorithms

  • RFCs now deprecate <1024‑bit DKIM keys and require verifiers to handle at least 1024–4096 bits; reality lags but most large providers comply.
  • Ed25519 for DKIM is standardized and partially deployed, but ecosystem support (mail servers, big providers, DNS tooling) is uneven and slow.
  • Some argue for just using 4096‑bit RSA where possible; others see this as wasted effort vs. moving to elliptic curves or PQC.

Operational and DNS constraints

  • Practical blockers mentioned:
    • DNS TXT record limits (255 bytes per string; multi‑string records are allowed but poorly supported in some UIs/registrars).
    • Some DNS providers still cap DKIM keys at 1024 bits or don’t handle split TXT records well, especially in smaller or non‑US markets.
  • Tooling for key rotation and management is described as underdeveloped and brittle, so many orgs leave old or weak keys in place for years.

Deniability, privacy, and DKIM

  • A substantial subthread debates whether strong, long‑lived DKIM signatures are a privacy problem:
    • One side: they enable stolen mail spools to be cryptographically authenticated years later, aiding blackmail, leaks, and legal exposure, while offering little value to end users.
    • Proposed mitigation: regularly rotate DKIM keys and later publish old private keys to restore repudiation (anyone could have forged those signatures).
    • Others counter that non‑repudiation can be socially useful (evidence in disputes, courts, journalism) and that users often want verifiability, not deniability.
  • Clarified: DKIM authenticates a sending domain/MTA, not an individual human; courts and non‑experts may nonetheless over‑interpret its evidentiary value.

Ethics and legality of cracking live keys

  • Some are uneasy about factoring real, in‑use DKIM keys, seeing it as crossing an ethical or even legal line (akin to cloning a physical key).
  • Others respond that:
    • The work used only public data and did not send fraudulent mail; it’s comparable to demonstrating exploitability in typical security research.
    • Responsible disclosure and fixing the issue before publication makes it ethically acceptable.
  • No clear consensus; participants note jurisdiction‑dependent laws and the practical risk that upset companies might still seek prosecution.