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)
4 comments:
Useful already, thanks for sharing!
Perfect and useful article!
Allowed me to quickly check our DKIM keys and ensure they are long enough :)
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?
Thanks
Post a Comment