On Sat, Jun 18, 2011 at 03:40:50PM -0700, H. Peter Anvin wrote:
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.
From your description of the instruction, this sounds almost identical to me as
what I suggested in using an instance of the cprng module in the kernel as the
drng coupled with using the tsc entropy as the trng input to reseed it. We
could use rnrand when possible on the input to the entropy pool, and the
software cprng when that wasn't available.
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.
It sounds to me like, if its desireous to bypass the entropy pool, then we
should bypass the /dev/random path altogether. Why not write a hwrng driver
that can export access to the rdrand instruction via a misc device.
Neil
-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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
