Nostr notes by badkeys

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