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). 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
