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
From:   Sandy Harris <sandyinchina@gmail.com>
Date:   Thu, 19 May 2022 13:18:36 +0800
Message-ID: <CACXcFm=y9dR5DONeoLq1OQZp7fiFTEYTn_ir=c4S=UfyxTGWpQ@mail.gmail.com>
Subject: [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

The original random.c used a 4k-bit input pool, I think mainly because
sometimes (e.g. for a large RSA key) we might need up to 4k of
high-grade output. The current driver uses only a 512-bit hash
context, basically a Yarrow-like design. This is quite plausible since
we trust both the hash and the chacha output mechanism, but it seems
to me there are open questions.

One is that the Yarrow designers no longer support it; they have moved
on to a more complex design called Fortuna, so one might wonder if the
driver should use some Fortuna-like design. I'd say no; we do not need
extra complexity in the kernel & it is not clear there'd be a large
advantage.

Similarly, there's a Blake 3 that might replace Blake 2 in the driver;
the designers say it is considerably faster. I regard that as an open
question, but will not address it here.

What I do want to address is that the Yarrow paper says the
cryptographic strength of the output is at most the size of the hash
context, 160 bits for them & 512 for our current driver. Or, since we
use only 256 bits to rekey, our strength might be only 256. These
numbers are likely adequate, but if we can increase them easily, why
not?

Blake comes in two variants, blake2s and blake2b; presumably b and s
are for big & small. The kernel crypto library has both & the driver
currently uses 2s. 2s has 512-bit context (16 32-bit words) and can
give up to 256-bit output. 2b has 1024 (16 64-bit words) and can do
512 out.

To me, it looks like switching to 2b would be an obvious improvement,
though not at all urgent. Benchmarks I've seen seem to say it is
faster on 64-bit CPUs and slower on 32-bit ones, but neither
difference is huge.