Re: use of RDRAND in $random_library
On Wed, 11 Jun 2014, Josh Triplett wrote:
> Any program desiring high-performance random numbers has a good reason to use
> RDRAND or RDSEED: they produce randomness *far* faster than the kernel, and
Yes, because SIGILL is so much faster…
Anyway. Even on systems supporting RDRAND, user space SHALL not use it
as sole source of entropy.
http://crypto.stackexchange.com/a/10397/8475 shows why.
If user space needs *a lot* of entropy, it should use arc4random_buf()
from -lbsd (libbsd-dev). However, the default setting uses only a
handful of bytes from /dev/urandom for seeding, because Linux’ urandom
device is inferiour to the random devices on OpenBSD/MirBSD, so you
should seed the aRC4 state with additional random bytes:
/* aRC4 state has about 1700 bits of entropy */
if ((fd = open("/dev/urandom", O_RDONLY)) == -1)
if ((size_t)read(fd, buf, sizeof(buf)) != sizeof(buf))
/* or use saturated read loop */
/* now throw away early keystream */
for (i = 0; i < 12; ++i)
/* actually, make sure the compiler doesn’t optimise away the above */
After this, you can use arc4random() and arc4random_buf() to your
heart’s content. The library will reseed every 1.6M of output or so.
If you really want rdrand, use a second arc4random_addrandom() call
with a buffer filled by rdrand; they are accumulative. You may pass
buffers between 1 and 256 bytes of length to arc4random_addrandom().
You can do this manually in a loop, too (there is no indication that,
once seeded properly as above, you need to repeat throwing away the
initial keystream, for this purpose and as long as the data added
is sufficiently random and not dependent on arc4random’s output).
“ah that reminds me, thanks for the stellar entertainment that you and certain
other people provide on the Debian mailing lists │ sole reason I subscribed to
them (I'm not using Debian anywhere) is the entertainment factor │ Debian does
not strike me as a place for good humour, much less German admin-style humour”