[Cryptography] combining lots of lousy RNGs ... or not

[Ray Dillinger]

In practical terms, an old Bitcoin mining stick, which continually
hashes its state plus a nonce, is a nice thing to feed to your RNG.  I
picked one up after the Debian Uninitialized RNG fiasco.  It uses a
fairly trustworthy hash algorithm, its output absolutely can be audited,
it's too high-frequency for someone more than ten feet and a stucco wall
away to easily track by electronic means, it produces output at an
easily adjustable rate, and it can remain powered avoiding loss of state
across reboots.

So I'm pretty confident that it helps, and I 'tail -r /dev/antminer >
/dev/random' in an early bootup script.

Forget mining Bitcoin with it; those USB stick miners are now utterly
useless for that, and so can be had cheap.  But they're still "pretty
good" sources of bits.  There is a good chance that it's EM-loud and
broadcasts its state or nonce or both, (whether because backdoored or
just not manufactured for security) but it still makes me happy,
especially because the /dev/random mixer keeps stirring the pot.  Even
if it's EM-loud, its contribution to the mixer makes me about 10
decimals more confident that the mixer's output is unpredictable to all
opponents.

If we use 128-bit keys (ie, ~37 decimals) and we want the same security
from our RNG that we get from our ciphers, it follows that I want bit
sources which *I* believe with ~37 decimal confidence to be
unpredictable in combination to all adversaries.  The Bitcoin stick
alone doesn't get there, but it sure helps.

It eliminates from consideration many attackers that could easily and
remotely take advantage of a  backdoored RDRAND or a
failure-to-properly-initialize mistake in implementation.


				Bear


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20161122/00b450b5/attachment.sig>