329 Followers
54 Following
38 Posts
badkeys is an open-source tool and web service to identify compromised cryptographic keys.
websitehttps://badkeys.info/
codehttps://github.com/badkeys/
pypi packagehttps://pypi.org/project/badkeys/
"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 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 presentation about badkeys, insecure keys in DKIM, DNSSSEC, OpenID Connect, and more now online: https://www.youtube.com/watch?v=Xr09jWCHfqI
#NullconBerlin2025 | Finding insecure cryptographic keys in DKIM, DNSSEC, OpenID Connect & elsewhere

YouTube
Tomorrow at @nullcon I will give a presentation about badkeys at 2pm https://nullcon.net/berlin-2025/schedule#daytwo-schedule/
Nullcon Security Conference & Training

Nullcon is Asia’s largest international security conference, where key stakeholders from the industry, delegates from the government company representatives, COOs and hackers come together to talk about InfoSec

Hey look, another certificate authority trusted ONLY by Microsoft is issuing certificates without validation (1.1.1.1/Cloudflare DNS in this case): https://crt.sh/?sha256=D42B028468E73795365102058CBCD350AD0A0B9CA7073C5362A570C5EC208A92
(h/t Hacker News user JXzVB0iA)
crt.sh | d42b028468e73795365102058cbcd350ad0a0b9ca7073c5362a570c5ec208a92

Free CT Log Certificate Search Tool from Sectigo (formerly Comodo CA)

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