On 09/08/2014 08:26 PM, Edward Ned Harvey (blu) wrote:
The problem with bad entropy sources would be overestimating their entropy.
Entropy calculation is doomed unless one can define and control larger system boundaries--not just software but complete hardware with physical protections around it. But I can see why one would still want to ~sort~ of try.
Logically, if the crypto is good, entropy accounting should not matter, but when one is feeding crypto it is wrong to put too much on, say, a counter driving AES... Wanting real entropy as an input is good. Okay, so make some lower-boundary estimations, but don't toss entropy just because you don't know the data you are being fed.
I think it is reasonable for the Linux kernel to have an RNG, but the kernel will never define a large enough boundary to really know its entropy sources. Being strict about entropy sources logically reduces to removing Linux's hybrid entropy-pool/cryptographic RNG altogether. Anyone who is marching down that logical path is the wrong person to maintain random.c.
Yes, Linus can be, er, loud, and much of the time it is refreshing, but he does have a pragmatic engineering perspective and, as far as I have observed, will see reality...maybe after a delay. He does get pretty amazing results in his personnel management to produce a kernel that runs well on an astounding range of hardware.
The most egregious offense was the exclusive use of ThreadedSeedGenerator class, which produced output that sometimes lzma compressed to approx 11% of its original size. That's bad. Really, really bad.
RNGs have the risk of failing silently. But this isn't even a silent failure. Jeeze.
-kb _______________________________________________ Discuss mailing list [email protected] http://lists.blu.org/mailman/listinfo/discuss
