League of Entropy aims to provide decentralized random number generation functionality with the goal of being able to use in scenarios such as Election Auditing, Lotteries, and Distributed Ledger Platforms etc.
As their website correctly mentions, everything from computer security and quantum mechanics to lottery number generation requires some form of randomness. Random numbers are core to the functioning of many complex systems and processes, including electoral auditing and cryptography. Using multiple independent and verifiable randomness sources is key to ensuring an unbiased and robust random number.
The League of Entropy is a consortium of organizations that are working together to produce a truly random beacon generating cryptographic random number every 60 seconds. These random numbers generated by the league are public, which means any one can get the list of all the recent random numbers generated till now. Since these numbers are cryptographically signed, they can be verified for their authenticity, so no question of tampering. And since this is a distributed generation of random numbers, no central authority can control the output either. Hence, true randomness.
With all those problems resolved, this looks like a great mechanism to start building distributed trustless applications on top of.
Except, one small problem.
The league of entropy has full control over the random number generation, but not on its application.
That is, there is nothing that prevents an application from tailing the list - that is, using an old random number from the published list which is always few minutes older than the latest. Since all the list of numbers is well-known publicly, the next number in the sequence is always known !!
The security of a random number generator comes not only from its randomness, but also from the timeliness. The random numbers generated from this league are valid for 60 seconds (currently).
For example, consider that a new random number is being generated at every 60th second (at the start of a minute, say 00 sec). Now, consider a client that queried for the latest random number at, say 59th sec. Immediately after few seconds, say 5 secs, if it makes the same query again, it will have another random number. The application now has two consecutive random numbers that are cryptographically valid till the next 55+ seconds. If you extend this scenario few seconds backwards, the application has a perfectly valid list of random numbers that are sequentially (and cryptographically) valid, and all that the application needs to do is create a sequence of (corrupt) blocks based on all those old random numbers, to drive the application / system into wrong (at least debatable) state. Given that there is no consensus on what is the latest random number, and given the delays in the network, it is perfectly normal to expect blocks with random number that are not latest (yet).
In other words, it is not enough for a random number generator to make the future unpredictable. It is also must for it to make the past undecidable. Alternatively, when the past is not undecidable (e.g. well known), then present must be consented.
Keywords: GK, Blockchain Consultant, Artificial Intelligence, IOT, Open Source, CarMusTy, CFugue, C/C++ Music Library, Carnatic Music, Song, Notation, MIDI, Typesetting, PDF, Books, Maya, Visual Effects, DirectX, OpenGL, Simulation, Predictive Analytics, Big Data, M2M Telematics, Predictive Maintenance, Condition-based Maintenance, Research, Cryptography, Distributed Ledger, Mentor, CTO for Hire, Consulting CTO for MVP Building, CTO for Startups, CTO as a Service, Virtual CTO, CTO Advisory Services.