Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Sat, 18 Jun 2022 01:37:30 +0200
From:   "Jason A. Donenfeld" <Jason@zx2c4.com>
To:     Sandy Harris <sandyinchina@gmail.com>
Cc:     Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
        LKML <linux-kernel@vger.kernel.org>, Ted Ts'o <tytso@mit.edu>
Subject: Re: [PATCH] random Remove setting of chacha state to constant values.
Message-ID: <Yq0QOmahm8m018NK@zx2c4.com>
References: <CACXcFmmw8bzSr-pmTauMS7a=036eW0=1KLdwAD1MOB_fY-7VRg@mail.gmail.com>
 <Yqr+rFeixFuHzyHD@zx2c4.com>
 <CACXcFmmdrELd8CkwmBQf5-W7PkR=McjcUz9kPDzaCh=NrODKUA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CACXcFmmdrELd8CkwmBQf5-W7PkR=McjcUz9kPDzaCh=NrODKUA@mail.gmail.com>
Precedence: bulk

On Sat, Jun 18, 2022 at 07:17:00AM +0800, Sandy Harris wrote:
> Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> 
> > ChaCha is a permutation that requires those constants.
> 
> No. The actual permutation does not use the constants.
> They are used in setting up the state & directly affect
> only the first round. The other 19 rounds do not use
> the constants; they operate on the more-or-less random
> state left by the previous round.

I guess. But that just seems like all the more reason to stick with the
constants in that first round, as chacha lacks round constants like
"hermetic" permutations. Better to give less control over that initial
state. Anyway, we're not going to veer off into lala land and redesign
chacha on lkml.

> There is no such argument for
> memset(&chacha_state[12], 0, sizeof(u32) * 4);
> ChaCha has a counter and a nonce in those
> bits, so setting them to zero is a deviation.

No. There's a new key each time. So the nonce begins at zero. And the
counter begins at zero as well at the beginning like usual. So it's
actually a rather boring by-the-books usage of chacha.

> Dropping the memset() and using whatever
> the existing state has there may not be ideal,
> but it is certainly better than the zeroes.

I'm not so sure about that. For starters, it means that we'll never
actually exceed the first 32 bits, and so the branch for the increment
of the next word is never true, which has some tiny value. And as for
the nonce, I'd like to reserve that for whatever interesting use comes
up in the future (like using the cpu number or something in an
interesting parallel design).

But the larger reason for rejecting your idea wholesale is that I'm
trying to enforce the property that input data goes through our hash
function (via mix_pool_bytes). Full stop! It's time that this
willy-nilly stuff ends where we're feeding in things right and left with
no actual design on which is ingesting what input and how it interacts.
So if you do think that a particular block of memory somewhere at some
point has some entropic value, then by all means call mix_pool_bytes or
add_device_randomness on it. But don't try to stuff it in where it
doesn't belong.

The type of valuable patch I'd like to encourage is this recent one from
LinusW: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ac9d25557dcc9fe90ed12bfbb6db401e892ca004
This seems like the kind of thing that might really help the situation
on certain devices in a real way. More of that! Less of fake crypto.

Jason