17.09.2019 17:11, Theodore Y. Ts'o ÐÐÑÐÑ:
There are only two ways out of this mess. The first option is we take
functionality away from a userspace author who Really Wants A Secure
Random Number Generator. And there are an awful lot of programs who
really want secure crypto, becuase this is not a hypothetical. The
result in "Mining your P's and Q's" did happen before. If we forget
the history, we are doomed to repeat it.
You cannot take away functionality that does not really exist. Every time somebody tries to use it, there is a huge news, "the boot process is blocked on application FOO", followed by an insecure fallback to /dev/urandom in the said application or library.
Regarding the "Mining your P's and Q's" paper: I would say it is a combination of TWO faults, only one of which (poor, or, as explained below, "marginally poor" entropy) is discussed and the other one (not really sound crypto when deriving the RSA key from the presumedly-available entropy) is ignored.
The authors of the paper factored the weak keys by applying the generalized GCD algorithm, thus looking for common factors in the RSA public keys. For two RSA public keys to be detected as faulty, they must share exactly one of their prime factors. In other words: repeated keys were specifically excluded from the study by the paper authors.
Sharing only one of the two primes means that that the systems in question behaved identically when they generated the first prime, but diverged (possibly due to the extra entropy becoming available) when they generated the second one. And asking the randomness for p and for q separately is what I would call the application bug here that nobody wants to talk about: both p and q should have been derived from a CSPRNG seeded by a single read from a random source. If that practice were followed, then it would either result in a duplicate key (which is not as bad as a factorable one), or in completely unrelated keys.
Attachment:
smime.p7s
Description: Криптографическая подпись S/MIME