[cryptography] on using RDRAND [was: Entropy improvement: haveged + rngd together?]
dj at deadhat.com
dj at deadhat.com
Sun Dec 1 15:27:34 EST 2013
> Am Freitag, 29. November 2013, 19:05:00 schrieb coderman:
> Hi coderman,
>> On Fri, Nov 29, 2013 at 4:54 PM, coderman <coderman at gmail.com> wrote:
>> > ...
>> > 0. "extract_buf() - 'If we have a architectural hardware random number
>> > generator [ED.: but only RDRAND], mix that in, too.'"
>> > 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:
>> 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.
More information about the cryptography