[cryptography] on using RDRAND [was: Entropy improvement: haveged + rngd together?]
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
consider current usage in Linux kernel, and past usage.
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