[cryptography] on using RDRAND [was: Entropy improvement: haveged + rngd together?]

coderman coderman at gmail.com
Fri Nov 29 19:54:10 EST 2013

On Thu, Nov 28, 2013 at 6:42 AM, Stephan Mueller <smueller at chronox.de> wrote:
> ...
> Though, bear in mind that you may not want inject entropy from one noise
> source via multiple paths. E.g. the Intel RDRAND instruction IS picked up
> by /dev/random and should therefore not used by rngd.

note that you may also elect to use RDRAND in a much more restricted
manner.  for example, disable direct kernel support and feed only
/dev/random with RDSEED. then use a userspace rngd as discussed to
process this entropy and mix into the kernel pool, perhaps with a more
conservative entropy density estimate.

Intel still has not released raw access to their entropy sources;
RDRAND and RDSEED both passing through the conditioner (AES-CBC-MAC),
RDRAND also munged and less frequently seeded AES CTR_DRBG (per NIST).

anything less than raw access to the entropy source samples inspires
no confidence!

consider current usage in Linux kernel[0][1], and past usage[2][3].

0. "extract_buf() - 'If we have a architectural hardware random number
generator [ED.: but only RDRAND], mix that in, too.'"

1. "Thoughts on RDRAND in Linux"

2. "Linux 3.2 random.c - get_random_int(void)"

3. "Linux 3.2 random.c - get_random_bytes()"

More information about the cryptography mailing list