Since early evening on September 5th, 2013 the US National Institute of Standards and Technology (NIST) has been publishing a 512-bit, full-entropy random number every minute of every day. What’s more, each number is cryptographically signed so that you can easily verify that it was generated by the NIST. A date stamp is included in the process, so that you can tell when the random values were created. And finally, all of the values are linked to the previous value in a chain so that you can detect if any of the past numbers in the series have been altered after the next number is published. This is quite an extensive list of features for a list of random values, and we’ll get into the rationale, methods, and uses behind this scheme in the next section, so stick around.
But first, before those of you who’ve got crypto on the brain start thinking crazy thoughts, note that the NIST has a banner stating the obvious in all caps: “WARNING: DO NOT USE BEACON GENERATED VALUES AS SECRET CRYPTOGRAPHIC KEYS.” Why not? Cryptographically speaking, they’re phenomenal random numbers; they’re just not secret at all! In contrast, they’re publicly available to everyone and archived for all time. The aim of the Randomness Beacon is to provide a random number standard, not to generate secrets. This distinction between secrecy and randomness is important in order to realize what the NIST is up to, so put your secrecy on the shelf for now. We’re talking randomness here.
The Perfect Coin Flip
A random variable, says the statistician, is a function that produces a value that is unknown before a given point in time, but is constant thereafter. This instant when the value is realized is crucial to understanding randomness. 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.
Before you roll that twenty-sided die, any number from one to twenty could come up. After the die comes to a stop, it’s absolutely certain that you just rolled a seventeen, and that fact is never going to change. You just rolled a seventeen, and only a seventeen, with certainty and forevermore. The probability distribution has collapsed to a point, which is exactly why we roll dice or flip coins if you think about it. Keep these concepts of uncertainty and timing in your mind as I tell you a brief, entirely fictional, story.
My wife and I are going out to a restaurant, but we can’t decide whether to get Italian or Thai. For the past year, we’ve been deciding restaurants with a coin flip, but that hasn’t worked since she got suspicious and discovered that the “random” coin flip isn’t random at all, and that I’d been using a two-headed coin. She’s not going to accept a dice roll either, for the same reason that we don’t play craps together anymore. What we need is a perfect coin flip: some future random event with an outcome that’s currently totally unpredictable, impossible for either of us to influence, but then easily verifiable after the event so there’s no room for argument.
Note what’s going on here. If either of us knew what the future random value would be, it wouldn’t be random. But we require something even stronger, that we can’t even make useful predictions about the outcome — that the coin is a fair coin. And since she doesn’t trust me anymore, the only way we’re going to go out to dinner is if neither of us can possibly influence the future value. Burned by a year of eating Thai food, she’s not going to trust me to read the result out to her either, she’ll need to see the results herself.
This is exactly what is provided by the NIST Randomness Beacon. To pick a restaurant, we agree to look at the NIST’s webpage at 7:00 pm and if the first digit is even, we go Thai. If it’s odd, we go Italian. We both agree that this is fair because the 7:00 pm result isn’t published until 7:00 pm. As late as 6:59 pm, the outcome is entirely unknowable, and after 7:00 pm it’s publicly available to anyone and hashed and signed with the NIST Beacon’s secret key, so it’s easily verifiable. Because the Beacon’s Output Value is the product of a few hashing steps, 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.
While it’s overkill for picking restaurants, there are a lot of similar agreements that a publicly available source of randomness will facilitate. One similar example from the NIST’s website is that of random inspections. If a saboteur knew ahead of time which box of mangoes was going to be “randomly” inspected, he could fill it with contraband, and the whole shipment would get impounded. Or if a pharmaceutical company knew ahead of time which patients were going to receive the real drug and which the placebo, they could assign healthier patients to the test group. By using a neutral source of randomness, the saboteur is left guessing and the pharma firm can demonstrate that it didn’t cheat on its science. Or the Beacon could be used in an election in a scheme to randomly sample precincts and re-count votes, immune to influence from any political parties.
More esoterically, one could use the Randomness Beacon to prove that something is newer than a certain date by including a recent Beacon entry. As of this writing, the values for December 31, 2014 are all still up in the air, so I can’t possibly write one of them down yet. But from Jan 1, 2015 and on, it’s trivial to do so. So if I get a bunch of t-shirts made with the midnight value from December 31, it’s absolutely verifiable that I got them made in the new year. In short, you could use the Beacon as a not-older-than dating scheme.
How Does It Work?
So to see how the NIST pulls this off, let’s take a quick look behind the curtains at how the Randomness Beacon achieves its goals of providing a random string of bits that’s completely unpredictable, stupendously difficult to influence, and publicly verifiable. See Figure 1 for the overview.
It all begins, naturally, with the random number generators. Two independent hardware random number generators provide 512 bits of randomness, and these two values are XOR’ed together to yield the Seed Value. Taken on its own, this is an extremely good 512-bit random number.
The Seed Value is then collected together with the rest of the relevant descriptive data: version number, frequency of output, the time stamp, a code for the chaining status, and the value of the previous output. This collection ties the random outcome together with the time that it was created and links this value with the previous one. The collection of data is then hashed with SHA-512 and signed with the Beacon’s private key, yielding the Signature. Given the Beacon’s public key, one can easily verify that the signature corresponds to the relevant data and is signed by the Beacon. You can use the UNIX shell script at the bottom of this article to run a verification for you.
Finally, the signature is hashed with SHA-512 again to create the final Output Value. This is the value that you’ll want to use as your random number. It incorporates all the relevant information about this minute’s value because it’s a hash of the signature, which is in turn a hash of the data. All of this hashing preserves the original entropy from the Seed Value but additionally makes the Output Value depend on the Beacon’s secret key and all the relevant background data in a verifiable way.
Devil’s Advocacy
Now let’s say that you don’t trust the NIST. That’s OK, because by design you don’t need to. What you would care about, for the purpose of deciding on dinner, is that the value isn’t manipulable in a way that could affect whether we go out for Thai or Italian. If someone inside the NIST wants to change the Output Value by picking a particular Seed Value, there are two rounds of SHA-512 hashing standing between the Seed Value and the Output Value even if they know the Beacon’s secret key. 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.
If you want to make the outcome even more difficult to manipulate, you could use two values from the Beacon and XOR or hash them together to create the final random value. Because the outputs are chained, changing any value in the past introduces a changed Previous Output value which would have to be propagated forward to the current observation. 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 * 24 * 60 = 2,880 SHA-512 stages to make the chain verify, still assuming that he knows the NIST’s secret key.
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.
To put it another way: It’s virtually impossible to manipulate the Output Value, and even if your adversary could, they’d have to tailor a publicly-announced value to target you specifically. The cost of doing so would be astronomical, and the cost of altering the algorithm that you use to post-process the output value is trivial. When you start believing that a government standards organization has people on the inside who are doing the impossible in order to make you eat Thai food, it’s time to get back on your meds.
The one way that we can think of that the NIST could cheat in making the beacon is in the generation and timing of the random Seed Values themselves. Imagine that the Seed Values are generated randomly as stated but that they were generated a year ago instead of just a few seconds ago. Insiders at the NIST could then know the values ahead of their publication date, and even if they are not able to influence the values, they could possibly profit from knowing what decisions other parties are going to take in the future. One could even structure the agreement to take advantage of a known future outcome. Say using the value at 7:01 pm for our dinner selection instead of 7:00 pm.
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. But it is the one hole in the system that we can think of, and if the outcomes of the Beacon end up moving stock markets, for instance, the incentive to cheat will be there.
Anyway, if nothing less than twelve layers of tinfoil will suffice for your hat, some researchers at NIST suggested that other organizations should also run their own Beacons so that users can combine outputs from institutionally different sources of entropy. One can imagine a future world where there are multiple beacon sources available to choose from. As long as you trust that the conspiracy doesn’t extend to the NIST and your other source, you can be sure that you’re getting non-manipulable values. Problem solved.
A Bell Test
This leaves us with the issue of true randomness. Sure, the values that come out of the hardware RNGs look random, but is there maybe some underlying deterministic physical rule that we could discover to predict the future evolution of the system? Our guess is no, but wouldn’t it be cool if you could issue a guarantee that the hardware generates actual randomness?
Two entangled photons are generated and sent off in opposite directions. Measurements are chosen and made on each photon in locations that are far enough away from each other that there is not enough time for light from one measuring station to reach the other until after both measurements are finalized. This means that there’s no way that the result of one measurement could affect the other, and high correlation between the two measurements demonstrates that (random) quantum mechanics is deciding the outcome rather than normal deterministic physics. And as a bonus, the final outcome couldn’t possibly be known until the time that it takes light to reach one measurement station from the other. We have a guarantee of randomness and an earliest-knowable time in one apparatus.
A really solid test of the Bell Inequality and photon entanglement is interesting from a fundamental physics perspective, but it’s also a source of physically undeniable random numbers. It’s also ridiculously difficult to construct such an apparatus, but they’re working on it. The NIST plans to plug the output from the Bell experiment into the Randomness Beacon described above and then make the results available to everyone. You said you wanted random numbers, right?
Conclusion
So in short, the NIST Randomness Beacon is designed to be the perfect coin flip. It’s a public source of random values that’s totally unpredictable, but also ex-post verifiable and extremely difficult to manipulate. They’ve been running the service for over a year now in public beta, and we think it’s time that folks started thinking up interesting new applications. You’re invited to post up your new ideas, conspiracy theories, or anything else related to public random numbers in the comments below.
And before we leave the subject of random numbers, we can’t help recommending looking at Hackaday’s own One-Time Pad pictured earlier in the post (0x0f 0x000 NUEM FAEUD POMEZRH BNRBRG) or RAND’s 1955 page-turner “A Million Random Digits with 100,000 Normal Deviates“, two other sources of Grade A random numbers. Just don’t use these resources, or the NIST Randomness Beacon values, to encrypt any important secret data. Because they’re not secret.
I’d also like to thank the folks at NIST who helped with numerous clarifications and ideas for this article. Thanks in particular to [Rene Peralta] and [John Kelsey] for interesting usage ideas. [Lawrence Bassham] explained the entire Beacon procedure in great detail, and provided the code that makes verification of the chaining and signatures a breeze. Any mistakes or misapprehensions that remain, despite their help, are mine.
Appendix: Beacon Test Code
## NIST Randomness Beacon verification routine
## Only slightly adapted by Elliot Williams
## from code provided by Lawrence Bassham, NIST
## The UNIX time that you'd like to test:
##
whichRecord=1400878200
## --------------- Utility Functions ----------------
## Extracts specified record from xml file
getValue() {
xmllint --xpath "/record/$1/text()" $2
}
## Converts little-endian to big-endian
byteReverse() {
len=${#1}
for((i=${len}-2; i>=0; i=i-2)) do
rev="$rev${1:$i:2}"
done
echo ${rev}
}
## ---------------- Get an arbitrary record -----------------
echo "Downloading data for: ${whichRecord}"
curl -s https://beacon.nist.gov/rest/record/${whichRecord} -o rec.xml
## ------------- Pack data into correct format --------------
echo
echo "## Create a summary of all of the data, save as beacon.bin"
## Strangest choice of format ever!
## Version number (ascii text)
## Update frequency (4 bytes)
## Time Stamp (8 bytes)
## The HW RNG seedValue (64 bytes)
## The previous output value, does the chaining (64 bytes)
## Status code (4 bytes)
getValue version rec.xml > beacon.bin
printf "%.8x" `getValue frequency rec.xml` | xxd -r -p >> beacon.bin
printf "%.16x" `getValue timeStamp rec.xml` | xxd -r -p >> beacon.bin
getValue seedValue rec.xml | xxd -r -p >> beacon.bin
getValue previousOutputValue rec.xml | xxd -r -p >> beacon.bin
printf "%.8x" `getValue statusCode rec.xml` | xxd -r -p >> beacon.bin
## ------------------ Verify signature on data --------------------
echo "## Verify that the signature and NIST's public key correctly SHA512 sign the data"
## Download Beacon's public key
echo "Downloading Beacon's public key"
curl -s https://beacon.nist.gov/certificate/beacon.cer -o beacon.cer
## Create a bytewise reversed version of the listed signature
## This is necessary b/c Beacon signs with Microsoft CryptoAPI which outputs
## the signature as little-endian instead of big-endian like many other tools
## This may change (personal communication) in a future revision of the Beacon
signature=`getValue signatureValue rec.xml`
byteReverse ${signature} | xxd -r -p > beacon.sig
## Pull public key out of certificate
/usr/bin/openssl x509 -pubkey -noout -in beacon.cer > beaconpubkey.pem
## Test signature / key on packed data
/usr/bin/openssl dgst -sha512 -verify beaconpubkey.pem -signature beacon.sig beacon.bin
echo
echo
## ------------------ Verify Signature -> Output and Chaining ------------
echo "The following three values should match: "
echo " a direct SHA512 of the extracted signature"
echo " the reported output value"
echo " next record's previous output value"
echo
## Just print output value
echo "Reported output value"
getValue outputValue rec.xml
echo
## Now turn the signature into the output value: again SHA512
echo "SHA512 of the signature"
getValue signatureValue rec.xml | xxd -r -p | sha512sum
## Now test chaining
## Get next record
echo "Downloading the next record"
curl -s https://beacon.nist.gov/rest/record/next/${whichRecord} -o next.xml
## Make sure that this period's output shows up as next period's "previous output"
echo "Next value's reported previous output (test of forward chaining)"
getValue previousOutputValue next.xml
echo
echo
## --------------------- The End -----------------------------------------
## If this all worked, we've verified that the signature (plus NIST's key)
## sign the hash of the random number and its support info
## _and_ we've verified that the outputValue is derived from them,
## so we know that this output value is in the chain.
## If we run this on every entry in the chain, and all works out just fine,
## then we'd know all is well
This reminds me of “what the bleep do we know.” If everyone in the world focuses on the same thing then random number generators become less random. What if everyone focuses on the same random number generator? Will this make the output become…. should I dare say….. less random??? https://www.youtube.com/watch?v=9QcKDvcnZrE
No, they will not become less random.
If we both stand side by side, with identical coins in our hands, throw them and record the result, we are both using the same method, focused on the same thing, and will get different outcomes.
Or at least it’s the theory. There’s a very small but existing chance that we throw the coins ten billion times, and get exactly the same result every single time.
I guess you don’t get it then.
I think he does get it; or if he doesn’t, then I don’t either. The title of that video is, “Quantum entanglement and the Power of Intention”. In other words, if I think it, I can make it happen, but not with my hands or other efforts. As one of the YouTube comments said, “entanglement is amazin but i think this video is exaggerating a lil bit”.
That’s so much new-age woo I almost fell out of my chair…
That sounds like a testable hypothesis. Go for it! I’ll be waiting with bated breath.
No because psychic abilities aren’t real.
I knew you’d say that.
http://www.random.org has been providing provably random numbers to the Internet since 1998.
Totally different service, but yeah, I could have name-checked them in the article. But if I did, I’d have to mention Lavarand (which doesn’t seem to exist anymore, shedding a small tear) too.
With NIST, it’s not just about the randomness, but also the public-ness and the audit trail. They’re making non-secret random numbers, which are totally different critters.
The insider at NIST can apply the algorithm 100 times to generate 100 new numbers for a single minute, then choose to publish one that corresponds to Thai food. No reversing of hashes needed.
That’s right. The more bits of info you’d like to influence in the outputValue, the more trials you’ll have to run in your brute-forcing attempt. So for the restaurant choice (one bit), it’s trivial.
But for something more realistic like the random recounting of some precints’ votes in an election, you’ve got a lot more bits that you’d like to influence, and that means exponentially more tries in your brute-forcing. And you’ve only got a minute to do it. (Unless you think that they’ve pre-run all the seeds, in which case they buy some more time.)
Anyway, the good news is that the resource is public, and while they’re spending all that time and effort to make me eat Thai food, the numbers coming out are as good as random for everyone else using the service.
It’s correct that targeting more bits will become more difficult. However even attacking 50 bits should be possible quite easily.
As an additional comment I would like to note that even if you try to use all 512 bits to create your binary value it doesn’t get harder for the attacker. Within only 10 tries he has a 99.9% change of getting at least of value with the desired outcome.
And in the case of the vote, it’s not even necessary to get one correct seed – there are a huge number of permutations of voters that result in the same outcome if you want to sway the count in favor of one candidate.
Shit, the insider at NIST could just substitute any desired 512 bit sequence desired for one or more outputs and no one would be the wiser. We really only have NIST’s word that the RNG source is as they describe.
Of course, NIST doesn’t have any visible motivation to cheat at this. But if it were to become public knowledge that this beacon were used for something of value – say, a state or regional lottery used it directly to generate draws – then that might change. And that fact alone reduces the value of this service to merely an academic curiosity.
This article is almost a documentary, very interesting, thank you!
I do believe it went too far.
The Initial question was Thai or Italian…
One of my favorite questions, that.
modern day number station ?
It just seems so inhuman without a machine reading them out. That being said I know exactly what project I’ll be making next to use these numbers. 512 bit, 155 decimal digits, just over 75 double digit numbers read out loud per minute? Seems a little fast but we could make it work.
That’s a great idea. Instant numbers station for your Linux box (reads the hex digits out loud):
curl -s https://beacon.nist.gov/rest/record/last |
sed -re ‘s#.*(.*).*#\1#’ |
tee /dev/stderr |
sed -re ‘
s/(.)/\1, /g;
s/9/niner/g;
s/A/alpha/g;
s/B/bravo/g;
s/C/charlie/g;
s/D/delta/g;
s/E/echo/g;
s/F/foxtrot/g’ |
espeak -s 240
(Just fix any fancy-formatted quotes to be normal quotes)
http://pastebin.com/ktPqeuQ3
Fun! For OS X, replace the “-re” with “-E” on the sed lines, and change the last line to “say”.
Very cute, Nerd65536! Great choice of user ID too. Can I have a PowerShell version for Windows 7, please?
;)
I’m working on a .NET v4.5 version using Bouncy Castle’s crypto library. I should be able to compile it into a CommandLet or rewrite the script using the imported Bouncy Castle DLL. Stay tuned… I’ll have it up in GitHub hopefully by this weekend. I need to work out the REST interface first. I can verify hand-jammed entries, but not from the web, yet…
Given your cheating, I would simply demand Italian with no more randomness for you.
Great article, long for a HAD post but I enjoyed it.
In your quest for Thai / against Italian, you mention neither party knowing the outcome beforehand and also the part about getting the value printed on a tshirt to prove no-older-than. Surely NIST could precalculate a year’s worth of hashes and sell them? Publishing the pre-calculated ones on-the-minute instead of calculating new ones. Assuming you don’t need a specific value and just need to know the outcome before hand?
I think I understand what you’re saying, but tell me if I’m wrong.
The block diagram shows that the starting point of this whole exercise comes from the hardware random number generators, labeled “HW RNG 1” and “HW RNG 2”. The unpredictability of the whole system is dependent on the unpredictability of those hardware random number generators. If an evil insider at NIST ran his own good quality hardware random number generator in his own basement to generate a year’s worth of statistically random numbers, and if he then modified those “HW RNG” boxes so that they would no longer generate random numbers on the fly, but instead they would replay the stream of numbers which he had generated in his basement, then yes, that evil insider could know in advance what the output stream was going to be. He’d only have to duplicate the rest of the stuff in that block diagram, including the NIST private key. If we were restricted to looking at the output, we’d have no way of detecting that kind of scheme, because the output would be fully random, just known by an insider before it was known publicly.
We have to trust that the folks at NIST have audited their hardware well enough, by enough independent observers, so that we have confidence those hardware RNGs are indeed producing a stream of numbers that is not known by anyone in advance. Another layer of protection might happen if NIST made sure that any individuals with access to the RNG hardware didn’t also have access to the NIST private key.
Yeah thats the angle I was going for! Assuming someone pays off the people with access to the key and the HRNG machine, they can know the outcome before its published.
Though I guess if you combine the output from many different organisations around the world creating these kind of numbers you could make it much harder for someone to pay them all off.
There are 512 bits per minute. If you made 2^512 shirts you could grab the right one at the right minute, but if your shirt shows 24hr*60m worth of 512 bit messages, there’s high confidence the shirt is ‘no older than’. Plus, the shirt could show the whole digest; NIST Pub Key YYY-MM-DD-hh-mm value all wrapped up
Throw something time-based and verifiable like the precise temperature at some location as reported by another organization every minute. Since each new hash is partially a product of the others, the only way to perfectly predict the outcomes for a year would to be precisely predict the temperature for that location every minute from now until this time next year.
For those who don’t feel like doing the math, that is a LOT of points to get right: http://www.youtube.com/watch?v=-r2xXtSsPV0
Or make “Random Cookies”. Break one open to find your random number!
D20 cookies! D & D game with a snack for every move!
I feel as though I must be missing an important point. Couldn’t the insider at NIST just switcheroo the generated output with his own before publication?
The insider has 60 seconds to chain last minute’s output in the hashing process, along with some seed. Supposing he has total control over the random seed, he has very few seconds to test many seeds for the desired output. Then he has to supply that seed and block normal operation. So, to accomplish this attack once requires a hostile takeover of wherever the HWRNGs are and a supercomputer and luck. And no one noticing.
Sounds like the plot of the next Die Hard movie.
Ocean’s Random. (Instead of Ocean’s 11 or 13 or whatever they’re up to now)
I remember when the NIST was pushing ecliptic cryptology algorithms for equations that the NSA had already solved. This smells like another NSA man in the middle attack to me.
I`d rather use a Commodore SID chip that trust NIST again.
These are random numbers and should not be used to obscure information. NIST expressly say so on their web page for the random numbers. If you manipulated these numbers for a man in the middle attack, it would more aptly be named “man, like, everywhere” attack.
To reiterate the well written article above. These are random numbers not secret numbers. There is such a thing as random secret numbers that can be used in cryptography but that is not the purpose for these numbers.
If you want to understand this better, read the article again.
Nay, it’s all about trust.
I trust my own random numbers: If they were genuinely important to me to be genuinely random, I’ll take entropy from the local RF spectrum, random bits from random Youtube videos, whitenoise on the FM dial, and combine that with a transducer that listens to the floor as my housemates stomp around during their daily deeds. And if that’s not good enough, I’ll throw a single-pixel CCD-based camera that stares at the busy intersection outside the front window of the house, and AGC it (with the AGC itself tempered by the Nasdaq average) so the levels are sane but based on values that only I know, and use that also.
A NIST-generated “random” number, on the other hand: Jesus, everyone has this same random number. So no matter how random it is, everyone else has it as well.
I don’t trust the Government’s random numbers. That I already trust their DES and AES, variably, is already quite bad enough – thanks.
(And I -like- NIST.)
what an (extremely unexpectedly) well written article.
usually hackaday articles are all derp’d out
I’ve noticed the long-form posts explaining things are usually better edited than the short ones about projects. Probably because they spend more time writing them, and/or collaborate on them.
Nice article – much much better than most of the recent stuff.
Only the shell script is broken, since every ” was converted to " every < to < … etc. maybe let's try not to use htmlspecialchars on it. :(
Is there any guarantee of uniform randomness across a subsection of the entire random number, and across the field of possible values? For instance, I could roll a die and pre-pend the result with 1 and generate lots of random numbers between 11 and 16. But if my wife and I only look at the first digit, we’re going to be eating a lot of Italian food. Can it be proven that an SHA-512 hashing preserves the distribution of randomness?
I just don’t see the utility of publishing random numbers in this manner, since these would be the first things to permutate when brute-forcing… in whole or part.
“WARNING: DO NOT USE BEACON GENERATED VALUES AS SECRET CRYPTOGRAPHIC KEYS.”
That’s a direct quote from the NIST page, and the second paragraph of the article that you apparently didn’t read (capital letters in original). In other words, DO NOT USE THESE NUMBERS FOR ANY SECURITY PURPOSE FOR EXACTLY THAT REASON.
Why not add a public information that can not be known in the past to the system. For example news headlines from around the world or twitter trending etc pp… with this information that would be difficult to manipulate and it would made it impossible to pre calculate values.
Aggregate value of the last closing day stock price.
NIST, the institution that cooperates with the NSA to sabotage crypto standards. Yeah, I would trust them.
you read my mind, would not trust anything like this.
The beacon test code has HTML characters in it. I’ve fixed it (and added the appropriate shebang) here: http://ecosimulation.com/beaconTester.sh
To use:
1. Download the script
2. chmod +x beaconTester.sh
3. ./beaconTester.sh
(or just sh beaconTester.sh if you don’t want to chmod it).
I’m getting “Syntax error: Bad for loop variable” on line 21.
three seconds of height at about two feet at the peak with a flip after catch on the bottom. same result ever time.
I don’t see how the “not older than” example works. If I publish a Web page and put the tracking beacon from this instant on it, that shows the Web page was created “now” and no later. But I can write a script to always publish the instantaneous beacon so the Web page would always be no newer than now. And in reality a Web page can not be created any moment after now until now happens… So I don’t need a beacon that tells me a Web page is published no later than now because that’s impossible.
Furthermore I can reach back to any point in history and publish that beacon signature. So I can show the Web site being created at any point in time. No newer or older than any point in time I choose with the exception of before the beacon service was created or after it shuts down. Which is a moot point.
At best I think you could only say a Web page has not been created before NIST started publishing random numbers.
But I think that goes back to my moot point issue because you could just chalk that up to a website not using the beacon and you wouldn’t know when it was created.
That’s because the website is stored on your server and you can do whatever you want with it. With the example of the t-shirt, you have the manufacturer selling shirts and people buying them who would have to learn how to alter shirts in order to buy one ahead of time and change it once the new year arrives. A basic marketing gimmick.
Also, it would let time travelers prove they’re from the future, presuming the random function is unlikely to be affected by actions a time traveler would perform..
This is the first time, in YEARS, that I read a good HAD article. Thank you, Elliot, for restoring my faith in HAD.
I keep thinking of the Tom Stoppard play “rosencrantz and guildenstern are dead” https://www.youtube.com/watch?v=NbInZ5oJ0bc
Does anyone have a byte representation of what the beacon.bin file mentioned in the sample script is supposed to look like? I’m not familiar with that language, and I’m trying to piece together a bit of .NET 4.5 code using the Legion of the Bouncy Castle crypto library to read the certificate from NIST and do the SHA-256withRSA signature verification, but I need to know the input of the data to the signature verification object to verify it against the supplied signature. It looks like the order for the properties being smashed together is the Version, Frequency, Time Stamp, Seed, Previous Output, and the Status Code, but the format is completely throwing me. Any help would be appreciated! Thanks
There are little / big endian differences between the Win32 crypto, .Net & the native cert file. Try changing just the endian of just the signature.
I’ve tried flipping around the endianness of the integers (frequency, timestamp, status code), and the signature, and combinations of both. There’s something about the formatting that either I still have wrong, or they are incorrectly signed, but I don’t have proof of either at the moment, so I have to assume (benefit of the doubt to NIST) that my formatting is wrong during the verification process. If someone has the script above running correctly and it shows that the signature is correct/verified, then could they post the hex dump of their “binary.bin” file to GIST or PasteBin or something like that for me to see what I’m getting wrong?
https://github.com/emailgregn/nist/blob/master/nist1/nistrecord.py
Is that Python 2x or 3x? I’ll give it a shot and see what it produces, thanks :) I see there are example BIN files in the repository as well, that will help me tremendously!
Found my issue… I was using an SHA256 digest in the Org.BouncyCastle.Crypto.Signers.RsaDigestSigner object creation method, I should have been using an SHA512 digest. Once I changed that and made my internal data array match the one provided by emailgregn (see comment reply below), I was able to verify the signature. So now for the REST interface, and a weekend to crawl all the values in the chain (using some throttling so as not to spam their servers or get IP banned of course). GitHub to follow, and a PowerShell script perhaps per a request made in the comments above.
C# Code for pulling/verifying the beacons:
https://github.com/SparkDustJoe/Random/tree/master/NISTRandomnessBeacon
Some Java code here (https://github.com/sorokod/NIST-Randomness-Beacon-Validator) that uses Bouncy Castle crypto
I didn’t see this until just now, but thanks, I’m sure others will find it useful :) That makes, so far, Linux shell, C#, Python, and now Java :)
Why reinvent the wheel? For random numbers, use a future block hash from the block chain any of the large and established cryptographic currencies, like Bitcoin, Litecoin or Dogecoin.
After it was revealed that the NSA deliberately messed with the randomness of encryption standards to easily break them I can’t see how one can trust NIST.
These numbers are public, so anybody would be stupid to use them as secret keys. Therefore there’s no incentive for NSA to mess with them.
What about adding data like this for weather forecasts. 1)Historical data available 2)Independent but nationally recognized body 3)Nice easy string to hash and produce an output 4)LARGE source of potential stations allowing for round-robin or deterministic-chosen-set of stations to prevent predictability 5)Data source available to very wide audience for a variety of purposes
http://aviationweather.gov/adds/metars/?station_ids=KBWI&std_trans=standard&chk_metars=on&hoursStr=past+36+hours&chk_tafs=on&submitmet=Submit EXAMPLE, BWI Airport in Maryland for past 36 hours
KBWI 202154Z 03005KT 10SM SCT060 BKN090 BKN150 06/M03 A2993 RMK AO2 SLP138 T00611028
KBWI 202054Z 00000KT 10SM SCT070 BKN100 BKN150 07/M02 A2994 RMK AO2 SLP139 VIRGA SW-NW T00671022 53009
KBWI 201954Z 04004KT 9SM SCT100 BKN120 BKN150 07/M02 A2991 RMK AO2 SLP130 VIRGA W-NE T00721022 … (etc.)
Publicly verifiable random numbers reminded me of something mentioned in Jon Peterson’s Playing At The World. When you’re playing a war game via post in the 1960s, what do you use for random number generation? The number of shares traded on the stock exchange on a future date.
I have seen this in Karen State (Burma) a few years ago. A group of dodgy men in a decrepit teahouse where watching TV showing children’s cartoons. Our guide pointed out the ticker tape with stock prices from the Bangkok exchange running along the bottom of the screen – the men where waiting for the closing bell and the last digit of the day’s trade
I had to modify the shell code to work on macOS and fix the bad quoting issues. Here is a gist for anyone who wants the updated version (and the fun little numbers station example as well).
https://gist.github.com/grempe/c8daecf169ec7d06adb0089f0530aede