Wednesday, October 24, 2012

How to determine DKIM key length?

I read this article in Wired about a researcher who figured out that Google was using a weak (512-bit) key for its implementation of DKIM. It turns out this is old news as someone did the same thing to Facebook.

This got me wondering if the keys for our emailing service are long enough. But, how to easily determine the length of the key? Turns out it is kind of convoluted so I decided to repeat the info here for my own benefit when I forget about this later.

Take your public DKIM key (probably from your DNS TXT record). It looks like this one from Google:

20120113._domainkey.google.com. 86400 IN TXT "k=rsa\; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAp5kQ31/aZDreQqR9/ikNe00ywRvZBFHod6dja+Xdui4C1y8SVrkUMQQLOO49UA+ROm4evxAru5nGPbSl7WJzyGLl0z8Lt+qjGSa3+qxf4ZhDQ2chLS+2g0Nnzi6coUpF8r" "juvuWHWXnzpvLxE5TQdfgp8yziNWUqCXG/LBbgeGqCIpaQjlaA6GtPbJbh0jl1NcQLqrOmc2Kj2urNJAW+UPehVGzHal3bCtnNz55sajugRps1rO8lYdPamQjLEJhwaEg6/E50m58BVVdK3KHvQzrQBwfvm99mHLALJqkFHnhyKARLQf8tQMy8wVtIwY2vOUwwJxt3e0KcIX6NtnjSSwIDAQAB"

Save the p= part of the TXT record into a file (google.key) that is line wrapped to around 78 columns (yes, it needs to be line wrapped or the openssl command used below breaks). Google seems to store their key in two parts so I removed the " " that is embedded in the middle of the blob above. You will also need the BEGIN/END PK block.

-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAp5kQ31/aZDreQqR9/
ikNe00ywRvZBFHod6dja+Xdui4C1y8SVrkUMQQLOO49UA+ROm4evxAru5nGPbSl7WJzyGLl0z8Lt+
qjGSa3+qxf4ZhDQ2chLS+2g0Nnzi6coUpF8r
juvuWHWXnzpvLxE5TQdfgp8yziNWUqCXG/
LBbgeGqCIpaQjlaA6GtPbJbh0jl1NcQLqrOmc2Kj2urNJAW+
UPehVGzHal3bCtnNz55sajugRps1rO8lYdPamQjLEJhwaEg6/
E50m58BVVdK3KHvQzrQBwfvm99mHLALJqkFHnhyKARLQf8tQMy8wVtIwY2vOUwwJxt3e0KcIX6Ntn
jSSwIDAQAB
-----END PUBLIC KEY-----

Then run openssl rsa -noout -text -pubin < google.key

Which then outputs this chunk with your answer:

Modulus (2048 bit):
    00:a7:99:10:df:5f:da:64:3a:de:42:a4:7d:fe:29:
    0d:7b:4d:32:c1:1b:d9:04:51:e8:77:a7:63:6b:e5:
    dd:ba:2e:02:d7:2f:12:56:b9:14:31:04:0b:38:ee:
    3d:50:0f:91:3a:6e:1e:bf:10:2b:bb:99:c6:3d:b4:
    a5:ed:62:73:c8:62:e5:d3:3f:0b:b7:ea:a3:19:26:
    b7:fa:ac:5f:e1:98:43:43:67:21:2d:2f:b6:83:43:
    67:ce:2e:9c:a1:4a:45:f2:b8:ee:be:e5:87:59:79:
    f3:a6:f2:f1:13:94:d0:75:f8:29:f3:2c:e2:35:65:
    2a:09:71:bf:2c:16:e0:78:6a:82:22:96:90:8e:56:
    80:e8:6b:4f:6c:96:e1:d2:39:75:35:c4:0b:aa:b3:
    a6:73:62:a3:da:ea:cd:24:05:be:50:f7:a1:54:6c:
    c7:6a:5d:db:0a:d9:cd:cf:9e:6c:6a:3b:a0:46:9b:
    35:ac:ef:25:61:d3:da:99:08:cb:10:98:70:68:48:
    3a:fc:4e:74:9b:9f:01:55:57:4a:dc:a1:ef:43:3a:
    d0:07:07:ef:9b:df:66:1c:b0:0b:26:a9:05:1e:78:
    72:28:04:4b:41:ff:2d:40:cc:bc:c1:5b:48:c1:8d:
    af:39:4c:30:27:1b:77:7b:42:9c:21:7e:8d:b6:78:
    d2:4b
Exponent: 65537 (0x10001)

3 comments:

Tristan Olive said...

Useful already, thanks for sharing!

luckyredhot said...

Perfect and useful article!
Allowed me to quickly check our DKIM keys and ensure they are long enough :)

jkoons71 said...

Does anyone know what the protocol overhead cost would be when using a larger (1024 and 2048)encryption key? I am assuming that using a larger key would result in a much heavier computational overhead. And, would this additional overhead be more of an issue on the MTA side or on the receiver side?