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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140613015610.GA7986@thin
