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

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