Message-Id: <4FAC5E1F-870F-47E3-BBE8-6172FDA15738@amacapital.net>
Date:   Wed, 5 Aug 2020 16:03:52 -0700
From:   Andy Lutomirski <luto@...capital.net>
To:     tytso@....edu
Cc:     Marc Plumb <lkml.mplumb@...il.com>, Willy Tarreau <w@....eu>,
        netdev@...r.kernel.org, aksecurity@...il.com,
        torvalds@...ux-foundation.org, edumazet@...gle.com,
        Jason@...c4.com, luto@...nel.org, keescook@...omium.org,
        tglx@...utronix.de, peterz@...radead.org, stable@...r.kernel.org
Subject: Re: Flaw in "random32: update the net random state on interrupt and activity"


>> On Aug 5, 2020, at 3:06 PM, tytso@....edu 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

Powered by blists - more mailing lists