linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: "Theodore Ts'o" <tytso@mit.edu>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] random: use named fields for adjusting chacha state
Date: Thu, 20 Jan 2022 22:53:58 +0100	[thread overview]
Message-ID: <CAHmME9pDHLXUdovYNPkFzOVecPmyq_bKxW9MDB5WHrsHv_o_4g@mail.gmail.com> (raw)
In-Reply-To: <Yemg2rWLqmYNzcDF@mit.edu>

Hi Ted,

On Thu, Jan 20, 2022 at 6:50 PM Theodore Ts'o <tytso@mit.edu> wrote:
> This change means that we're only initializing the key, but we're not
> initializing the counter/nonce (well, IV) value.  Could you fix this,
> please?

Right, as I mentioned in the commit message, this was the point. I'll
understand if you don't want to make this change, but the idea is that
indeed we make the nonce and counter values start at zero. This is
what's done in the original "fast key erasure" chacha rng [1,2] and
openbsd's arc4random [3]. And it seems sensible, in that we're not
really getting anything from having a 384-bit key over a 256-bit one.
It's not actually a meaningful reduction in security, and it
simplifies analysis by having the key rows used explicitly for keys
and the public rows used explicitly for public-ish values. It's always
scary to do seemingly _less_, and you could argue that these fields
are fine as input for a little additional pizzazz, so why not? If
that's your perspective, I can understand, and I'm not wedded to
changing it like this. On the other hand, if you agree it doesn't
change things cryptographically, and it simplifies the analysis, then
we can make the change. Either way works for me.

Jason

[1] http://blog.cr.yp.to/20170723-random.html
[2] https://github.com/jedisct1/supercop/blob/master/crypto_rng/chacha20/ref/rng.c
[3] https://github.com/openbsd/src/blob/master/lib/libc/crypt/arc4random.c

  reply	other threads:[~2022-01-20 21:54 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-30 16:50 [PATCH] random: avoid superfluous call to RDRAND in CRNG extraction Jason A. Donenfeld
2021-12-30 22:13 ` Theodore Ts'o
2021-12-30 22:58   ` Jason A. Donenfeld
2021-12-31  3:35     ` Theodore Ts'o
2021-12-31 11:49       ` [PATCH v2] " Jason A. Donenfeld
2021-12-31 17:13         ` Theodore Ts'o
2022-01-04  5:03           ` Sandy Harris
2022-01-04  5:55             ` Theodore Ts'o
2022-01-20 15:03               ` Jason A. Donenfeld
2022-01-20 15:07                 ` [PATCH] random: use named fields for adjusting chacha state Jason A. Donenfeld
2022-01-20 17:50                   ` Theodore Ts'o
2022-01-20 21:53                     ` Jason A. Donenfeld [this message]
2022-01-05 15:28         ` [PATCH v2] random: avoid superfluous call to RDRAND in CRNG extraction Ard Biesheuvel

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=CAHmME9pDHLXUdovYNPkFzOVecPmyq_bKxW9MDB5WHrsHv_o_4g@mail.gmail.com \
    --to=jason@zx2c4.com \
    --cc=linux-kernel@vger.kernel.org \
    --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;
as well as URLs for NNTP newsgroup(s).