Skip to content

Instantly share code, notes, and snippets.

@tarcieri
Created August 26, 2013 22:27
Show Gist options
  • Star 3 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save tarcieri/6347417 to your computer and use it in GitHub Desktop.
Save tarcieri/6347417 to your computer and use it in GitHub Desktop.
djb on /dev/random vs /dev/urandom
Date: 17 Aug 2013 00:24:45 -0000
From: "D. J. Bernstein" <djb@cr.yp.to>
To: cryptography@randombit.net
Subject: Re: [cryptography] urandom vs random
Aaron Toponce writes:
> Cryptographers don't like the idea that it's possible, even if it's
> excessively remote, and highly unprobable. This is why you see suggestions
> to use /dev/random for long term SSH, SSL and OpenPGP keys.
Cryptographers are certainly not responsible for this superstitious
nonsense. Think about this for a moment: whoever wrote the /dev/random
manual page seems to simultaneously believe that
(1) we can't figure out how to deterministically expand one 256-bit
/dev/random output into an endless stream of unpredictable keys
(this is what we need from urandom), but
(2) we _can_ figure out how to use a single key to safely encrypt
many messages (this is what we need from SSL, PGP, etc.).
For a cryptographer this doesn't even pass the laugh test.
I'm not saying that /dev/urandom has a perfect API. It's disappointingly
common for vendors to deploy devices where the randomness pool has never
been initialized; BSD /dev/urandom catches this configuration bug by
blocking, but Linux /dev/urandom (unlike Linux /dev/random) spews
predictable data, causing (e.g.) the widespread RSA security failures
documented on http://factorable.net. But fixing this configuration bug
has nothing to do with the /dev/random superstitions.
---D. J. Bernstein
Research Professor, Computer Science, University of Illinois at Chicago
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment