Re: RFC random(4) We don't need no steenking ...

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Eric Biggers <ebiggers@xxxxxxxxxx> 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.



[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]

  Powered by Linux