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?
