Similar to centralized random beacons like the NIST[2] and Chile beacons.
1: https://eprint.iacr.org/2015/1015.pdf
2: https://csrc.nist.gov/projects/interoperable-randomness-beac...
(assuming you mean computers returning random numbers, and your people with dice is an analogy)
The problem with that is how do you trust the source if you need “cryptographically secret” random numbers. One of the sources could poison the well with bad entropy and increase by a small but significant amount the chance of guessing your keys.
OK, so you could the data from many sources, but that would add latency so not an option where performance matters and even then if someone gains control of a significant portion of the distributed system (just by standing up lots of hosts) the issue persists.
You could also do a bunch of statistical tests, but again that is work that will harm performance and if you are going to that sort of effort anyway you could setup your own random sources (a couple of active Linux boxes, on older Linux kernels running haveged, on newer ones the latter part isn't needed (https://github.com/jirka-h/haveged/issues/57)) and use those tests to make sure those sources are statically safe.
So such a service isn't really needed, and where it might be isn't likely to be trusted, so it could exist but as a play-thing not a serious service.
On my little home server, not a particularly up to date CPU etc, running 5.10, I can pull >3Gbit/sec from /dev/random. Heck, the Pi400 that is currently my router can hand out ~230Mbit/sec or entropy.
Well in the modern age this is solved by upvotes and reputation score.
>it could exist but as a play-thing not a serious service.
I wasn't being particularly serious, well I'm seriously surprised someone hasn't tried it, but I'm not investing my own hard money in the idea so...
The TL;DR is that:
- Everyone playing comes up with a random number X, which is kept local for now
- X is hashed, such that HASH(X) = Y, where Y is then sent to a server where everyone can view it (aka some blockchain smart contract). Some other stuff around preventing impersonators happens as well, but the hash being sent is the important bit. This is your commitment to the game.
- When everyone has submitted their Y values, they all send in their original X values as well
- Every X values is verified such that HASH(X) = Y.
- All the X values are combined, and used as a seed to an RNG (i.e. something like concatenation, run a KDF over the concatenation, use that output as a seed to an RNG)
- Now everyone knows which player run virtual coins, without a central decision point.
Is it from some rng generator or is it from nuclear decay of a Cesium atom?
This is what my product provides. Truly random (TM) numbers!
If I gave the number 1 that could be random or not. The fact that it's a 1 is unimportant. Only how it was derived.
I suppose it's like free range eggs in that respect. But free range eggs and mathematics don't seem to be natural bedfellows.
> LavaRand is a system that uses lava lamps as a secondary source of randomness for our production servers. A wall of lava lamps in the lobby of our San Francisco office provides an unpredictable input to a camera aimed at the wall. A video feed from the camera is fed into a CSPRNG, and that CSPRNG provides a stream of random values that can be used as an extra source of randomness by our production servers.
I could roll a die in return for $random crypto currency.
Obviously the amount could vary depending on the amount of randomness. So me thinking of a random number would get less than a die roll which would get less than this comment.