Re: use of RDRAND in $random_library
Thorsten Glaser <tg@debian.org> writes:
> Your theory may be good, but we are talking about a scenario in which at
> least one of the other sources may be not just “shitty entropy” but “a
> bytestream specifically designed to counteract entropy in the output
> stream of the XOR” (independence is needed).
> You’d better use a mechanism that first hashes together the “untrusted”
> sources¹ and only combine that with the “a bit more trusted” entropy
> later, using appropriate algorithms. Sure, XOR is fast, but arc4random
> on MirBSD performs pretty well too (I get about 40 MiB/s easily… on old
> Pentium-M hardware).
This is the reason why Fortuna uses SHA-256 to mix in entropy. Provided
that you use a hash function to mix in entropy and that hash function
satisfies the requirements of a cryptographic hash function, there should
be no way for an attacker with control over an entropy source to reduce
the total entropy created by the the other entropy sources. The worst
they should be able to do is add zero entropy.
Cryptography Engineering has an excellent chapter on pseudorandom number
generators that gets into the issues here.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: