[cryptography] urandom vs random

Eugen Leitl eugen at leitl.org
Mon Sep 9 02:58:49 PDT 2013


----- Forwarded message from coderman <coderman at gmail.com> -----

Date: Sun, 8 Sep 2013 22:35:02 -0700
From: coderman <coderman at gmail.com>
To: David Johnston <dj at deadhat.com>
Cc: Discussion of cryptography and related <cryptography at randombit.net>
Subject: Re: [cryptography] urandom vs random

On Sun, Sep 8, 2013 at 9:57 PM, David Johnston <dj at deadhat.com> wrote:
> ...
> 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.

this is a good analogy :)


> ... The natural size for the state
> shrinks to the block size of the crypto function being used for entropy
> extraction

for best effective performance, it seems memory bus(es) constrains the
optimal transmission unit size.
4k extended instructions providing more throughput than repeated
instructions at 512bit chunks.

the worst case scenarios, you're passing entropy directly into AES
native instructions, and/or onward to PCIe lanes...


> 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)

you keep coming back to this assumption that RDRAND is entirely
trusted and always available.

consider adding additional entropy sources like USB keys, scavengers
like Dakarand or Haveged, and so forth.

conversely to your argument, there is no harm in aggressively mixing a
large pool with a high rate hardware entropy source. if you are one of
the worst case scenarios, like seeding an entire new volume for full
disk encryption with entropy, then you can manage accordingly and cut
out the OS level, kernel pool middle man, system call boundary, and
other overhead accordingly.


> A consequence of Linux having a big pool is that the stirring algorithm is
> expensive because it has to operate over a many bits.

but not effectively expensive!

again, i find very few the situations in which my modern processor is
unable to keep a properly refilled aggressively reseeded /dev/random
up to any demanded rate of consumption for high speed network
services, common client side uses, most key generation, and so forth.

if you are one of the worst case scenarios, like seeding an entire new
volume for full disk encryption with entropy, then you can manage
accordingly and cut out the OS level, kernel pool middle man, system
call boundary, and other overhead


> 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.

fair enough, but consider the inverse, particularly for a skeptical
audience knowing what we do now:

why not mix aggressively with multiple sources if you have the CPU budget?

why not provide access to the raw, un-mixed, un-encrypted,
un-whitened, un-obfuscated state of the raw entropy bits for those so
inclined to use it in such a manner?


efforts to drive RDRAND into direct use instead of the kernel entropy
pool in the linux kernel,

efforts to steadfast refuse access to the raw entropy stream,

are thus viewed with elements of suspicion and provide an air of lack
of credibility.


even with all of these concerns, i have publicly said and will
continue to assert, using RDRAND is better than nothing. the current
state of entropy on most operating systems and especially virtual
machine environments on these operating systems, is very poor.

it is just a shame this resource cannot be used to greater utility and
confidence, as would be provided, were raw access be available.


best regards,
_______________________________________________
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/33539885/attachment-0001.sig>


More information about the cypherpunks mailing list