Cracking a 1024-bit DKIM Key

Your DKIM public key is sitting in DNS right now. Anyone can read it. If you're still using a 1024-bit RSA key, the question isn't whether it can be cracked. It's how much it would cost.

Let's do the math.

NIST already called it

NIST Special Publication 800-131A Rev. 2 (March 2019) is the definitive reference here. In Table 2, Section 3, the status of RSA keys shorter than 2048 bits for digital signature generation is one word:

Not deprecated. Not legacy use. Disallowed.

A 1024-bit RSA key provides roughly 80 bits of security strength. NIST requires a minimum of 112 bits for federal use. That minimum maps to 2048-bit RSA.

NIST defines "disallowed" in SP 800-131A Rev. 2 [1] as:

"The algorithm or key length is no longer allowed for applying cryptographic protection."

1024-bit keys are only permitted in "legacy use" mode, meaning you can still verify old signatures but must not generate new ones.

The upcoming SP 800-131A Rev. 3 (initial public draft, October 2024) [2] goes further. It transitions the minimum security strength from 112 bits to 128 bits after December 31, 2030. That means RSA-2048 (112-bit security) would be deprecated, with RSA-3072 (128-bit security) becoming the new recommended minimum. NIST intentionally chose "deprecated" rather than "disallowed" for asymmetric algorithms, to avoid forcing a double transition alongside the upcoming move to post-quantum cryptography.

The factoring records

The algorithm that cracks RSA keys is the General Number Field Sieve (GNFS). It's been used to set every modern factoring record.

RSA-250 (829 bits) was factored in February 2020 by Boudot, Gaudry, Guillevic, Heninger, Thomé, and Zimmermann [6][7]. The total computation time was roughly 2,700 core-years using Intel Xeon Gold 6130 CPUs at 2.1GHz. Sieving took 2,450 core-years and the matrix step took 250 core-years.

RSA-240 (795 bits) was factored in 2019 using approximately 900 core-years [6]. The researchers who did it estimated that a 1024-bit RSA modulus would take about 500 times as long.

RSA-1024 (1024 bits) has never been publicly factored.

Extrapolating to 1024 Bits

The GNFS complexity scales as:

L(n) = exp( c · (log n)1/3 · (log log n)2/3 )

where c ≈ 1.923 and log denotes the natural logarithm. Running this formula for 829 bits (RSA-250) versus 1024 bits gives a scaling factor of 200x. From 795 bits (RSA-240) the factor is 543x.

That gives us a range:

Basis	Multiplier	Estimated core-years for RSA-1024
RSA-250 (2,700 core-years) × 200	GNFS extrapolation	~540,000
RSA-240 (900 core-years) × 543	GNFS extrapolation	~488,000
NFS practitioners (Mersenne Forum)	Pessimistic	~1,500,000

The GNFS formula puts the sieving effort at roughly 500,000 core-years. The pessimistic estimates are 3x higher because the matrix step doesn't parallelize as well as sieving and becomes the real bottleneck at 1024 bits. The matrix would be approximately 4 billion × 4 billion and require a petabyte of RAM, which is beyond any standard server configuration today [4][5].

The cloud cost calculator

Let's price this out on a real cloud provider: Alibaba Cloud ECS.

A compute-optimized instance like ecs.c6.large (2 vCPU) costs approximately $0.06/hour on pay-as-you-go pricing in most regions. That's $0.03 per vCPU-hour, or roughly $263 per core-year.

Scenario	Core-years	On-demand	Spot (~70% off)
Optimistic	500,000	$131M	$40M
Mid-range	750,000	$197M	$59M
Pessimistic	1,500,000	$394M	$118M

Using spot instances aggressively, a well-funded attacker could potentially crack a 1024-bit RSA key for $40M to $120M in cloud compute alone [9].

For comparison, the Shamir and Tromer estimate from 2003 [4] suggested that a custom-built ASIC device could factor RSA-1024 in one year for approximately $10M (in 2003 dollars). With 20+ years of Moore's law improvements, a purpose-built hardware approach would likely be cheaper today, though nobody has publicly built one.

Timeline: how fast?

The sieving step is embarrassingly parallel. With enough machines, it's limited only by budget and bandwidth.

Budget	Instances (spot)	Sieving time	Total estimate
$40M	~500,000 vCPUs	~12 months	1.5 to 2 years
$80M	~1,000,000 vCPUs	~6 months	~1 year
$120M	~1,500,000 vCPUs	~4 months	~8 months

The matrix step is the bottleneck. It requires a single machine (or tightly coupled cluster) with massive memory. Current estimates suggest a petabyte of RAM. At current memory prices, building such a machine is feasible but adds $5M to $10M to the total cost. Alibaba Cloud, AWS, and Azure all offer high-memory instances (like Alibaba's ecs.r7.32xlarge with 1TB RAM), but you'd need to chain many of them together.

Why DKIM is a special case

Here's what makes DKIM different from TLS or S/MIME:

The public key is published in DNS. No need to intercept traffic or perform a man-in-the-middle attack. Just query selector._domainkey.example.com and you have the raw public key material. You can check your own DKIM key length right now and see exactly what an attacker sees.

DKIM keys rarely rotate. Many organizations set their DKIM key once and forget it for years. A cracked key stays useful for as long as the DNS record exists.

A single key compromise is devastating. Once you have the private key, you can forge emails from that domain that pass DKIM, SPF alignment, and DMARC. Phishing emails from a trusted domain with valid authentication are the holy grail for attackers.

You don't need real-time cracking. Unlike TLS where you need the session key quickly, DKIM key cracking can take months. The key will still be valid when you're done.

What this means for Your domain

A 1024-bit DKIM key is not going to be cracked by a random script kiddie. The $40M price tag (at minimum) means this is nation-state or well-funded criminal enterprise territory.

But that's exactly the point. If your domain is a target for state-sponsored phishing, or if you're in finance, government, healthcare, or critical infrastructure, a 1024-bit DKIM key is a known weakness.

The fix is straightforward. Start by running a DKIM check on your domain to see which selectors are active and what key sizes they use. Then:

1. Upgrade to 2048-bit RSA keys

   (the current minimum recommendation)

2. Consider 4096-bit keys

   if your DNS provider supports them (watch out for UDP packet size limits)

3. Rotate your keys regularly

   (twice a year)

4. Monitor with DMARC

   to detect unauthorized use of your domain

Time to Act

$40M to $120M to crack a DKIM RSA-1024 key sounds like a lot, but consider what that buys.

As of March 2026, both apple.com and microsoft.com still publish 1024-bit RSA DKIM keys in their DNS. Anyone can verify this right now. Crack one of those keys and you can send perfectly authenticated emails from @apple.com or @microsoft.com to anyone on the planet. DKIM passes. DMARC passes. The email lands in the inbox, not the spam folder.

Now think about what a single well-crafted email from @apple.com is worth to an attacker. A fake password reset to a Fortune 500 CEO. A fraudulent wire transfer instruction from @microsoft.com to a CFO who trusts Microsoft email implicitly. A supply chain attack targeting thousands of developers through a spoofed security advisory. The FBI's IC3 reported $2.77 billion in business email compromise losses in 2024 alone, and those attacks typically rely on lookalike domains that careful recipients can spot. A DKIM-authenticated email from the real domain? There's nothing to spot.

$40M is not expensive. It's a rounding error compared to the potential return. For a nation-state running an intelligence operation, it's a line item. For an organized crime syndicate running BEC at scale, it pays for itself with a single successful wire fraud against a large target.

A 1024-bit DKIM key provides 80 bits of security. That's below the minimum standard NIST mandated in 2011, with a final transition deadline of December 31, 2013. Cloud computing has made the cost of factoring these keys drop from "theoretical" to "expensive but achievable." The question is no longer whether someone can afford to do this. It's whether the target is worth it. And if your domain is apple.com or microsoft.com, the answer is obviously yes.

Don't wait for someone to prove it. Rotate your DKIM keys today.

---

References

1. Barker, E. & Roginsky, A. (2019). Transitioning the Use of Cryptographic Algorithms and Key Lengths. NIST SP 800-131A Rev. 2. https://doi.org/10.6028/NIST.SP.800-131Ar2

2. NIST SP 800-131Ar3 Initial Public Draft (October 2024). Transitioning the Use of Cryptographic Algorithms and Key Lengths. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar3.ipd.pdf

3. Rose, S. (2017). Defining Elliptic Curve Cryptography Algorithms for use with DKIM. IETF Draft. https://datatracker.ietf.org/doc/html/draft-ietf-dcrup-dkim-ecc-00

4. Shamir, A. & Tromer, E. (2003). Factoring Large Numbers with the TWIRL Device. CRYPTO 2003, LNCS 2729, pp. 1-26. Springer.

5. Lenstra, A.K., Tromer, E., Shamir, A., Kortsmit, W., Dodson, B., Hughes, J. & Leyland, P. (2003). Factoring Estimates for a 1024-Bit RSA Modulus. ASIACRYPT 2003, LNCS 2894, pp. 55-74. https://doi.org/10.1007/978-3-540-40061-5_4

6. Boudot, F., Gaudry, P., Guillevic, A., Heninger, N., Thomé, E. & Zimmermann, P. (2020). Comparing the Difficulty of Factorization and Discrete Logarithm: A 240-Digit Experiment. CRYPTO 2020, LNCS 12171, pp. 62-91. https://doi.org/10.1007/978-3-030-56880-1_3

7. Boudot, F. et al. (2020). Factorization of RSA-250. CADO-NFS announcement.

8. Kleinjung, T. et al. (2010). Factorization of a 768-Bit RSA Modulus. CRYPTO 2010, LNCS 6223, pp. 333-350. https://doi.org/10.1007/978-3-642-14623-7_18

9. Alibaba Cloud ECS Pricing. https://www.alibabacloud.com/en/product/ecs (see Pricing tab)

10. NIST SP 800-57 Part 1 Rev. 5. Recommendation for Key Management: General. https://doi.org/10.6028/NIST.SP.800-57pt1r5