17.09.2019 18:11, Alexander E. Patrakov пишет:
> 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.

I take this back. Of course, completely duplicate keys are weak keys, 
and they are even more dangerous because they are not distinguishable 
from intentionally copied good keys by the method in the paper.

-- 
Alexander E. Patrakov