7 ms·
NIST Randomness Beacon
- swordswinger12 13y agoOne possible application of this that NIST didn't discuss is mentioned in a new paper on accountable Bitcoin mixes: http://eprint.iacr.org/2014/077.pdf http://eprint.iacr.org/2014/077.pdf They use signed contracts combined with a novel mixing fee mechanism based on public randomness to ensure honest behavior by rational Bitcoin mixes. If you're interested in Bitcoin the full paper is worth a read.
- TempleOSV2 13y agoFucken nigger.
- dfc 13y agoThat does not fall under the Secure Multiparty Computation category?[^1] Or are you upset that they did not mention bitcoin mixes explicitly? [^1]: http://www.nist.gov/itl/csd/ct/beacon-secure-multi-party-computation.cfm http://www.nist.gov/itl/csd/ct/beacon-secure-multi-party-com...
- randomwalker 13y agoI'm one of the authors. It's interesting that you cite our paper as an application of the NIST beacon. Perhaps a better reason to cite our paper is that we actually design a beacon using the Bitcoin blockchain itself (Section 4.4), because the NIST beacon has many problems.
- dfc 13y agoBesides trusting NIST what are the other problem[s]?
- randomwalker 13y agoThe other major one is reliability (but that is encompassed by sufficiently broad interpretations of "trusting NIST.") Also, for our specific application it's not clear how to assign precise timestamps to Bitcoin blocks that everyone can agree on; this is necessary to be able to use a beacon that is external to the block chain.
- dfc 13y agoThanks for responding. I never thought about bitcoin+time problems. Are there any efforts/research into how to address the bitcoin+timestamp problem?
- swordswinger12 13y agoAhhh, I forgot about that part of the paper. I read it a few weeks ago, my apologies :)
- EthanHeilman 13y agoNIST random beacons can also be used to defend against selfish mining https://eprint.iacr.org/2014/007 https://eprint.iacr.org/2014/007 Selfish mining requires strategically withholding blocks, the NIST random beacon gives you unforgeable timestamps, thus during block races you can prefer blocks that have newer unforgeable timestamps. Those older withheld blocks will lose blockraces punishing selfish miners.
- nullc 13y ago> you unforgeable timestamps, Unforgeable except by anyone who's able to order or trick NIST into doing something. If NIST is unimpeachable, why not just have them run the anti-double-spending database and dispense with this inefficient blockchain stuff? :) > prefer blocks that that have newer unforgeable timestamps This general class of solutions often runs into problems with creating incentives for large miners to continue to mine at your current height and ignore a third party block, because you know you'll beat it in a race even though you announced late.
- EthanHeilman 13y ago>If NIST is unimpeachable, why not just have them run the anti-double-spending database and dispense with this inefficient blockchain stuff? :) Because even if NIST helps someone cheat, the cheaters only get a minor advantage and NIST runs a huge risk. Having an additional security measure which doesn't endanger the entire system if it is broken is not that same as trusting NIST. Furthermore you can also compose the NIST beacon with other random beacons so that they would all have to collude for any party to cheat. Imagine tomorrow, we find out a small (<33%) pool is selfish mining, what is a fix we can roll out in a few hours that will stop them while we examine longer term solutions (a long term solution might be asking every pool above 33% to provide a beacon and then having miners compose these beacons). >This general class of solutions often runs into problems with creating incentives for large miners to continue to mine at your current height and ignore a third party block, because you know you'll beat it in a race even though you announced late. Yes, we run into these problems at 33% of mining power. That being said, a 33% attack is better than the 0.5% attack.
- TempleOSV2 13y agoVersion:Version 1.0Frequency:60 secondsTime:03/24/2014 7:49 pm (1395715740)Seed Value:01A60DF95F925E67C7DE3ECF1AFF4A191605C4F0131D04A9DB2964B30C65D030 0AB4CB55CCF03BFAF1BC31FBB8ADD613CA87B7AEB21071737F0A4C7B0B2BEC2C Previous Output:BEE0F2FA687A234C5E7BFF753379AC23A78ED9C446C4390B792C48FE663CC46C 7E90ED602066A76DF4501059754F66C54E0817FE10C55AA915C8F0083B1932EB Signature:BA2748CD07E0121272A9DB60073314BB8CDE6AE1CDA318DF2DE644EEDA955EAC FBF114A6E43BDADBE428CFDF4925A165238065F464ADE8A795A377C63D2DBB83 37B26A14AEE30B5CC57031877EA797419DF53D4D060A6306ED3464F8FA5A8610 3C838546536AF2C16D276852AE81E31F5D2BE448C587DB85164436699D005257 DD2FC4FEFAE36D08E8213A5B5647F4A39FFD0BF085B2DA9EFD8C3070410BE581 2831E5FA92B25C6E8E8BE20D1A6B3F43C6708C2588C9FA39F3BE95B656A486C0 8D642C03C64E6F14C39BDC566DB3B267C55324F7764BD0467777607E7E240760 AFB42B7211BB9A408821B217078F13F4E4CE09D27756367073E1427813CF4751 Output Value:B14CFE698A353BC17D0BB3120090362E62CA24A4D4DF8C895F9D307F5B6DC3FD 198AC2AE196DA338F73E2E9F3AA16F2D1F1D46ABF2202D9FD9A10508AB0D2D27 Status:0: Normal -------- B14CFE-->11619582 Mod 100091 +1-->Line 9027 hanging at the court gate. 40:9 And thou shalt take the anointing oil, and anoint the tabernacle, and all that is therein, and shalt hallow it, and all the vessels thereof: and it shall be holy. 40:10 And thou shalt anoint the altar of the burnt offering, and all his vessels, and sanctify the altar: and it shall be an altar most holy. 40:11 And thou shalt anoint the laver and his foot, and sanctify it. 40:12 And thou shalt bring Aaron and his sons unto the door of the tabernacle of the congregation, and wash them with water. 40:13 And thou shalt put upon Aaron the holy garments, and anoint him, and sanctify him; that he may minister unto me in the priest's office. 40:14 And thou shalt bring his sons, and clothe them with coats: 40:15 And thou shalt anoint them, as thou didst anoint their father, that they may minister unto me in the priest's office: for their anointing shall surely be an everlasting priesthood throughout their generations.
- mpyne 13y agoVery neat, though it's a pity that the warning about crypto in the lower-right is so hard to notice. I mean, people weren't going to trust NIST on this anyways but if you're going to warn about crypto then it should probably be more prominent.
- dfc 13y agoThe dearth of documentation is also a pity.
- jauer 13y agoAt least the beacon interface/api page has a warning about not using it for crypto front and center in red underlined italics: https://beacon.nist.gov/home https://beacon.nist.gov/home
- jws 13y agoIf you have an engineer using publicly broadcast random numbers in your cryptography, the problem did not originate in the font size of the "Beware of the Leopard" sign.
- NAFV_P 13y ago$ Very neat, though it's a pity that the warning about crypto in the lower-right is so hard to notice. After reading your comment I had another peek... I think the background colour is inappropriate considering the surroundings, I had some trouble reading it well.
- midas007 13y agoWho in their right mind would trust anything NIST offers considering Dual DRBG EC? Best bet is to use many entropy sources including local hardware (ie sound card audio input) mixed in a fortuna entropy pool.
- dfc 13y agoThe metrology folks at NIST are top notch. I think they have been awarded four Nobels in physics in the last twenty years.
- Karunamon 13y agoUnfortunately, that attests greatly to their credentials and precisely nil to their trustworthiness. For all we know there are NSL gag orders in effect.
- dfc 13y agoI am not sure what you are talking about. Do you know what metrology is? If there is a NSL gag order in effect for the work recognized by the 2012 Physics Nobel how did the committee hear about the work? You think the scientific community just took Haroche and Wineland's word and never looked into their results?
- midas007 13y agoPlease, allow me to paraphrase 'pg: pedigree is for suckers. These data points have absolutely nothing to do with practical, trustworthy crypto standard processes or confidence in their ability to due-diligence systems.
- dfc 13y agoPlease allow me to paraphrase dfc, "confusing metrology with crypto is for suckers." To recap; you started this thread with "Who in their right mind would trust anything NIST offers." I responded by pointing out that there is a very talented group of people working on metrology at NIST and that some of these individuals have been awarded Nobels. What is the connection between trustworthy crypto standards and metrology?
- nknighthb 13y agoAhahahaha no. You can only "prove to anybody that [you] used truly random numbers not known before a certain point in time" if this supposed "anybody" trusts that NIST isn't just sending out pre-generated numbers.
- anigbrowl 13y agoYou probably shouldn't use it for crypto, but this would be a big help in scientific and industrial contexts where you can just point to NIST instead of having to come up with answers about the quality of your random data source. Say for example you want to showcase some algorithm that you say performs 10% better than chance (in some field where that confers a significant time/$ advantage), this gives you a meaningful benchmark to measure against. And since all the random data is stored, it makes certification of scientific papers much more repeatable since they can just show longs of when the NIST server was accessed in the materials & methods section of a paper. There are many applications of a good random beacon besides crypto.
- michaelmior 13y agoForget how random the numbers are if your source of randomness is literally being broadcast publicly, it doesn't matter.
- deleted 13y ago[deleted]
- sa1 13y agoIt is only not good for crypto, it remains good for other scientific applications.
- Sanddancer 13y agoThings like Monte Carlo simulations can, and have used public random numbers over the years -- the Rand Corporation's book of one million random digits [1] was used for this purpose. A public entropy source means that in verifying something, you can demonstrate that there was nothing up your sleeve when you used the points you did. [1] http://www.rand.org/pubs/monograph_reports/MR1418.html http://www.rand.org/pubs/monograph_reports/MR1418.html
- felipelalli 13y agoWhy they say "DO NOT USE BEACON GENERATED VALUES AS SECRET CRYPTOGRAPHIC KEYS"?
- josephagoss 13y agoBecause you can't know for certain that the values are random and thus it's a terrible idea to use them in cryptography.
- midas007 13y agoYes. Raw entropy values need to be first mixed in an entropy pool first in some way that's not easily predictable. Fortuna's entropy pool is a high-quality algorithm / system that happens to be part of a cryptographically secure psueorandom number generator (CSPRNG). The two can be seperated, just as AES-NI instructions have RdSeed and RdRand. ASCII: entropy sources -> entropy pool -> CSPRNG -> ...
- mpyne 13y agoBeyond the randomness thing (which you're right about, although NIST is claiming that they're actually random), the problem is that they're not secret. Given that you'd probably want to avoid using for any crypto use (not just secret parameters) unless you can be sure that using this randomness for a public parameter doesn't break the cryptosystem (or USG isn't in your threat model). Given that few of us are experts in cryptology it would seem like the safe thing to do is to avoid for crypto use at all.
- gojomo 13y agoAll the values are broadcast publicly; they're not secret.
- motters 13y agoWhy would anyone trust a public random source? It may be truly random, but it can also be completely recorded such that if anyone uses this as a random source and the timestamp is known then the encryption can be broken.
- midas007 13y agoIt's really nothing novel [0], there was the Lava Lamp RNG. [1] Except the generation source might be technically interesting, if you at all trust the overarching politics. [0] http://www.random.org/ http://www.random.org/ [1] http://web.archive.org/web/*/http://lavarand.sgi.com http://web.archive.org/web/*/http://lavarand.sgi.com
- Perseids 13y agoYou cannot use that randomness for private key or private data generation, true. But there are less common usage scenarios that need unpredictable randomness that is guaranteed to be generated only after a certain point in time. For two party protocols you can exchange nonces to prove that both parties are participating in this exact moment, but those don't scale to thousands of mutually distrustful parties. An example for that is the proposed Bitcoin protocol change that is already cited by swordswinger12 which prevents attackers from hoarding Bitcoin blocks.
- ef47d35620c1 13y agoMixing it into other sources of randomness could not hurt your crypto. Using it as the only source would be very bad.
- UweSchmidt 13y agoRegarding other RNG products they comment: "However, demonstrably unpredictable values are not possible to obtain in any classical physical context." What's wrong with any hardware RNG that produces 0's and 1's straight from physics, if these also pass the relevant statistical tests?
- hahainternet 13y agoPhysics is predictable
- UweSchmidt 13y agoTo clarify: What's wrong with any hardware RNG that produces 0's and 1's straight from observing natural phenomena like "thermal noise, the photoelectric effect, and other quantum phenomena", as wikipedia puts it[1]. How can they do better than that; specifically, what do they mean with "demonstrably unpredictable values"? [1] http://en.wikipedia.org/wiki/Hardware_random_number_generator http://en.wikipedia.org/wiki/Hardware_random_number_generato...
- sp332 13y agoFrom the quote you already posted: "in any classical physical context". They're not talking about anything quantum.
- UweSchmidt 13y agoGot it, thanks!
- Houshalter 13y agoWhat would happen if, just by random chance, the numbers ended up in a pattern that isn't "random". Like it returned 4 a thousand times in a row or something like that. What's the worse case scenario?
- efalcao 13y agocan anyone help me understand why the chain of signed/hashed values is important? Is it all about tampering?