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

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.