On Thu, Nov 28, 2013 at 6:42 AM, Stephan Mueller <[email protected]> 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 _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
