[cryptography] [liberationtech] Heml.is - "The Beautiful & Secure Messenger"

Patrick Mylund Nielsen cryptography at patrickmylund.com
Sat Jul 13 17:17:57 EDT 2013

On Fri, Jul 12, 2013 at 3:29 PM, ianG <iang at iang.org> wrote:

> On 12/07/13 21:54 PM, Patrick Mylund Nielsen wrote:
>> On Fri, Jul 12, 2013 at 2:48 PM, James A. Donald <jamesd at echeque.com
>> <mailto:jamesd at echeque.com>> wrote:
>>     On 2013-07-13 12:20 AM, Eugen Leitl wrote:
>>         It's worth noting that the maintainer of record (me) for the
>>         Linux RNG quit the project about two years ago precisely because
>>         Linus decided to include a patch from Intel to allow their
>>         unauditable RdRand to bypass the entropy pool over my strenuous
>>         objections.
>>     Is there a plausible rationale for bypassing the entropy pool?
>> Throughput? Not bypassing means having to wait until enough randomness
>> has been gathered from trusted sources.
> Typically, the entropy pool is used to feed a PRNG.  Throughput isn't
> really an issue because modern PRNGs are fast, and there are very few
> applications that require psuedo-RNs at that sort of speed.

It seems that this indeed was the reason. In the original thread, Linus
made the comment:

"The fact is, even if you worry about some back door for the NSA, or some
theoretical lack of perfect 32-bit randomness, we can pretty much depend on
it. We still do our own hashing on top of whatever entropy we get out of
rdrand, and we would still have all our other stuff. Plus the instruction
is public and testable - if Intel did something wrong, they'll be *very*

In other words, there's absolutely no reason not to use it, and allow us to
get away from /dev/random running out of entropy. We absolutely should use
it for bootup randomness (where we currently are somewhat weak), and I
absolutely disagree that it should be made into more of a driver


It still makes sense if you need so much random data that /dev/random
doesn't have sufficient entropy in time to re-seed the PRNG.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.randombit.net/pipermail/cryptography/attachments/20130713/08271e40/attachment.html>

More information about the cryptography mailing list