> Am Freitag, 29. November 2013, 19:05:00 schrieb coderman: > > Hi coderman, > >> On Fri, Nov 29, 2013 at 4:54 PM, coderman <coder...@gmail.com> 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/dri >> > vers/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: >> > > This code is already in since 3.4 or so. IIRC, your mentioned code never > appeared on a final kernel tree. >
The effect of RNGd using RdRand is entirely different in user experience and security effect to the Kernel's use. The mix-in algorithm to the kernel pool is different (XOR vs that twisted LFSR thing), the RNGd source gets credited entropy by the kernel, where the RdRand does not. The result is that with RNGd pulling from RdRand, /dev/random does not block. With the right kernel parameters, /dev/random flows freely from initial boot. This is a great improvement over the status quo. The kernel's use of RdRand fails in this respect. /dev/random still blocks. It is not a complete solution. The downside to RNGd is a slightly higher computational overhead and a larger attack surface, but for a box you control, that may be moot. It's statistical tests seem misplaced. While the kernel keeps getting it wrong (in a way that keeps /dev/random blocking where it need not) RNGd is the path of least resistance that does get deployed and does cause /dev/random to actually work. I would not characterize the Linux RNG issue as "fully resolved" in any way. Until every CPU maker includes a source of entropy by design (instead of by accident) and the Kernel gets off its high horse and chooses to use them and the kernel gets pre-configured in distros with sane parameters, crypto software will continue to fail from low entropy situations. _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
