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;
MIME-Version: 1.0
References: <CACXcFm=y9dR5DONeoLq1OQZp7fiFTEYTn_ir=c4S=UfyxTGWpQ@mail.gmail.com>
In-Reply-To: <CACXcFm=y9dR5DONeoLq1OQZp7fiFTEYTn_ir=c4S=UfyxTGWpQ@mail.gmail.com>
From:   Sandy Harris <sandyinchina@gmail.com>
Date:   Thu, 19 May 2022 14:10:59 +0800
Message-ID: <CACXcFmn2wKVf7eh-qYsgp3x-acrf0=c8ur-UARcht5Dd3=epYg@mail.gmail.com>
Subject: Re: [RFC] random: use blake2b instead of blake2s?
To:     Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
        "Jason A. Donenfeld" <Jason@zx2c4.com>, "Ted Ts'o" <tytso@mit.edu>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Sandy Harris <sandyinchina@gmail.com> wrote:

> The original random.c used a 4k-bit input pool, ...

> Blake comes in two variants, blake2s and blake2b; ...
>
> To me, it looks like switching to 2b would be an obvious improvement,
> though not at all urgent.

I'd actually go a bit further and have 2k bits of input pool,
two blake2b contexts; probably make inputs alternate
between them. It would also be possible to put each
input into both pools.

For output, have a flip-flop variable and alternate between
the pools with some sequence like:
: mix some extra entropy into pool
: generate 512 bits output
: mix that back into the other 2b context
: 8-round chacha on output
: mix output into chacha context

Mixing output from one context into the other ties the
two together so in effect we have a 2k-bit input pool.

Chacha is designed to be non-invertible so the
8-round instance prevents a rather unlikely
attack. Even if an enemy manages to get the
chacha state & infer some of the rekeying inputs,
they do not get direct access to blake output.
They would need to repeatedly break chacha8
to get any data that might let them attack blake.