Nice explanation of uses and how entropy is converted into a constant. Reminds me of an old post I did on types of randomness http://www.statisticsblog.com/2012/02/a-classification-schem...
"The anti-use would be in any sort of cryptographic implementation, since any "entropy" you'd be gaining by using this data as a source of randomness is completely counteracted by the fact that the source is known. Randomness becomes deterministic once the source of the randomness is disclosed and broadcast ... "
In this design, that's true. But Rabin's hyper-encryption is an example of how a strongly secure encryption system can be built using a very high-bandwidth source of public randomness.
Part of hyper encryption strength is derived from assuming that the public randomness cannot be recorded due to cost. This beacon only emits 512 bits every 60s, so that is easily recordable.
"The anti-use would be in any sort of cryptographic implementation"
I'm not ready to disagree with you (yet) but I was thinking about the possibility of turning a pseudo-random number into a truly random number. If you generate a number using a PRNG and use that as a bit offset (via the timestamp), you might get a better string of random bits as an input to your cryptography system. Of course this relies on there being enough previously generated bits available.
That is pure security by obscurity. If I know the output of the PRNG, and that this method is being used, I also know the random number. So attacking it is no harder than attacking the PRNG itself.
Wouldn't the weak point in that system then be the PRNG? If so, doesn't that require the use of a crytographically secure PRNG in the first place?
Yes ... the PRNG is the weak point (just as it always is). And if you're only using enough bits from the PRNG to generate a timestamp, you also have to worry about whether the distribution is flat.
Part of the idea behind this is that you can run your own randomness beacon in the same manner, and if you and another person want to make a bet like that, you can each use your own beacon and xor the values together to get a new, previously unknowable, random value.
The second use is pretty much exactly how bitcoin blockchain betting systems work. It'd be interesting to know if this could be (or has been?) done in etherium or similar to lower the trust required even more.
Re:NIST Random Beacon
by stephengillie on Thursday July 20, 2017 @02:41PM
(#14815184)
Could we use it as a source of "reproducable randomness"? For instance, use this as an RNG during game development?
Re:NIST Random Beacon
by URSpider94 on Thursday July 20, 2017 @02:44PM
(#14815218)
Yes, exactly. If you want to run a regression test on your game, you could compare results by feeding the string in place of your rand() function, starting from the same offset.
Given what we know now about the nsa, isn't it fairly safe to assume they _have_ been comprised?
Re:NIST Random Beacon
by URSpider94 on Thursday July 20, 2017 @02:48PM
(#14815245)
I'm not sure what you are implying. If you're asking if the NSA can read NIST's mail -- maybe? If you are saying that the NSA can hack/compromise this particular device in a way that would benefit national security - I think you'll have to sketch that out a little more for me to go along.
First, in scientific coding, one of the big challenges is in reproducing the results of a program that uses random numbers. A classic solution is to use a deterministic pseudo-random number generator that can be seeded, such that if it's seeded with the same number on two different runs, it will always generate the same output. This could be a great replacement for that, since you could write a rand() routine that accepts a start point in the chain and traverses forward to output random values on demand.
Second, you could use this as a source of future randomness -- for example, I will award you $x if the next eight bits out of the random generator represent 0-127, and will award the $x to me if they represent 128 or greater. We can both check the value, and we don't have to trust each other.
The caveat with the last example is that we both have to trust that NIST has not been compromised ...
The anti-use would be in any sort of cryptographic implementation, since any "entropy" you'd be gaining by using this data as a source of randomness is completely counteracted by the fact that the source is known. Randomness becomes deterministic once the source of the randomness is disclosed and broadcast ...