Remix.run Logo
Taek an hour ago

Unfortunately you are not correct, and djb explains it quite well here:

https://blog.cr.yp.to/20140205-entropy.html

TL;DR adding a compromised source of entropy to a pool of already secure sources of entropy can catastrophically compromise the final result.

It's better to source entropy from a smaller number of harder-to-compromise sources. That's why I like the iterated hashes method; the security surface area is both very small and highly likely to be well tested.

strenholme an hour ago | parent [-]

Indeed, that’s a real attack.

From that page:

>>>what I'm advocating here, for security reasons, is a sharp transition between

* before crypto: the whole system collecting enough entropy;

* after: the system using purely deterministic cryptography, never adding any more entropy.<<<

Which is exactly how a XOF should be used, and how I used the XOF in my code. A malicious source of entropy will need to perform 2^n operations to control n bits of the XOF’s output, and that’s assuming the malicious entropy source somehow perfectly knows the other entropy the XOF is using.

Taek 36 minutes ago | parent [-]

Yes but why introduce complexity and room for error when something that's extremely basic is also sufficient?

The point here is to eliminate surface area for mistakes, and an XOF has a much larger and more complex implementation than iterated hashing against a timer.