Re: Flaw in "random32: update the net random state on interrupt and activity"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux