Folks,
For a narrative walk-through of what can go wrong when you don't use
large enough keys in public cryptography, as applied in a real world
attack against DKIM in email:
http://www.wired.com/threatlevel/2012/10/dkim-vulnerability-widespread/
There is a US-CERT announcement:
http://www.kb.cert.org/vuls/id/268267
In particular, a number of tutorials on how to set up DKIM will have the
administrator use the openssl command to create a 512 or 768 bit RSA
key. This is unwise, and may permit others to fraudulently assert that
their mail comes from you. If your mail and reputation are worth
protecting, they're worth protecting right.
“A 384-bit key I can factor on my laptop in 24 hours,” he says. “The
512-bit keys I can factor in about 72 hours using Amazon Web Services
for $75. And I did do a number of those. Then there are the 768-bit
keys. Those are not factorable by a normal person like me with my
resources alone. But the government of Iran probably could, or a large
group with sufficient computing resources could pull it off.”
-- Zachary Harris, cited in the Wired article
Public key cryptography on the Internet is in an awkward transitional
phase: most folks are still using RSA and it's the "de facto supported"
algorithm, but adequate key lengths today make processing very slow. In
the USA, NSA Suite B cryptography uses ECC exclusively, which is fast
and uses smaller keys, but support is not widespread. This leads to
some uncomfortable choices for administrators.
The Exim maintainers are not cryptanalysts, we can not state what should
be used. We do not know what maximum sizes may be supported out there.
We can say that DKIM specifies a minimum of 1024 bits; the site:
http://www.keylength.com/en/
provides tables of key-lengths as recommended by various organisations.
The European ECRYPT II standards cite 1248 bits (asymmetric) as the
smallest general purpose level for protection in situations which most
closely resemble DKIM for email on the Internet.
We can say that DKIM has been designed to make it very easy to roll your
keys! Create new keys, publish them in DNS. If you use a predictable
naming scheme, you might wait for the zone minimum/negative TTL expiry
duration to pass, so that non-existence can't have been abusively cached
for your next key. Then switch the signing transport's `dkim_selector`
and `dkim_private_key` values to point to the new selector and key.
Wait a few days for mail in transit to all have been delivered, then
remove the old keys from DNS (or sooner, if you've been attacked, as
Google were).
Those wanting a complete example, with Makefile, of Exim and DKIM
integration might peruse "Unix and Linux System Administration
Handbook", 4th Edition, by Nemeth et al; the Exim DKIM section has a
complete example, contributed by myself. (I am not an author, I receive
no money from sales of this excellent book.)
Regards,
- -Phil Pennock, mostly on behalf of The Exim Maintainers
