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?
On Thu, Jan 27, 2022 at 05:04:07PM +0800, Sandy Harris wrote:
> Current code in extract_buf() declares a local struct blake2s_state,
> calls blake2s_init() which uses initialisation constants
Which is good, because BLAKE2s is defined to use certain constants. If
different constants were used, then it wouldn't be BLAKE2s anymore, but rather
some homebrew crypto with unknown security properties (like the old "SHA-1" that
wasn't really SHA-1).
> and moves data into the chacha state with memcpy().
It's actually XOR'd in. Please take a closer look at crng_reseed().
- Eric
Eric Biggers <[email protected]> wrote:
> On Thu, Jan 27, 2022 at 05:04:07PM +0800, Sandy Harris wrote:
> > Current code in extract_buf() declares a local struct blake2s_state,
> > calls blake2s_init() which uses initialisation constants
>
> Which is good, because BLAKE2s is defined to use certain constants. If
> different constants were used, then it wouldn't be BLAKE2s anymore, but rather
> some homebrew crypto with unknown security properties (like the old "SHA-1" that
> wasn't really SHA-1).
That's a reasonable argument & something very similar applies to
chacha usage. I do not think it holds water, though, since we
would still use the blake & chacha transforms. Even in blake,
every iteration except the first applies the transform to
arbitrary somewhat random data.
> > and moves data into the chacha state with memcpy().
>
> It's actually XOR'd in. Please take a closer look at crng_reseed().
You are correct.
On 1/28/22, Sandy Harris <[email protected]> wrote:
>
> Even in blake,
> every iteration except the first applies the transform to
> arbitrary somewhat random data.
No. The compression function uses the IV always, to break potential symmetries.
If you have a concrete idea, please just send a patch with good argumentation.