BrianKrebs on Nostr: Reason #2,391 why revisiting security assumptions is always a good idea. [Bimi] No ...
Reason #2,391 why revisiting security assumptions is always a good idea.
[Bimi] No cryptographic connection between VMC and DKIM key
https://mailarchive.ietf.org/arch/msg/bimi/Ba3jFfJ8K6ic7qg4DzPsIsGW5UY/My favorite part:
"I guess some may consider what I just said as an unimportant or a merely theoretical issue, so I would like to illustrate it with an example. Let's take the domain entrust.com. It has a DKIM key
configured at "dkim._domainkey.entrust.com". The TXT record is the following:
"v=DKIM1; k=rsa;
p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCyGF0xzO7Eig1H8QdIErjEKOGnIVvoLU5VjcMRBRWZK65NinL+gVnjuMD2mYdjC3f+7sQCWxGDSKIFn/bB+iXxO2x1/ktkwXHQfQ/9FcFuy+LE0Snsm0SwXN/2l1m5f9e1xdswC+dzHt6DIpDSDENsRal019YKQTqwVyB++7QORwIDAQAB"
This is a 1024 bit RSA key, which is not up to modern standards. But breaking 1024 bit RSA is still only feasible for very powerful attackers. However, this key has another problem: it is vulnerable to
the Debian OpenSSL bug (CVE-2008-0166). It is trivially possible to
find the private key (you can use my tool badkeys -
https://badkeys.info/ - to do that):
https://github.com/badkeys/debianopenssl/blob/main/rsa1024/ssl/le32/25731-rnd.key";
Published at
2024-05-12 14:07:04Event JSON
{
"id": "a92d2b1aa78ada48a969328f05c9dd645e236ad0f6261d90c44ef84b93240dd9",
"pubkey": "662250ce4d037de109a64a6a0230f7899f922b76346388b3e7ca06fe9490358d",
"created_at": 1715522824,
"kind": 1,
"tags": [
[
"proxy",
"https://infosec.exchange/@briankrebs/112428503842956186",
"web"
],
[
"proxy",
"https://infosec.exchange/users/briankrebs/statuses/112428503842956186",
"activitypub"
],
[
"L",
"pink.momostr"
],
[
"l",
"pink.momostr.activitypub:https://infosec.exchange/users/briankrebs/statuses/112428503842956186",
"pink.momostr"
]
],
"content": "Reason #2,391 why revisiting security assumptions is always a good idea.\n\n[Bimi] No cryptographic connection between VMC and DKIM key\n\nhttps://mailarchive.ietf.org/arch/msg/bimi/Ba3jFfJ8K6ic7qg4DzPsIsGW5UY/\n\nMy favorite part:\n\n\"I guess some may consider what I just said as an unimportant or a merely theoretical issue, so I would like to illustrate it with an example. Let's take the domain entrust.com. It has a DKIM key\nconfigured at \"dkim._domainkey.entrust.com\". The TXT record is the following:\n\n\"v=DKIM1; k=rsa;\np=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCyGF0xzO7Eig1H8QdIErjEKOGnIVvoLU5VjcMRBRWZK65NinL+gVnjuMD2mYdjC3f+7sQCWxGDSKIFn/bB+iXxO2x1/ktkwXHQfQ/9FcFuy+LE0Snsm0SwXN/2l1m5f9e1xdswC+dzHt6DIpDSDENsRal019YKQTqwVyB++7QORwIDAQAB\"\n\nThis is a 1024 bit RSA key, which is not up to modern standards. But breaking 1024 bit RSA is still only feasible for very powerful attackers. However, this key has another problem: it is vulnerable to\nthe Debian OpenSSL bug (CVE-2008-0166). It is trivially possible to\nfind the private key (you can use my tool badkeys -\nhttps://badkeys.info/ - to do that):\n\nhttps://github.com/badkeys/debianopenssl/blob/main/rsa1024/ssl/le32/25731-rnd.key\"",
"sig": "33d29d6c11c04cb5e1d04437742112dbd3989a54eaf8df9b07ef48452d3b044b0f13c2173546581db3ecfe3bc8869bf916d46a9c6e1b3eb229feedbfb64474cd"
}