> <i>it’s also almost impossible that I could influence the value ahead of time even if I had an insider at the NIST. Even if I’ve hacked into the NIST’s servers and tried to change that one value, the way that the values are chained will eventually make this tampering obvious.</i><p>In the example, the decision is made based on whether the first digit is odd. Even if you can't directly manipulate the final random number, couldn't "an insider at the NIST" simply generate random numbers until the resulting hash matches the desired pattern, and then publish that number?<p>DJB wrote an interesting blog post [1] discussing how a rogue entropy source can manipulate the output of a PRNG by emitting only the values that produce a certain pattern in the hash:<p>> <i>Here's an interesting example of an attack that can be carried out by this malicious source:</i><p>> <i>1. Generate a random r.</i><p>> <i>2. Try computing H(x,y,r).</i><p>> <i>3. If H(x,y,r) doesn't start with bits 0000, go back to step 1.</i><p>> <i>4. Output r as z.</i><p>> <i>This attack forces H(x,y,z) to start 0000, even if x and y were perfectly random. It's fast, taking just 16 computations of H on average.</i><p>[1] <a href="http://blog.cr.yp.to/20140205-entropy.html" rel="nofollow">http://blog.cr.yp.to/20140205-entropy.html</a>
You want your own random bits? Tune your AM radio between stations and record the resulting static to your PC. Grab the low bit from every 10'th sample or so and concatenate into a buffer until desired length is reached. You may want to XOR alternate samples to eliminate any voltage bias your sound card has to provide equal numbers of 0's and 1's.
A fair amount of discussion on the trustworthiness of NIST's beacon in particular, or how someone in control of a single beacon could influence the results in some way, but what about the author's suggestion for using multiple beacons run and controlled by competing interests?<p>Would there be any value in having companies like Microsoft, Google, Amazon, and Yahoo each running their own such beacon?<p>Edit: A bit of a tangent: if one were to create their own beacon service as a toy project, what would be the expected guarantees? Would a typical webserver's built-in randomness suffice for creating the seed values? What about interruptions in service/availability? Are timestamp gaps acceptable, or should they be backfilled after a server downtime?
<i>It’s the instant that separates the past, a period of time when the outcome has a probability distribution around its possible values, from the present in which the outcome is a simple constant number.</i><p>I sure don't claim to be a QM expert, but isn't this almost the exact definition of the wave function collapse when "observed", and so then are the two related in some mathematical way?
And from the 2009 class of critical design, the (mechanical) Coin Flipper: <a href="http://www.dotmancando.info/index.php?/projects/coin-flipper/" rel="nofollow">http://www.dotmancando.info/index.php?/projects/coin-flipper...</a>
There is no guarantee in this scheme that the data was actually generated at the time they state.<p>An insider can easily cycle through "random" numbers until the hash of the block has a desired characteristic.
> <i>We have no reason to believe this is happening, and it’s hard to imagine that the institution in charge of running the nation’s most accurate clocks would also be putting fake timestamps on the Beacon data.</i><p>This is hopelessly naive. We don't need to imagine that the NIST has been compromised: this has already happened. The NIST collaborated with the NSA to put a backdoor in the Dual_EC_DRBG standard[1]. Given this, I think we have to view the NIST as a compromised, untrusted entity.<p>As such, we must assume that an attacker has <i>both</i> the seed values and the NIST's private key. Given an attacker with this power, none of the approaches mentioned in the article provide security:<p>> <i>SHA-512 is not known to be broken at present, and so even working backwards through one of the SHA-512 stages is essentially impossible; two rounds is impossible squared.</i><p>The proposed attacker knows all the inputs to the SHA-512 hash and therefore does not need to reverse the hash.<p>> <i>So if you’d like to make your adversary’s work super-duper difficult, combine the Output Values from today at 7:00 pm and yesterday at 7:00 pm. Your adversary will have to work backwards through 2 x 24 x 60 = 2,880 SHA-512 stages to make the chain verify, still assuming that he knows the NIST’s secret key.</i><p>The proposed attacker knows all the inputs to the two SHA-512 hashes and therefore does not need to reverse the hash.<p>> <i>But suppose SHA-512 were broken and working it backwards were easy instead of being ridiculously difficult. Nothing prevents you from writing your contract to take the Output Value, add one to it, and run this value through a better hash of your choosing. Now the bad actor inside the NIST has to reverse your chosen hash function as well.</i><p>The proposed attacker knows all the inputs to whatever hash function you choose, and therefore does not need to reverse the hash. Adding one does effectively nothing, and I'm not sure how to prove what it doesn't do, because I'm not sure what the author thinks adding one does.<p>A better try might be to use an adequately-sized random secret key with a unique, incrementing nonce to generate the random numbers via a pseudo-random function. However, you shouldn't trust that this works without seeing a mathematical proof--something sorely lacking in the original article. And even if it does work, it's counter-productive to use the NIST random numbers as input for your function. There are plenty of other sources of inadequate randomness, and at least if you're using your own inadequately-random numbers you can determine <i>how</i> inadequate the input randomness is and act accordingly.<p>In short, the first step toward the perfect coin flip is to stop trusting the NIST.<p>[1] <a href="http://en.wikipedia.org/wiki/Dual_EC_DRBG" rel="nofollow">http://en.wikipedia.org/wiki/Dual_EC_DRBG</a>