[cryptography] on using RDRAND [was: Entropy improvement: haveged + rngd together?]
smueller at chronox.de
Sun Dec 1 07:41:59 EST 2013
Am Freitag, 29. November 2013, 16:54:10 schrieb 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, and past usage.
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