[cryptography] urandom vs random

Eugen Leitl eugen at leitl.org
Mon Sep 9 02:53:47 PDT 2013


----- Forwarded message from David Johnston <dj at deadhat.com> -----

Date: Sun, 08 Sep 2013 21:57:43 -0700
From: David Johnston <dj at deadhat.com>
To: cryptography at randombit.net
Subject: Re: [cryptography] urandom vs random
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8

On 8/17/2013 9:39 AM, Sandy Harris wrote:
> Papers like Yarrow with respected authors argue convincingly that
> systems with far smaller state can be secure.

I've argued in private (and now here) that a large entropy pool is a
natural response to entropy famine and uneven supply, just like a
large grain depot guards against food shortages and uneven supply.

If you've got lots of good quality random data available, you don't
need a large state. You can just stir lots on raw data into a small
state and the small state will become fully entropic. The natural size
for the state shrinks to the block size of the crypto function being
used for entropy extraction. Once the value is formed and fully
entropic, you spit it out and start again.

This is one of the things that drove the design decisions in the
RdRand DRNG. With 2.5Gbps of 95% entropic data, there is no value in
stirring the data into a huge pool (E.G. like Linux) so that you can
live off that pool for a long time, even though the user isn't
wiggling the mouse or whatever. There will be more random data along
in under 300ps, so prepare another 256 bits from a few thousand raw
bits and reseed.

A consequence of Linux having a big pool is that the stirring
algorithm is expensive because it has to operate over a many bits. So
an LFSR is used because it's cheaper than a hash or MAC. An LFSR may
be a good entropy extractor, but I don't know of any math that shows
that to be the case. We do have that math for hashes, CBC-MACs and
various GF arithmetic methods.

When I count my raw data in bits per second, rather than gigabits per
second, I am of course going to use them efficiently and mix up a
large pot of state, so I can get maximum utility. With the RdRand
DRNG, the bus is the limiting factor, not the supply or the pool size.

DJ

_______________________________________________
cryptography mailing list
cryptography at randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

----- End forwarded message -----
-- 
Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org
______________________________________________________________
ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org
AC894EC5: 38A5 5F46 A4FF 59B8 336B  47EE F46E 3489 AC89 4EC5
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.cpunks.org/pipermail/cypherpunks/attachments/20130909/14d5db81/attachment-0001.sig>


More information about the cypherpunks mailing list