>> On Aug 5, 2020, at 3:06 PM, tytso@xxxxxxx wrote: >> >> On Wed, Aug 05, 2020 at 09:06:40AM -0700, Marc Plumb wrote: >> 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? > > I haven't looked at the users of net_rand_state, but historically, the > networking subsystem has a expressed a (perceived?) need for *very* fast > mostly-random-but-if-doens't-have-to-be-perfect-numbers-our-benchmarks- > are-way-more-important numbers. As in, if there are extra cache line > misses, our benchmarks would suffer and that's not acceptable. > > One of the problems here is that it's not sufficient for the average case > to be fast, but once in every N operations, we need to do something that > requires Real Crypto, and so that Nth time, there would be an extra lag > and that would be the end of the world (at least as far as networking > benchmarks are concerned, anyway). I respectfully disagree with the supposed network people :). I’m working, slowly, on a patch set to make this genuinely fast. > So in other words, it's not enough for > the average time to run get_random_u32() to be fast, they care about the 95th or > 99th percentile number of get_random_u32() to be fast as well. > > An example of this would be for TCP sequence number generation; it's > not *really* something that needs to be secure, and if we rekey the > RNG every 5 minutes, so long as the best case attack takes at most, > say, an hour, if the worst the attacker can do is to be able to carry > out an man-in-the-middle attack without being physically in between > the source and the destination --- well, if you *really* cared about > security the TCP connection would be protected using TLS anyway. See > RFC 1948 (later updated by RFC 6528) for an argument along these > lines. > >> 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. > > Well, technically it's not supposed to be a secure cryptographic > primitive. net_rand_state is used in the call prandom_u32(), so the > only supposed guarantee is PSEUDO random. > > That being said, a quick "get grep prandom_u32" shows that there are a > *huge* number of uses of prandom_u32() and whether they are all > appropriate uses of prandom_u32(), or kernel developers are using it > because "I haz a ne3D for spE3d" but in fact it's for a security > critical application is a pretty terrifying question. If we start > seeing CVE's getting filed caused by inappropriate uses of > prandom_u32, to be honest, it won't surprise me. > > - Ted
