Nostr notes by badkeys

This is the sha256 hash of a sentence: ...

2026-10-24T18:45:05Z

This is the sha256 hash of a sentence:
f7a6b8dcde222fdffba66f1e2ec1d4dc340f624437a526c00f6b3ef03fb08656
(just want to make sure I may be able to prove later at what time I found what I just found. stay tuned...)

By the way, this part of the eMudhra story doesn't get the ...

2026-10-23T10:34:10Z

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 ...

2026-10-23T08:10:42Z

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.

Google has test ECDSA P384 keys with d=2 and d=3 in boringssl. ...

2026-10-22T11:34:19Z

Google has test ECDSA P384 keys with d=2 and d=3 in boringssl. And yes, badkeys did scan for these. If they hadn't stopped at 3...

Randall, we have questions... ...

2026-10-20T17:11:04Z

Randall, we have questions...

Please update your root stores and whatever checks your ...

2026-10-20T13:08:27Z

Please update your root stores and whatever checks your certificates:
https://blog.mozilla.org/security/2026/10/20/protecting-firefox-users-following-the-compromise-of-emudhra-intermediate-certificates/
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAON8YFNdN5UU%2Bn98zGsVL%2BH-zNATS%3DM0-UrrSoYCt1V9hERJLA%40mail.gmail.com

I've recently scanned DKIM keys for vulnerabilities, more ...

2026-08-27T07:47:32Z

I've recently scanned DKIM keys for vulnerabilities, more extensively than previous scans. DKIM keys with the Debian OpenSSL bug are still very common. So are too-short RSA keys (quite a few 512 and even 384 bit keys, and *many* 768 bit, which is still difficult to break, but possible).
Also, a notable number publish a private key in their DKIM record. (This is only a problem if they actually use the same key elsewhere correctly.)
I tried disclosing things, but manual disclosure impractical for thousands of affected hosts and automated disclosure is difficult (plenty without security.txt, security@ often is rejected).
Replies to disclosures also show a common misunderstanding: People believe they are unaffected saying these keys are old and unused. This shows a fundamental confusion about how digital signatures work. Attackers don't care if you use insecure keys as long as they can use them.

Some stats for the latest scan: https://monitor.badkeys.info/dkim/2026-08-11-dkim-badkeys.html

During #39c3 Nadia Heninger introduced me to Keegan Ryan, and we ...

2026-06-12T13:01:14Z

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. ...

2026-04-15T07:34:51Z

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-----

In the recently released badkeys v0.0.17, a new check for an RSA ...

2026-02-22T07:55:36Z

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 Adam Langley (npub1h2q…lajr) 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 ...

2026-01-21T09:18:47Z

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 )

JSON Web Keys have a very peculiar property. It is a ...

2025-02-25T11:15:10Z

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](https://infosec.exchange/@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

@npub1stt…ddpm @npub1lcc…lcye nothing spectacular, random ...

2025-01-18T08:25:02Z

Dr. Christopher Kunz (npub1stt…ddpm) Kevin Beaumont (npub1lcc…lcye) nothing spectacular, random small company webpages and some likely internal hostnames.

I discovered a certificate using a "public private key", ...

2024-11-25T15:51:04Z

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