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.
--
Alexander E. Patrakov