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

* RFC random(4) We don't need no steenking ...
@ 2022-01-27  9:04 Sandy Harris
  2022-01-27 19:08 ` Eric Biggers
  0 siblings, 1 reply; 4+ messages in thread
From: Sandy Harris @ 2022-01-27  9:04 UTC (permalink / raw)
  To: Linux Crypto Mailing List, Ted Ts'o, Jason A. Donenfeld,
	Herbert Xu, John Denker

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?

^ permalink raw reply	[flat|nested] 4+ messages in thread