[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.'"
  https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/char/random.c#n1038

1. "Thoughts on RDRAND in Linux"
  http://blog.lvh.io/blog/2013/10/19/thoughts-on-rdrand-in-linux/

2. "Linux 3.2 random.c - get_random_int(void)"
  http://lxr.free-electrons.com/source/drivers/char/random.c?v=3.2#L1326

3. "Linux 3.2 random.c - get_random_bytes()"
  http://lxr.free-electrons.com/source/drivers/char/random.c?v=3.2#L928


More information about the cryptography mailing list