entropy of /dev/random vs. openssl rand

[markus reichelt]

Hi,

I need to create a moderate amount of v3 keys for loop-aes and wonder
how/if the "openssl rand" implementation differs significantly from
/dev/random concerning entropy.

In case /dev/random and "openssl rand" are somewhat comparable, I
would just use the latter to create the keys.

However, I certainly don't want to use a /dev/urandom look-alike.

Any feedback appreciated.

[Gisle Sælensminde]

Post by markus reichelt
Hi,
I need to create a moderate amount of v3 keys for loop-aes and wonder
how/if the "openssl rand" implementation differs significantly from
/dev/random concerning entropy.
In case /dev/random and "openssl rand" are somewhat comparable, I
would just use the latter to create the keys.

Openssl actually uses /dev/urandom to generate random bytes on Linux and other systems that support it, possibly with some further filtering. On systems without a random device, a configuration file is used instead, since openssl is supposed to be compatible over a wide range of systems. Openssl rand should therefore be equivalent with the non-blocking /dev/urandom on Linux.

from openssl crypto/rand/rand_unix.c:

/* Use a random entropy pool device. Linux, FreeBSD and OpenBSD
* have this. Use /dev/urandom if you can as /dev/random may block
* if it runs out of random entries. */

Post by markus reichelt
However, I certainly don't want to use a /dev/urandom look-alike.

Whether the blocking behaviour of /dev/random is desirable is a matter of discussion. Some people argue that a periodically reseeded cryptographic-quality random number generator is as secure as a true random number generator for all practical purposes. It does then not make sense with a blocking generator like /dev/random. This view is much disputed, as can be seen if you read the archives of the Linux kernel mailing list. I personally can't think of any realistic scenario where /dev/random would make you safe while /dev/urandom would make you sorry. Some people seem to think differently, including you apparently :-) , while the openssl people seem more concerned about the blocking behaviour of /dev/random.

-Gisle


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Jari Ruusu]

Post by Gisle Sælensminde
Some people argue that a periodically reseeded cryptographic-quality
random number generator is as secure as a true random number generator for
all practical purposes.

[snip]

Post by Gisle Sælensminde
I personally can't think of any realistic scenario where /dev/random would
make you safe while /dev/urandom would make you sorry.

No problem if cryptographic-quality random number generator is reseeded
using high quality entropy. But saving/reseeding PRNG using a plaintext file
as most distros seem to do at shutdown and boot does not count as secure.
/dev/urandom state may be predictable for some time after boot. /dev/random
at least waits for new entropy before handing out random bits, and avoids
that predictable state pitfall.

Do most distros attempt to overwrite /var/lib/urandom/random-seed or
whatever after it has been used to reseed /dev/urandom? Does any distro
attempt to overwrite that file?

For the record, loop-AES versions of mount/losetup/swapon that set up random
key loop devices, use /dev/urandom. But they also attempt to work-around
possibly predictable boot-time /dev/urandom bits. The work-around is
basically random-seed save/restore (to backing device) but with 20
overwrites of saved-state after it has been used to create new encryption
keys. See source for more details.