 |
lua-l archive |
|
|
||
|
On 5/7/2018 5:00 AM, Roberto Ierusalimschy wrote:
By "the current implementation" below I meant what was presented in the ongoing discussion. Poor writing/editing that.Are there serious flaws that disqualifies the current implementation>from this purpose?If I understood your last message correctly, you are asking why to change from xorshift128plus to xoshiro256**. xorshift128plus does not have any serious (or non-serious) flaws for our purpose, despite what some pundits may say. Nevertheless, some pundits will complain about xorshift128plus (they already did), which generates noise (e.g., "avoid the lower bits"). The implementation of xoshiro256** is basically as simple as xorshift128plus, and avoids the noise.
Yes, that is more or less correct. I was too brief.By math.random's intent, any number of good PRNGs should qualify. But if some new paper pops up from security researchers detailing a flaw or weakness in one of the PRNGs being discussed, then it ought to be brought to attention by the community.
Absent such flaws, one or more PRNGs qualifies, and one would presumably be chosen at the pleasure of Team Lua. A focus on the output quality in terms of crypto randomness tests may extend too far into quality concerns that is not specified by math.random. A pursuit of the 'bestest' implementation by the community here is laudable, but it seems a little like a pursuit of perfection that can be grasped only fleetingly.
What is the perfect choice for today may change in the future. Security research will progress and a few years down the line, who knows what may turn up. Weak keys, exploits, better algos, etc.
(Many things that need really high-quality random numbers may not need PRNGs that much these days. E.g. about all IoT chips with crypto hardware will feature a true random number generator.)
-- Cheers, Kein-Hong Man (esq.) Selangor, Malaysia