Posted by hkc 13 hours ago
In this case one cert gets defeated and you go the odds of that number being that low are 2^-384. Essentially impossible if it were randomly selected. It's much more likely you didn't choose that at random so I start guessing a bunch of other low numbers for your other certificates and find them quickly.
I have an insanely unlikely unique car licence plate number to sell you.
You would say the same of any seed I gave you. You've just artificially assigned this number with some sort of emotional importance.
"Playing roulette, in isolation after RED - RED - RED - RED - RED, there is not a higher chance of getting BLACK than RED in the next run. But in practice, one would be correct in concluding that it will probably be BLACK. The proof is that in our test, the next run gave BLACK".
Said differently, it was not particularly unlikely that the number would be 4. But maybe it got the attention of the person who decided to try assuming that it was a mistake, and they were indeed lucky.
I can think any number of programming mistakes that will result in a supposed (pseudo-)random number generator to be be biased to very small numbers. I have made such mistakes myself.
By any reasonable estimate, the probability of randomly picking a number below 256 is MUCH smaller than the probability of someone having made a mistake.
That doesn't make sense, does it?
> In this case one cert gets defeated and you go the odds of that number being that low are 2^-384.
It just happened that that particular number got the attention of a human, which was luck. But in terms of statistics, this number was not less likely than another one.
In short, raising the floor doesn’t really hurt the search space meaningfully.
In theory, all values would be equally random. In practice, some results are exceedingly more likely to occur when something's wrong with the algorithm.
While any given outcome of flipping a coin randomly N times is equally likely, if that series looks like [heads, heads, heads, heads, ...], then there's probably something other than pure random affecting the output.
That said, a sanity check on the value somewhere in the code would indeed have prevented this.
More generally, it is common to sample a bit string and use that as a seed for a PRG, from which the private key is generated. So in that case the range is [0, 2^k] and what matters is the quality of the randomness. Unfortunately high-quality randomness is not always available, especially for embedded devices and rack-mounted "appliances."
https://ubuntu.com/blog/emudhra-ca-compromise-fixes-availabl...
* It's absurd that Python, Go, or Node need their own certificate stores that need separate updates. (Probably OK for browsers because they seem very on top of updating them without user intervention.)
* This issue is especially bad when you consider deployment through containers, docker, etc. More parallel copies of vulnerable certificate stores. With docker volumes you could mount the host's certificates into the containers and get "update once" behavior but I doubt people are doing this.
* It wouldn't be too hard to implement CRLs against the OpenSSL certs as a script that runs from cron. I might end up doing this.
Since there's nothing to indicate that the private key was all zeroes and one non-zero lsbyte, and presumably nobody would try to brute-force a private key.
The two cases are very similar. The only difference is that the weak randomness was harmless in the earlier story, and here it’s devastating.
Why not? There are examples of RNGs providing very poor entropy which might be a reason to check it (looking at you Sony).
It took less than a second to factor this key. Why not attempt, say, to factor every CA, with a budget of less than a minute each?
The reward/risk ratio is skewed so heavily in favor of trying, the only reason not to is this idea that it is "impossible".
It's clearly not, hence, the theater. Your locks don't have to work, they often only have to look like they work...
Previously: eMudhra intermediate CA compromise - https://news.ycombinator.com/item?id=50166579 - Oct 2026 (458 comments)