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

[Sandy Harris <sandyinchina@gmail.com>]

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?