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 */ char buf[212]; if ((fd = open("/dev/urandom", O_RDONLY)) == -1) err(1, "open"); if ((size_t)read(fd, buf, sizeof(buf)) != sizeof(buf)) /* or use saturated read loop */ err(1, "read"); arc4random_addrandom(buf, sizeof(buf)); explicit_bzero(buf, sizeof(buf)); /* now throw away early keystream */ char anotherbuf[256]; int i; for (i = 0; i < 12; ++i) arc4random_buf(anotherbuf, sizeof(anotherbuf)); /* actually, make sure the compiler doesn’t optimise away the above */ explicit_bzero(anotherbuf, sizeof(anotherbuf)); 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). bye, //mirabilos -- “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” -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.10.1406121014170.17...@tglase.lan.tarent.de
