[Cryptography] NIST Randomness Beacon

[John Kelsey]

One beacon is not worth all that much, because of the trust issues.  (Along with not trusting NIST, you may also not perfectly trust everyone involved in the project, everyone who might have access to the machine running the beacon, or the security of the beacon itself.)  Many beacons run by mutually mistrustful entities under separate political regimes and ownership, with separate codebases and hardware, but using the same message format, could be worth a lot more.  

Similarly, including the beacon in a protocol where each of us is exchanging random numbers to contribute to a seed is nice because it can be verified by people in the future, who aren't yet participants in the transaction.  

Suppose we decide to build a combined seed to decide which ballot boxes to audit.  We do:

Alice the Democrat generates R[a] and sends hash(R[a])
Bob the Republican generates R[b] and sends hash(R[b])
They both reveal their random numbers and compute the agreed-upon seed 

S = hash(R[a] || R[b])

Now, Carol the Green, who wasn't a party to this whole thing, has to trust that Alice and Bob didn't collaborate.  Adding in a beacon input addresses this somewhat.

Alice and Bob do the same thing as above, but also include a commitment that they will take the NIST beacon value as of tomorrow at noon Eastern time and mix it in.  

At noon tomorrow, they get R[beacon], reveal their random numbers, and derive

S = hash(R[a] || R[b] || R[beacon])

If Carol thinks Alice and Bob are collaborating with the beacon, this doesn't help.  But if she thinks it's easier for the local Republican and Democratic bosses to cooperate than for them to subvert the beacon, then this adds some assurance for Carol, as she audits the generation of this shared seed as an outsider.  

--John