[cryptography] urandom vs random

coderman coderman at gmail.com
Sun Aug 18 20:07:49 EDT 2013


On Sun, Aug 18, 2013 at 10:14 AM, Ben Laurie <ben at links.org> wrote:
> ... my advice is that you probably should not run Linux if you need
> strong randomness.

i am surprised this has not surfaced more often in this thread:
 if you need good entropy: use a hardware entropy generator!



also use a userspace entropy collector like dakarand or haveged, use a
userspace entropy daemon for seeding system entropy pool (/dev/random)
from hardware sources (like /dev/hw[_-]?random, unless you trust
RDRAND ;)

this is true no matter what operating system you use, where on a clean
boot in a headless system you must choose between denial of service or
silent insecurity.

not to mention being under served in unexpected high usage situations,
like initializing full disk crypto volumes with /dev/random or
extremely high volume web server endpoints with high entropy
utilization requirements.

if you are running virtual machines this implies virtio random devices
or VM safe instructions (if you trust RDRAND ;) to provide strong
entropy within the guest systems as well. not to mention proper
administration to ensure you're saving seeds and not sharing pool
state between instances, etc.



over ten years ago i wrote a threaded entropy daemon for the C5XL
XSTORE instruction that provided megabits of entropy from /dev/random
after configuring the MSR for XSTORE, sanity checks in the mtrngd, and
writing to /dev/random when poll indicated users had consumed entropy
from the system, thus ensuring /dev/random never went dry.

ten years later and still the state of the consumer, embedded, and
enterprise markets is totally inadequate, with the one recent ray of
hope (RDRAND) intentionally obfuscated in a way that threatens trust.

WTF



in short, if you are not doing one or more of the following:
- hardware rng with userspace daemon for hw rng
- userspace entropy collector (haveged, dakarand, others)
- securely seeded and re-seeded CSRNG (for VMs with boot and runtime
entropy passing)

you are doing it wrong. it is just a matter of risk/cost to exploit
your use of "randomness"!
 (and the above does not mitigate your risk, it merely makes other
risks your new weakest link, of course ;)


More information about the cryptography mailing list