
NIST Random Beacon - relyio
https://www.nist.gov/programs-projects/nist-randomness-beacon
======
URSpider94
There are two clear uses for this, and one anti-use.

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 ...

~~~
smoyer
"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.

~~~
grosscol
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?

~~~
smoyer
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.

------
kanzure
"DO NOT USE BEACON GENERATED VALUES AS SECRET CRYPTOGRAPHIC KEYS"

but people will do it anyway, the level of insanity out there is really high
[https://www.reddit.com/r/btc/comments/68pusp/gavin_andresen_...](https://www.reddit.com/r/btc/comments/68pusp/gavin_andresen_on_twitter_im_looking_for_beta/dh1cmfl/)
or even [https://arstechnica.com/security/2015/05/crypto-flaws-in-
blo...](https://arstechnica.com/security/2015/05/crypto-flaws-in-blockchain-
android-app-sent-bitcoins-to-the-wrong-address/)

also why would it be a good idea to use a centralized source of "entropy"....?
why is NIST involved at all?

~~~
petertodd
> also why would it be a good idea to use a centralized source of
> "entropy"....? why is NIST involved at all?

Actually there's a very good use-case for NIST's Random Beacon in
[OpenTimestamps]([https://opentimestamps.org/](https://opentimestamps.org/)):
preventing miners from backdating their blocks undetectably.

Background: The Bitcoin protocol constrains block timestamps to not be >2hrs
in the future, by virtue of the (kinda weak) rule that nodes reject forward
dated blocks. However, for a timestamp proof that rule is irrelevant: a
forward-dated block is a weaker proof, not a stronger proof. Unfortunately the
reverse is problematic: a Bitcoin block is valid so long as its timestamp is >
the median time of the last 11 blocks; nodes will happily accept backdated
blocks, with the only constraint on backdating being that you eventually push
the difficulty up.

Now, if you assume it's only a small percentage of miners doing this, the
median time past rule helps you a bit, but it's hard to model; if a majority
of miners are backdating blocks, there's a risk of backdated timestamps being
generated with significant (hours/days) of backdating. While that risk is
mostly theoretical because it's easily detected, it'd still be nice to rule it
out.

Since the NIST Random Beacon represents a nonce that NIST claims did _not_
exist in the past, we can easily use it to constrain and detect block
timestamp backdating, a useful improvement to the security of OpenTimestamps.
While not a priority, I'll probably add support for random beacons to
OpenTimestamps at some point, and have the calendars do this automatically as
part of the timestamping process.

Of course, I wouldn't do this with just NIST: all blockchains act as random
beacons, so it'd make sense to use a merkle tree of this NIST random beacon
and a few other blockchains at the same time to achieve this.

And finally, yes, you're quite right: using the random beacon as a source of
entropy is beyond stupid.

edit: Come to think of it, the simplest possible implementation of this would
be a cronjob that just grabbed the latest beacon and timestamped it... All you
need to achieve is proof that the block had a dependency on the beacon after
all.

edit2: ...and it's live:
[https://alice.btc.calendar.opentimestamps.org/experimental/i...](https://alice.btc.calendar.opentimestamps.org/experimental/inject/)

------
azinman2
“DO NOT USE BEACON GENERATED VALUES AS SECRET CRYPTOGRAPHIC KEYS.”

Can this at least be used to seed a CSPRNG at boot / device install, ideally
with a mix of other entropy available? Is the problem that they’re shared for
everyone at some given time?

~~~
kevinnk
You need a TLS connection to get the NIST beacon, which requires a seeded rng.
That seems like a chicken and egg problem.

~~~
londons_explore
As long as this data was signed by NIST, and we trusted NIST, there should be
no need for TLS.

~~~
inetknght
except that you would need to download the _entire_ random number sequence
blockchain history instead of, say, specific parts. Otherwise, the specific
parts you download would be known and therefore part of your randomness would
be known.

------
phkahler
A clock for transactions. Since this produces verifiable data every minute,
you can use that data as to sign any transaction and be able to verify that
the transaction did not occur prior to the publication. However you can not
verify that the signed data was not modified or even created after the
publication of the data. Any thoughts on how this concept can be useful then?

~~~
URSpider94
It's mostly not. The block chain is much better suited for this case, because
you can insert a hash of your data into a particular block and prove that you
were in possession of it at the time the block was mined.

------
masto
My hero, John Walker, built this thing in 1996:
[https://www.fourmilab.ch/hotbits/](https://www.fourmilab.ch/hotbits/)

------
grempe
At Tierion, we think the inclusion of the NIST Beacon in every Chainpoint 3.0
proof we generate is a powerful feature.

We announced that we had started including the Beacon in our new proofs at
Consensus in May. The first of its kind.

[https://tierion.com/blog/chainpoint-innovations-in-
blockchai...](https://tierion.com/blog/chainpoint-innovations-in-blockchain-
timestamp-proofs/)

Its also featured in our white paper if you'd like to read more about how
we're using it.

[https://tokensale.tierion.com/whitepaper](https://tokensale.tierion.com/whitepaper)

Tierion has been collaborating with the leader of the Random Beacon project at
NIST and we've been providing feedback on their new release, expected this
summer.

Every Chainpoint 3.0 proof has the most current available NIST timestamp and
its associated random value merged into the proof directly, allowing easy
manual audit and cross-check. This is in addition to server NTP time in the
form of a v1 UUID, which contains both a timestamp and randomness.

We also include the NIST Beacon in a new Calendar block every time it is
updated so our Calendar blocks can have enhanced temporal anchoring, even in
the absence of aggregated Merkle roots being anchored to the Calendar.

We've thought for a while that the NIST Beacon it pretty cool and we're glad
to see others coming around to the idea as well.

------
abrookewood
How susceptible would this be to government influence?

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.

~~~
dokument
How much would it matter if you used this as one source of entropy for your
rng?

~~~
URSpider94
The fact that it might be non-random is a much smaller concern than the fact
that it's known by the world. The whole point of seeding a RNG with entropy
(at least for cryprographic purposes) is to attempt to prevent someone else
from duplicating/predicting the state of the RNG.

~~~
abrookewood
Ahhh ... yeah, that makes total sense. So it would literally be the worst
thing you could do.

------
friendzis
If I read the announcement correctly, the hash is computed on the last value
and is distributed separately. Either I miss something or they can change ANY
value in the chain and the last hash would still check out.

It is only viable to use this while constantly querying /last. If
network/power/etc. outage lasts more than 60 secs, chains should be considered
separate.

Or maybe I'm missing something obvious

~~~
scrumper
I read "Each... value includes the hash of the previous value... chaining the
sequence of values together" which is how immutability is ensured. (Amending a
prior value would invalidate the hashes of every subsequent value.)

------
zeroflow
What would be the typical usecase for this beacon?

The first usecase I could think of would be a warning canary that signs the
data of the beacon akin to the plot in movies where someone holds up today's
newspaper.

The 2nd would as said on the page as kind of "nothing up my sleeves" random
number generator

~~~
21
Financial Times was already doing something like this years ago (still is?):

[https://upload.wikimedia.org/wikipedia/en/8/87/Root_of_Merkl...](https://upload.wikimedia.org/wikipedia/en/8/87/Root_of_Merkle_tree_as_published_in_Widely_Witnessed_Media.png)

------
0xabe
Compare to the Dice-O-Matic [0] just recently featured here.

[0]
[https://news.ycombinator.com/item?id=14806986](https://news.ycombinator.com/item?id=14806986)

------
johnhenry
Similar: [https://www.random.org/](https://www.random.org/)

------
wyldfire
Gambling seems like an interesting use case. Having a public seed and a public
algorithm would mean that results should be verifiable but not predictable.

I suppose it would be interesting to consider how latency of this public
resource represents a risk and how it could be mitigated.

~~~
sudhirj
One would assume that all bets would close X units of time before generation
time.

------
bstamour
For those interested, here's a Haskell interface to the Beacon I put together
some time ago [1].

[1] [https://github.com/bstamour/haskell-nist-
beacon](https://github.com/bstamour/haskell-nist-beacon)

------
tsujamin
I remember using ANU's one as the random source for a first year CS assignment
once haha

[https://qrng.anu.edu.au/](https://qrng.anu.edu.au/)

------
i_have_to_speak
Hmm, what if a government agency with warrant / hacker can force a specific
consumer of this service to be fed with known "random" values?

------
rini17
/dev/random seeding on bootup from NIST will be implemented in systemd in
3..2..1..

~~~
vesinisa
That would be a terrible idea. Seeding a (C)PRNG from a publicly known value
is one of the worst ways to shoot yourself in the foot.

~~~
zeveb
I'm pretty sure that's the joke.

------
TheDreamBotcher
I think NIST implemented the random beacon when they announced the WTC towers
report?

[https://www.youtube.com/watch?v=GvAv-114bwM](https://www.youtube.com/watch?v=GvAv-114bwM)

