Re: Re: use of RDRAND in $random_library
Theodore Ts'o wrote:
> On Thu, Jun 12, 2014 at 10:19:37AM -0700, Russ Allbery wrote:
> > I've never seen a convincing argument that the kernel /dev/random is
> > likely to be *less* secure than the hardware random number generator.
> > It's either more secure or the same level of security. Given that, it's a
> > risk analysis, and the fact that we have absolutely no idea what the
> > hardware random number generator is doing, it would be quite possible to
> > insert a mathematical back door into it, and there's no way to audit it, I
> > understand why people want to put a software randomization layer that we
> > *can* audit in front of it.
>
> One thing to worry about is what happens if the software library (if
> it is implemented as a shared library) gets modified by a bad guy.
> One thing a really paranoid program can do is to mix (via XOR, for
> example) the output that it gets from /dev/urandom or this
> cryptorandom shared library with RDRAND.
If you don't trust a hardware random number generator, you should not
xor it and another random number source together; after all, if you
believe the numbers coming out of the hardware random source are not
actually random, you might just as easily believe that they're the
precise non-random values needed to xor with another CPU register to
produce non-random values. And assuming you *don't* believe that, then
there's little point in mixing a fast random source you trust with a
slow random source you trust.
(Also, if you don't trust a hardware random number generator, you should
ask yourself why you trust any other instruction on your CPU. If you
don't trust the hardware you run on, you're doomed anyway; it's a good
idea to reduce your attack surface, but your attack surface *always*
includes your hardware. But I'd prefer to sidestep that entire
argument, and instead suggest that it's (more) ridiculous to have this
argument in Debian rather than elsewhere.)
> That way, if Unit 61398 tries to hack the cryptrandom shared library,
If you can intercept calls to an arbitrary shared library, what stops
you from intercepting calls to open and read, feeding back non-random
data for reads of /dev/random and /dev/urandom?
- Josh Triplett
Reply to: