Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
From:   Sandy Harris <sandyinchina@gmail.com>
Date:   Thu, 27 Jan 2022 17:04:07 +0800
Message-ID: <CACXcFmkhWDwJ2AwpBFnyYrM-YXDgBfFyCeJsmMux3gM8G+Gveg@mail.gmail.com>
Subject: RFC random(4) We don't need no steenking ...
To:     Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
        "Ted Ts'o" <tytso@mit.edu>, "Jason A. Donenfeld" <Jason@zx2c4.com>,
        Herbert Xu <herbert@gondor.apana.org.au>,
        John Denker <jsd@av8n.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

In normal usage of either a hash or a cipher, consistent results are
needed because we want the hash to be usable for authentication and
the cipher to be decryptable. We therefore require a standard
initialisation using known constants, macros to deal with endinanness
so different systems can get the same results, and sometimes locking
of the inputs to avoid having a hash give indeterminate results.

I would contend that in the context of random(4), none of the above
are desirable, except perhaps for the first initialisation at boot
time & even that should use random data rather than constants if
possible, Thereafter, the input pool, hash context & chacha context
should all be updated only with ^= or += so they cannot lose entropy.
Nor should any code here lock any structure it only reads or
manipulate data for endianness.

Current code in extract_buf() declares a local struct blake2s_state,
calls blake2s_init() which uses initialisation constants, and moves
data into the chacha state with memcpy(). As I see it, those are
mistakes.

I'm inclined to think we need only one 512-bit context[]; use chacha
on it to generate output and hash directly into it to rekey. I have
not yet worked out the details or all the implications.

Other opinions?