On 06/17/2011 01:28 PM, Matt Mackall wrote: >> >> The one use case that it is cryptographically insufficient for is to >> seed a new PRNG, which probably means it is unsuitable for being fed >> as-is into /dev/random. > > The thing to understand about the input side of /dev/random is that it's > COMPLETELY immune to untrusted data. So there's absolutely no harm in > sending it data of questionable entropy so long as you don't tell it to > account it. And, of course, if it DOES contain entropy, it makes things > better. > > Think of it this way: I have a coin in my pocket. You, the attacker, > tell me to flip it. You can do that any number of times and not improve > your guess about the coin's state over your initial guess. This is what > it means to have a reversible mixing function: no number of iterations > reduces the degrees of freedom of the pool. > What I meant is that it is unsuitable to *bypass the pool* for /dev/random. I think we can -- and almost certainly should -- use RDRAND on the input side; we just have to figure out the accounting. However, RDRAND is high enough quality (and high enough bandwidth) that it should be not just possible but desirable to completely bypass the pool system for /dev/urandom users and pull straight from the RDRAND instruction. I don't actually know what the exact numbers look like, but the stall conditions being looked at are of the order of "every core in the socket trying to execute RDRAND at the same time." -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
