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

Stephan Mueller smueller at chronox.de
Sun Dec 1 07:41:59 EST 2013

Am Freitag, 29. November 2013, 16:54:10 schrieb coderman:

Hi coderman,

> On Thu, Nov 28, 2013 at 6:42 AM, Stephan Mueller <smueller at chronox.de> 
> > ...
> > 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 
> > 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!

You nailed it :-)

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

Exactly. And I have to concur with the Linux developers. And that is also 
the exact reason for the flag I get on my RNG attempt based on CPU jitter. 

And as you mentioned in your subsequent emails, RDSEED/RDRAND can be picked 
up by rngd, if needed and trusted by some users.

| Cui bono? |

More information about the cryptography mailing list