On Fri, Nov 29, 2013 at 4:54 PM, coderman <[email protected]> wrote: > ... > 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
hopefully my last mea culpa, but the issue above is fully resolved in latest linux git; Theodore Ts'o's work to harden the entropy system in Linux should be commended. the less better version directly xor's RDRAND with the pool output before handing back to consumer. see v3.12 or earlier: http://lxr.free-electrons.com/source/drivers/char/random.c?v=3.12#L945 which looks like this: --- 899 static void extract_buf(struct entropy_store *r, __u8 *out) 900 {... 945 /* 946 * If we have a architectural hardware random number 947 * generator, mix that in, too. 948 */ 949 for (i = 0; i < LONGS(EXTRACT_SIZE); i++) { 950 unsigned long v; 951 if (!arch_get_random_long(&v)) 952 break; 953 hash.l[i] ^= v; 954 } 955 956 memcpy(out, &hash, EXTRACT_SIZE); 957 memset(&hash, 0, sizeof(hash)); 958 } versus the latest version, with improvements: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/char/random.c#n1049 which includes: - a __mix_pool_bytes() on the RDRAND xor'd read - an additional sha_transform() - a final half fold to mask digest output before handing back to consumer. i would be comfortable running this mode and implementation with RDRAND. _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
