6
$\begingroup$

What is the recommended key length for DKIM? I'm currently thinking about a 1024-bit key vs. a 2048-bit one.

From the crypto point of view for RSA, 2048 or 4096 bits is clearly recommended--no discussion on that point. Having glanced over various posts, it seems there may be some trouble at the mail or DNS level with keys of 2048-bit length.

Moreover, using 1024-bit keys seems to be the current trend.

Which key length is best for DKIM?

$\endgroup$
5
$\begingroup$

Nobody has publicly announced that they've broken 1024-bit RSA (other than via implementation defects that can happen with any key size), but it's not out of the question. I can't find a recent estimate, but when RSA-768 was broken in 2009, the researchers estimated that RSA-1024 would be “about a thousand times harder” and that there was “little doubt about the feasibility by the year 2020 of a matrix required for a 1024-bit NFS factorization”. So 1024-bit RSA should certainly not be used to encrypt confidential data or to authenticate arbitrary entities.

However, DKIM is somewhat less demanding than most cryptography applications. Your adversary is not NSA, it's spammers and scammers. On the scale of how much money they make, the cost of breaking 1024-bit RSA would be totally prohibitive. Furthermore, the impact of a broken key is detectable and correctable: if someone manages to break a legitimate key and makes use of that, there will be emails bearing those traces. This may cause temporary harm, but the key can be revoked. In practice, it's a lot more likely that an adversary would impersonate a legitimate participant by exploiting some misconfiguration of the server than by breaking the cryptography.

So 1024-bit RSA is fine for DKIM at the moment. However, attacks only ever get better. It's possible than an improvement to factoring techniques will make it slightly easier to break RSA, and will bring 1024-bit RSA from “NSA can break it if they really want” to “$10k on AWS”. So you should have an upgrade path ready, which you should always have when it comes to cryptography anyway. You should make sure that your system accepts 2048-bit keys, but it's ok to use a 1024-bit key for now.

| improve this answer | |
$\endgroup$
  • $\begingroup$ But practically speaking, signing and signature verification is rarely a bottleneck in systems like this even if using large RSA keys. I'd say it's worth it to at least use 2048 bit keys. And then you don't need to suddenly switch keys if anybody shows up out of the blue announcing that they cracked 1024 bit keys. $\endgroup$ – Natanael Aug 2 '19 at 18:21
  • $\begingroup$ @Natanael The asker was worried about compatibility, not about performance. Of course everybody should already have upgraded away from 1024-bit RSA, even for DKIM. For that matter, everybody should have upgraded away from RSA. But the world moves slowly. $\endgroup$ – Gilles 'SO- stop being evil' Aug 2 '19 at 20:50
  • $\begingroup$ Given the 255-char limit of a single, self-contained DNS TXT record, is there anything that precludes using a value higher than 1024, but lower than 2048, that would fit comfortably within that limit? For example, a 1246-bit key produces a 252-character TXT record. $\endgroup$ – Royce Williams Oct 20 at 20:22
  • 1
    $\begingroup$ @RoyceWilliams In principle, RSA can work with keys of any size (not even necessarily a whole number of bytes), but not all implementations support this. Most implementations support powers of 2 and often at least 3*2^n, so 1536 bits is widely supported. $\endgroup$ – Gilles 'SO- stop being evil' Oct 21 at 11:12
1
$\begingroup$

FYI:

We use G Suite and our DNS is AWS.

Upgrading our DKIM from 1024 to 2048 caused a lot of e-mail, both internal and external, being labelled as spam.

I contacted Google and they suggested to lower the DKIM length to 1024.

Why?

  1. Because "[...] your DKIM record is pretty long to be used in your domain's DNS settings" (we use AWS, are you serious?)
  2. "[...]If your DKIM is not recognized properly then your outbound messages will not be authenticated properly [...] the recipient's server can get your messages as coming from unknown sources [...] Then the spam classification is triggered."

Therefore we ended up using 1024. We are in 2020 and G Suite has been sponsoring DKIM 2048 since 2016. But the problem was AWS which is using 1024-bit DKIM key by default.

CONCLUSION: You can use 1024 which is still fairly good or 2048 if you want to feel safer. Keep in mind that 1024 is still the standard and before you choose 1024 or 2048 check your DNS provider and see what length of DKIM key is supported because they need to match.

| improve this answer | |
$\endgroup$
  • $\begingroup$ I had the same experience. GMail and most large mailing systems support 2048-bit keys just fine, but plenty of older ones are still failing to validate emails due to key length issues. $\endgroup$ – mae Jul 22 at 5:22
0
$\begingroup$

Bulk e-mail provider emarsys is using a 1024 bit key. It might be worth cracking, as they tell their clients to put their public key in the clients own DNS as a TXT record. And to only create one record. It is big companies that uses them.

All other mail providers tells customers who do not use their own keys, to create a CNAME to the providers, and tells customers to setup 2 selectors, so that they can change a key, and switch over to the secondary while they update the first. This allows them to mitigate away from breached keys in a week or so. emarsys can't do that. They need all their customers to update their TXT record, or at least create new CNAME records.

1024-bit is OK to use if you publish 2 selectors, if you sign for customers, then have the customers create CNAME records for both selectors. Then you can change in a week (or less - Not sure how long time you should give old mail to be delivered / verified).

| improve this answer | |
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.