badkeys

I reported an insecure DKIM key to Deutsche Telekom / T-Systems. They first asked me to further explain things (not sure why 'Here's your DKIM private key' needs more explanation, but whatever...). Then they told me it's out of scope for their bugbounty. I guess then there's really no reason not to tell you: They have a 384 bit RSA DKIM key configured at: dkim._domainkey.t-systems.nl 384 bit RSA is... how shall I put it? I think 512 bit is the lowest RSA key size that was ever really used. 384 bit RSA is crackable in a few hours on a modern PC (using cado-nfs). The private key is: -----BEGIN RSA PRIVATE KEY----- MIHxAgEAAjEAtTliQYV2Xvx1OGkDyOL799BTFEuobY2dn2AgtiKCQgrh78NVK1JK j0yRXgNnPpGBAgMBAAECMF0t+TBZUCi8xATSMij7VLTxv5Xi5OIXesNiXOKtYIRP LkpYfR5PggaMScfbmqSssQIZAMwOhm9d7Y7Qi7I2j1AlYbiqdtqO54T7FQIZAONa 9dJFkC6lM3EPXR+0SZ4dqwwpiM0nvQIYYgz8thi5JK264ohq9sTvnu9yKvUN9I09 AhgfgMYZKcxtujRjkSZtMzUUNLYzzDmJe90CGDKwqcBI0v9ChaR8WHht+/chMdxj 7ez94w== -----END RSA PRIVATE KEY-----

"What do you think about the latest news about quantum computing breakthroughs and post-quantum cryptography?" - "Well, I still have some research about RSA vulnerabilities to publish, I need to get it done before RSA is obsolete."
(Yes, this conversation happened roughly like this. No, don't worry, it's nothing big, and probably won't affect you.)

There's a software called "BrowserStack local", which, apparently, contains a valid certificate for bs-local[dot]com including a private key. If you leak a private key like that, and if the CA (which, in this case is Godaddy) is informed about it, they have to revoke the affected cert.
I've reported this back in November. They generated a new cert in January. Again, private key is leaked through their software.

Chinese security company 360 recently leaked a private key for a wildcard web certificate for *.myclaw.360.cn. The key was shipped as part of their 360 Claw software (apparently some AI frontend).
The certificate has now been revoked. I checked their software for private keys, and, appart from the key for that cert, I found another private key (1024 bit RSA) embedded in the file chrome.dll (it appears their software bundles some fork of chromium, the "original" chrome.dll contains, however, no such key).
I dont know what that other key does. Given it's 1024 bit RSA, it cannot be used for a valid Web certificate (those must be >=2048 bit).

Both keys are now detected by badkeys.

In the recently released badkeys v0.0.17, a new check for an RSA vulnerability has been added: RSA keys with small private d values, also known as Wiener's attack: https://badkeys.info/docs/smalld.html

RSA keys have a public exponent e and a private exponent d. Usually, we set the public exponent to a small value (these days, largely standardized to e=65537), which automatically means the private value d is about as large as the public modulus. d/e are interexchangable, and it's possible to create insecure keys with small d and large e value. Wiener's attack (first published 1989) allows breaking such keys.

This weakness can be entirely prevented if one simply does not support keys with large public e values. This is, e.g., the case in the go crypto library, see, e.g., this old (2012) blogpost by @agl@infosec.exchange https://www.imperialviolet.org/2012/03/16/rsae.html

Even more secure is to fix the e value to its common default (e=65537). This is small enough to be still fast, and it avoids both attacks relying on large e (Wiener's attack) and very small e values like 3 (Bleichenbacher's Signature Forgery/BERserk, Coppersmith/Håstad attack).

Is anyone aware of an OCR tool that is reliable enough for non-text content like base64 that it can decode something like this?

(Context is something that was just posted on the dev-security-policy list and I currently can't judge the severity, but it happens every now and then that I see private or public keys in images that I'd like to get OCRed, source of this one: https://archive.ph/u6U2p )

Video recording of my @nullcon@bird.makeup presentation about badkeys, insecure keys in DKIM, DNSSSEC, OpenID Connect, and more now online: https://www.youtube.com/watch?v=Xr09jWCHfqI

Tomorrow at @nullcon@bird.makeup I will give a presentation about badkeys at 2pm https://nullcon.net/berlin-2025/schedule#daytwo-schedule/

@urig it doesn't really matter, it's just two different ways to encode the key. The main difference is that SPKI encodes the key type, but you know that with DKIM anyway. The mere problem is that the standard says something and reality is another thing.

@bartavi no security risk, it's just a "if you dare to follow the standard, your emails may not be delivered"-risk.

Key serialization formats can be - uh - the source of "interesting" issues. It appears the whole internet technically uses DKIM the wrong way, but it's more or less the fault of the standard.
DKIM uses public keys in DNS, usually RSA, but how are they encoded? There are two common RSA public key formats, SPKI and PKCS#1.
The DKIM spec RFC 6376 says this should be an RSAPublicKey and references RFC 3447, which is PKCS #1. So it's PKCS #1, right?
Well... there's an "INFORMATIVE" part of the RFC that lists openssl commands to encode a key, with an example. And that's... the openssl command to generate SPKI. The example shown is also an SPKI key.

The Internet has voted with its feet and everyone uses SPKI. From previous research, I had a collection of ~35k DKIM keys, and there are zero PKCS#1 keys in there.

This appears to be known and is mentioned in the errata.

It's quite an unfortunate situation. Technically, everyone's doing it wrong. However, if you would happen to be so brave to try to do it right, you'll probably just run into problems. While I haven't tested it, my best guess is that you will almost certianly find some receivers accepting PKCS#1 and others not. (Many crypto library APIs autodetect the format, but given *noone* is using PKCS#1, I'm sure there will be ones only accepting SPKI.)

@heinleinsupport@social.heinlein-support.de Und falls Ihr das seht und jetzt badkeys mal testen wollt: https://badkeys.info/

Jenkins recently announced that their docker images ssh-agent (CVE-2025-32754) and ssh-slave (CVE-2025-32755) had pregenerated, static SSH host keys. They're now detected by badkeys. https://www.jenkins.io/security/advisory/2025-04-10/

JSON Web Keys have a very peculiar property. It is a cryptographic key serialization format where public and private keys look almost the same. The only difference is that private keys contain more values. This means one can accidentally use a private key instead of a public key. Which works, but isn't very secure.
After my recent presentation at the @owasp_de@infosec.exchange Day, I was asked to have a look at OpenID Connect keys. Which are, well, in JWK format. I guess you can see where this is going.
https://blog.hboeck.de/archives/909-Mixing-up-Public-and-Private-Keys-in-OpenID-Connect-deployments.html

The new badkeys release (0.0.13) adds support to scan JSON Web Keys and JSON Web Key Sets directly with badkeys.

I recently realized something that I hadn't noticed before. In RSA, we call the privat key value "d". In elliptic curve cryptography, we also call the private key value "d". Is this a coincidence, or was this some deliberate choice? (FWIW, this isn't true for the public key, in RSA, this is composed of two values R and e, in ECC, it's usually x and y, but it's complicated... )

Updates on the Fortinet incident: badkeys now detects a more complete set of affected keys, and I have also identified 314 keys for active ACME accounts for @letsencrypt@infosec.exchange in the data. I have disabled the affected ACME accounts. Some updates in the blogpost: https://blog.hboeck.de/archives/908-Private-Keys-in-the-Fortigate-Leak.html

@christopherkunz@chaos.social @GossiTheDog@cyberplace.social nothing spectacular, random small company webpages and some likely internal hostnames.