Hi Ted,
On 2020-08-05 8:34 a.m., tytso@xxxxxxx wrote:
On Wed, Aug 05, 2020 at 04:49:41AM +0200, Willy Tarreau wrote:
Not only was this obviously not the goal, but I'd be particularly
interested in seeing this reality demonstrated, considering that
the whole 128 bits of fast_pool together count as a single bit of
entropy, and that as such, even if you were able to figure the
value of the 32 bits leaked to net_rand_state, you'd still have to
guess the 96 other bits for each single entropy bit :-/
Not only that, you'd have to figure out which 32-bits in the fast_pool
actually had gotten leaked to the net_rand_state.
That's 2 bits which are already inputs to the fast_pool, so it doesn't
even make a brute force any more difficult.
I agree with Willy that I'd love to see an exploit since it would
probably give a lot of insights. Maybe at a Crypto rump session once
it's safe to have those sorts of things again. :-)
Just because you or I don't have a working exploit doesn't mean that
someone else isn't more clever. It pays to be paranoid about
cryptographic primitives and there is nothing more important than the
entropy pool.
So replacing LFSR-based PRnG with
something stronger which didn't release any bits from the fast_pool
would certainly be desireable, and I look forward to seeing what Willy
has in mind.
Isn't get_random_u32 the function you wrote to do that? If this needs to
be cryptographically secure, that's an existing option that's safe.
The fundamental question is: Why is this attack on net_rand_state
problem? It's Working as Designed. Why is it a major enough problem to
risk harming cryptographically important functions?
Do you remember how you resisted making dev/urandom fast for large reads
for a long time to punish stupid uses of the interface? In this case
anyone who is using net_rand_state assuming it is a CPRNG should stop
doing that. Don't enable stupidity in the kernel.
This whole thing is making the fundamental mistake of all amateur
cryptographers of trying to create your own cryptographic primitive.
You're trying to invent a secure stream cipher. Either don't try to make
net_rand_state secure, or use a known secure primitive.
Thanks,
Marc
