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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/loom.20140616t140448-...@post.gmane.org
