Re: use of RDRAND in $random_library

[Thorsten Glaser <tg@debian.org>]

Gunnar Wolf <gwolf <at> gwolf.org> writes:

> using entropy to seed a PRNG, if you have several shitty entropy
> sources and one _really_ good one, and you xor them all together, the
> resulting output is as random as the best of them. If your hardware

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).

① MirBSD first accumulates them, using a hash that is almost²
  Bob Jenkins’ one-at-a-time hash (plus, thanks for tytso for
  pointing this out, some stirring) in an 128-byte buffer, no
  matter how fast they come in. Then, at most once a second,
  if the buffer has accumulated at least 128 bytes, this is
  mixed into an aRC4 structure which is never used directly
  (i.e. no costly “throw away initial keystream” and all that
  needed) but only used for contributing bytes to the “main”
  entropy pool (what is /dev/urandom in Linux) and the “real”
  aRC4 pool. (We don’t use XOR here either because we know
  they are not entirely independent… in fact we use this
  property to ensure some amount of stirring/mixing around.)

② It adds 1 in the initial step so that even adding a NUL byte
  to a 0x00000000 state contributes, and the finaliser step is
  replaced by AES’ MixColumn step, which is a bit slower, but
  has better mixing properties without losing anything from the
  original finalising step. Also, it is used during stirring the
  128-byte buffer.

bye,
//mirabilos