NIST have a long history of positive work in the security field, so they have that in their favour. They also publish the "hash of the previous value to chain the sequence of values together", so presumably someone could record all of the values and test them for randomness ... but still, if this became the default source for random number generators in operating systems everywhere, it would present a very attractive target.
Imagine you have six sources of entropy and they all suck except the third one, which is independent and works. All the others are actively working together to manipulate your result.
Then xor'ing the bits
a xor b xor c xor d xor e xor f
can be rearranged to
(a xor b xor d xor e xor f) xor c
and it is the exact same expression. (xor is commutative.)
But now it's clear that C acts like a "one time pad" on the whole rest of the expression, making it truly random.
Of course, if it's not independent, for example if A is reading C and set equal to it, then this argument does not apply.
But it is highly unlikely that this beacon could be specifically manipulated to target weakening a single specific user of it. For one thing it couldn't be done with more than one person at a time.
So we can ignore the possibility that it is not independent of your other sources of entropy.
Go ahead, go wild including it.
(I say this even though I place the likelihood that this beacon is backdoored and predictable to the government, at 200:1 in favor.)
Two techniques you can use:
1. Mix with other sources of entropy such as number of milliseconds on the system clock. Doesn't matter if they're weak - do this yourself.
2. Draw from the beacon continuously, discarding values when you don't need thsm. Don't just draw when you need it.
These two techniques will make it almost impossible to reconstruct the random numbers, even if the sequence were predictable by someone.
By contrast, only using this beacon mixed with a backdoored rng, without xoring by some function of the system clock yourself, and only drawing the number of bits you need and doing so every time you need them, will make your solution considerably easier to bruteforce if your rng is backdoored.
First let me explain how prior probability works to you guys.
Imagine that I tell you these two facts: there is a bag (perhaps very large) with both fair coins and exceedingly unfair coins in it - such as coins so heavily weighted that they land "heads" approximately 90% of the time.
You draw a coin at random and flip it a few times, and get the sequence: heads, heads, heads, heads, heads, heads, heads, heads, heads, heads. (10 heads.)
What do you think the likelihood is that you drew a fair coin?
You might think it's exceedingly unlikely.
However, if I then told you there were 2046 fair coins and only two weighted coins in the bag, it turns out you'd be down to 50/50. If there were a billion fair coins and 1 weighted coin, you'd be almost certain to have drawn a fair coin.
The fact that you just threw ten heads pales in comparison with the prior probability.
Now what we're looking at is that you flipped it ten times and it seems totally normal. But the bag is full of ten thousand heavily weighted coins and only one fair coin.
It doesn't matter how great ("fair") the announcement looks, because we know from historical reasons the prior probability that it's actually fair.
Reading through the announcement with these eyes you get:
>However, demonstrably unpredictable values are not possible to obtain in any classical physical context.
Which is pretty absurd. Reading the brownian motion of molecules with a sensor will not allow anyone to predict when the next molecule hit. XOR-ing two classical independent processes so that the second process has no access to the first and vice versa removes any remaining possibility of error. If any source in an independent xor chain is random the rest can be weighted and it's no problem, because xor is a commutative operation, you can rewrite the chain so the random source is last, and it will act as an OTP. So just a couple of low-tech classical noisy sources of entropy are more than enough.
Instead we have a very sophisticated setup that can be backdoored at a very low level, and almost certainly is.
A plausible reason for this announcement is so that writers of backdoored cryptography can use the output of this as a putatively random seed, both claiming an honest mistake for using it in cryptography, and also perhaps writing architecture that seems not to require a truly random source but can in fact be broken by a source whose upcoming values are known to the government.
What you're looking at is almost surely a government program to help other government programmers produce broken cryptography.
When combined with the prior probability, there is almost no chance (perhaps 1 in 200) that the architecture in the write-up has been produced for any other purpose, or cannot be predicted by someone having access to the sequence and special information on the process used to produce it.
-
EDIT: downvoters don't understand the analysis. Sorry.
Given that any sequence of {heads, tails} is equally likely to any other sequence of {heads, tails} for a fair coin, what information does flipping the coin give you? There's no way to disprove that a coin is fair.
Rather than a "proof" you should think about the payoff if you then had to bet about which was which and then it was revealed.
If one landed heads 105 times and tails 3 times in your quick test, there is a conceivable universe in which that was the fair coin. But you would not accept 200:1 payoff to bet that that is the fair coin. You are much more confident than 200:1 that it is the weighted coin.
Even assuming you're right, why would they put in giant red text "DON'T USE THIS FOR CRYPTOGRAPHY" at the top, if their goal was to get you to use it for cryptography?
Nonsense
https://google.com/search?q=nist+backdoor
Further, I reviewed the architecture in the write-up.
If they wanted a random beacon that was not backdoored, they would xor it with samples from a lava lamp or something simple and unpredictable and point a web cam at it that anyone can see. As explained, this cannot reduce the randomness. They would not carefully design an architecture that is possible to backdoor, which is what we are reading about.
As for the reason why they say it should not be used in cryptography, I addressed these in my original comment.
In my estimation the chances that the government can predict the output of this random beacon are 200:1 in favor.
You are free to disagree, that's fine.