[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHmME9qd_jHB-7FHNqNhZC1AQBAZjUjQAYwqcLn3sz-FXoEAFw@mail.gmail.com>
Date: Sat, 2 Apr 2022 15:48:17 +0200
From: "Jason A. Donenfeld" <Jason@...c4.com>
To: Sandy Harris <sandyinchina@...il.com>
Cc: LKML <linux-kernel@...r.kernel.org>,
Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
Dominik Brodowski <linux@...inikbrodowski.net>,
"Theodore Ts'o" <tytso@....edu>
Subject: Re: [PATCH v2] random: mix build-time latent entropy into pool at init
Hi Sandy,
On Sat, Apr 2, 2022 at 6:45 AM Sandy Harris <sandyinchina@...il.com> wrote:
> > In switching to using a hash function, this required us to
> > specifically initialize it to some specific state,
>
> Hash functions do not require that. Any such function must
> work correctly with a new input block and a more-or-less
> random state from hashing previous blocks.
Well yes and no. Strictly no in the sense that blake2s_state has a few
book-keeping variables, which we probably benefit in terms of caching
from having next to the other state variables. Almost yes in the sense
that in the ideal model, the hash state can become _anything_ so
initializing it to random might be okay. But in practice, maybe not,
because at the moment the latent entropy plugin is actually expanding
a 64-bit seed with a basic LFSR, rather than supplying more uniformly
random bytes (I have a patch out for that now). These details might
matter, so rather than tempting fate, just calling blake2s_update the
way the hash function is intended to be used seems a lot more cautious
than poking at the function's innards unnecessarily.
Jason
Powered by blists - more mailing lists