[149171] in cryptography@c2.net mail archive
Re: [Cryptography] cheap sources of entropy
daemon@ATHENA.MIT.EDU (dj@deadhat.com)
Tue Jan 21 13:59:40 2014
X-Original-To: cryptography@metzdowd.com
In-Reply-To: <20140121151016.GB28368@thunk.org>
Date: Tue, 21 Jan 2014 18:51:08 -0000
From: dj@deadhat.com
To: "Theodore Ts'o" <tytso@mit.edu>
Cc: cryptography@metzdowd.com, dj@deadhat.com
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
> On Mon, Jan 20, 2014 at 04:46:23PM -0000, dj@deadhat.com wrote:
>>
>> Paranoid Entropy Trap:
>> The tendency to get no entropy because you turned off all the sources
>> of
>> entropy, because you don't trust any of them.
>
> My answer to this is to mix from as many sources as possible, in the
> hopes that one or more of them can not be predicted by the attacker.
> Yes, this may be less efficient, but that's engineering tradeoffs for
> you --- and how many applications really *do* need 3 gigabits per
> second of cryptographic grade random numbers? :-)
>
Things (well most things) don't need a 3Gbps RNG. You build a 3Gbps RNG so
that thread A can't perform an RNG DoS on thread B. It's an availability
thing and relates to the saturation properties of on-chip busses. The
performance is neither an argument for nor against the multiple sources
approach.
Your position falls down when the only source of entropy on the platform
is the single provided RNG and you don't credit it any entropy because you
choose not to trust it on behalf of the user, so their OS mediated random
number supply blocks when if fact there's copious entropy to be had.
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
