Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It only takes a minute to sign up.
Sign up to join this community
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?
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.
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?
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.
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).
