By the way, this part of the eMudhra story doesn't get the attention it deserves: Google hired Daniel Bleichenbacher, he wrote a tool to identify insecure cryptographic artifacts, and Google did not use it regularly to check certificates and intermediates trusted by Chrome's root store.
Just wondering: has anyone seen any other instance of a small private key ECDSA vuln? For now, apart from the eMudhra certificates, the only keys I saw were deliberately generated test keys in software tests. I checked recent TLS+SSH scans and found nothing.
I'm inclined to conclude that this is a relatively rare vulnerability.
Randall, we have questions...
The FIDO Alliance publishes certificates for "Device attestation" for Passkeys through something called the FIDO Metadata Service(MDS). The idea here is that a service can restrict the use of passkeys to certain vendors. (One can argue whether that's a problematic, user-hostile feature to begin with.)
Looking through the certificates, we find this "interesting" cert:
"CN=FIDO2 Enterprise Attestation BATCH KEY prime256v1, emailAddress=tools@fidoalliance.org, O=FIDO Alliance, OU=Authenticator Attestation, C=US, ST=MY, L=Wakefield"
Its Issuer looks even more interesting:
"CN=FIDO2 Enterprise Attestation TEST ROOT, emailAddress=tools@fidoalliance.org, O=FIDO Alliance, OU=CWG, C=US, ST=CA, L=Mountain View"
It's not the only one in there that implies it's some form of "test" cert. However, this one is particularly interesting, as... it's also, apparently, using a "test" private key, which you can find here:
https://github.com/fido-alliance/conformance-test-tools-resources/blob/main/docs/FIDO2/Authenticator/README.md
In case you want to pretend that you're building a "KQC QuKey Bio FIDO2 Authenticator", that may come in handy.
It's not the only odd issue in that list, there are also plenty of certs with encoding errors. See, e.g.: https://github.com/fido-alliance/fido-device-onboard-feedback/issues/5
(Found together with @duesee )
In these times of a looming quantum cryptopocalypse, I guess every cryptographic tool has to support post-quantum cryptography eventually, and badkeys is, of course, no different.
With the latest release 0.0.19, badkeys can detect ML-KEM/ML-DSA keys. I wanted to do this for a while, but had to wait for support in python cryptography, which landed recently. Regarding the "post-quantum serialization format war", I'm supporting what python cryptography supports, which is currently only the seed format. This is also the recommended format by the RFC, so I guess that's fine for most uses.
Also, currently no support for SLH-DSA, as that's not supported by python cryptography either, and, I guess, there are questions whether this will see widespread adoption. (It has, to some degree, more reliable security guarantees, as it is "provably as secure as your hash function", but comes with impractically large signatures.)
You may wonder: do we already have ML-DSA/ML-KEM security vulns? No specific ones that badkeys detects yet, but there's one class of vuln that affects every algorithm and is independent of its security and any implementation weaknesses: accidental use of known-public private keys.
You can check badkeys' post-quantum support with the example keys from RFC 9881 and RFC 9935 that are already detected as known-compromised. More keys from test vectors etc. will be added over time.
Release notes: https://github.com/badkeys/badkeys/releases/tag/v0.0.19
During #39c3 Nadia Heninger introduced me to Keegan Ryan, and we talked about things that could go wrong in RSA, and how to detect keys with suspicious patterns created by defect RNGs. At some point, Keegan said: "You could check the Hamming Weight of the Modulus." And I replied: "I don't know what that means."
But it's actually quite simple. The Hamming Weight is the ratio of symbols, if we look at bits, how many 0s vs 1s are there. For a "proper", randomly generated RSA key, the ratio should be close to 0.5. If it's significantly different from that, it's likely not randomly generated.
We ended up finding some keys with repeating zero-byte patterns.It is possible to represent those as polynomials. Unlike integer numbers, polynomials can be factored efficiently, which means these keys can be broken.
We found SSH host keys that we could trace back to a software called CompleteFTP (which, furthermore, had another RSA vulnerability in its Linux version and also generated vulnerable DSA keys - all fixed in the latest version of CompleteFTP, but keys need to be regenerated). We furthermore identified another class of vulnerable keys (with a different width of zero byte patterns) in TLS certs (both self-signed and WebPKI-signed, but all expired, so no revocations), most of them from Verizon+Yahoo, but we were unable to identify the vulnerable RSA implementation.
If you're interested in the details of the attack, check Keegan's blog post:
https://blog.trailofbits.com/2026/06/12/factoring-short-sleeve-rsa-keys-with-polynomials/
The latest badkeys version 0.0.18 detects all affected vulnerable keys.
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-----
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.)
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 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
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... )
Something about that Fortinet/Fortigate leak that has not been widely recognized/reported yet: there are some private keys in there. Some of them belonged to unexpired, unrevoked certificates. I have reported all affected certificates to the responsible CAs.
badkeys now has detection for those keys. (yet, based on incomplete data.)
More info: https://blog.hboeck.de/archives/908-Private-Keys-in-the-Fortigate-Leak.html
I discovered a certificate using a "public private key", in this case a key that is part of OpenSSL's test suite. This would not necessarily be a particularly interesting event. It happens every now and then that people use private keys they find on the Internet, likely due to a lack of understanding of public key cryptography. I usually report them for revocation, and move on. However, this one is a bit more unusual. It has been issued by the CA Digicert - for a domain owned by Digicert. https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/d21mtDJ7YXQ