upvote
I suspect private keys should receive a nominal check, that they can't be guessed by smashing the number 4 on a numpad.
reply
So we either expose the key material for inspection (very obviously bad) or we try and brute force how many possible "weak" private keys from the public key to see if they check out?

Note that this is on the order of trillions of useless computations at least per year since almost everyone just uses a CSPRNG or HWRNG available in all modern computers to generate their keys sanely.

Now, for CAs, sure because that is a very small number of certificates. But that's a completely different discussion and also however eMudhra managed to lop off all of the entropy except for the final byte was wildly incompetent and not something a layman would even consider doing.

It's also not the job of the CA to detect you being an idiot. You can go post your private key online after getting your certificate if you so wish, the CA may revoke it if they find out but they're just in the business of helping you secure your communications with others. If you wish for them to actually be insecure... You are silly, but that was always allowed.

reply
FWIW, at at least some of the ACME CAs still willing to sign RSA certificates will make a cursory attempt at brute forcing your private key to make sure you don’t have one very tiny prime and one big one. Tom7 encountered this when he tried to implement the least secure website he could without being flagged by the browser. He ended up using a public modulus with four prime factors instead of 2.
reply
The “4” affair did make me wonder… as a non-expert, I’d always kind of assumed that—with all the ceremony around key ceremonies and all—there might be some way to provably assert the set of techniques used to arrive at the key in the first place. XYZ hardware-signed source of entropy was sampled at DEF time and input into ABC signed chunk of algorithm to arrive at the private key…

In fact I assumed that’s why somebody might explicitly choose “4” as their key: to make it as easily detected as “TK” in a copy edit, or a prefix-designated API key in a repo, or an “@example.com” that slides by into a serious environment.

We really go on a pinky swear across the public CA ecosystem?

reply
You could certainly use zero knowledge proofs to prove some statements about the secret key, like requiring it to be roughly a 1:1 ratio of 0s and 1s and the longest run of the same bit is not significantly larger than log2(n). I think if I were trying to enforce a minimum level of security then I might take that route, requiring that the key passes zero-knowledge proofs of various statistical tests of randomness.

By pigeonhole principle, nearly all numbers have to have a Kolmogrov complexity within some constant of their own length, meaning they are algorithmically random and will by definition pass every statistical test of randomness, so you lose surprisingly few bits entropy per assertion this way.

reply
You're looking for https://www.ietf.org/archive/id/draft-ietf-lamps-csr-attesta.... It's gotten enough renewed attention in the wake of the eMudhra fiasco that I'm reasonably optimistic about it becoming required for intermediates.
reply
I am not sure how trillions of computations will occur, simply attempting 0-255 would have found ... all? ... of the eMudhra fuckups. Maybe a few million instructions burnt on a CPU.
reply
Do you know how many SSL certificates are issued per year? LE issued 10 million per day in 2025. https://letsencrypt.org/2025/12/09/10-years

And again, you have to actively work to get a "private key" of 0000 ... 0-255. If you want to be stupid it's not really the CA's job to tell you not to be. It's their job to verify your identity. And, again, a CA itself is a totally separate beast where this thinking does not apply. If you want to be secure it's easy to be secure and if you don't want to be... Why should anyone else care? You are only hurting yourself.

reply
The check should probably be done for intermediary CAs though? Right?
reply