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.
Date: Sat, 18 Jun 2022 11:49:22 +0200 [thread overview]
Message-ID: <Yq2fohMo90Tk0A/T@zx2c4.com> (raw)
In-Reply-To: <CACXcFmma8euek8Z9T6m4jiyD1poyo3WHrLZKuN22sE20hFXNpA@mail.gmail.com>
On Sat, Jun 18, 2022 at 08:38:23AM +0800, Sandy Harris wrote:
> Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>
> > > 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.
>
> No. ChaCha has a random nonce.
Maybe you're thinking of xchacha? Generally it's not recommended to pick
nonces at random when they're only 64 bits. And it's even not great to
do for 96 bits. In this case here, it doesn't matter, because as
mentioned, the key is fresh each time. But if we're just going by the
book on how people generally use chacha, nonces are typically
sequential.
> > 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.
>
> For input data, I agree completely.
>
> > 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.
>
> This is not input data but more-or-less random state. I'm not trying
> to input it, just to leave it where it belongs rather than overwriting
> it with constants.
What's the difference? If you think you've got some "more or less random
state" that would be useful input as something to influence the rng's
output, call mix_pool_bytes on it. (Also, "more or less random" is
probably not a good way to describe uninitialized stack. It's way less
random than more, and sometimes controllable.)
Sorry, but I'm just not interested in complicating the design with
handwavy things like this.
Jason
prev parent reply other threads:[~2022-06-18 9:49 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-16 5:18 Sandy Harris
2022-06-16 9:58 ` Jason A. Donenfeld
2022-06-17 23:17 ` Sandy Harris
2022-06-17 23:37 ` Jason A. Donenfeld
2022-06-18 0:38 ` Sandy Harris
2022-06-18 9:49 ` Jason A. Donenfeld [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Yq2fohMo90Tk0A/T@zx2c4.com \
--to=jason@zx2c4.com \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sandyinchina@gmail.com \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®