Hi Simo, Your message makes no sense to me. > Note that there is no study > about using internal states of hash functions, it would be better to Ignoring your probably wrong mention about "no study", we're not making any use of "internal states". We're using the hash function off the shelf without modifications. There's no whacky bespoke crypto going on, no use of "internal states", nothing that matches your description. > if the current code is mistakenly stretching the entropy, perhaps the > correct curse of action Except it's not. The non-underscore version calls into account(), and returns false when it's not sufficiently full. I'm also not sure it matters in the way you think it does; perhaps you could clarify what you mean by "mistakenly stretching the entropy" and what you think this enables. > they are stretching the entropy, the risk is compounding errors and Compounding errors? This doesn't make any sense. > It would also be nice to have an explanation (in the patch or at least > the commit message) about how entropy is preserved That iterative hashing serves as a good entropy accumulator is rigorously shown in the paper that the commit message references. And either way, we never reseed the crng with more than 32 bytes, so what's happening here is rather boring. Thanks, Jason
