Re: new PRNG's

[Roberto Ierusalimschy <roberto@...>]

> >Is it true ?
> >Lua 5.4 ?
> >
> >http://vigna.di.unimi.it/ftp/papers/ScrambledLinear.pdf

That is our plan.


> IMHO, math.random is similar in purpose to C standard library's
> random function. It's pseudo-random, that's about it. It does not
> promise any quality specifications.
> 
> Are there serious flaws that disqualifies the current implementation
> from this purpose?

Yes. First, it is not portable. The C standard library 'rand' is so bad
that POSIX has another one. Lua uses that other one in POSIX systems,
but not in other platforms. That is, in some non-POSIX platforms
math.random can be really bad. Second, it does not generate 64-bit
numbers, which is strange now that Lua has 64-bit integers as its "main"
numeric type. (It is also a little weird that random floats do not have
all bits random. Someone complained about that not so long ago on the
list.)


> Is there a requirement for cryptographic-quality randomness? Is that
> a good idea? For what applications? If for crypto/security, is it
> normal for a base programming language library to embrace such
> capabilities? Shouldn't we use well-established libraries instead?
> If we crunch crypto in pure Lua, wouldn't a timing attack be easy?

There is no requirement at all for cryptographic-quality randomness,
quite the opposite. We will not announce it as such and will not
argue about it. We chose that algorithm because it has a very simple
implementation and good statistical (from a "pseudo-randomness" point
of view) quality. It is hard to get much simpler than that:

static Rand64 nextrand (Rand64 *state) {
  Rand64 res = rotl(state[1] * 5, 7) * 9;
  Rand64 t = state[1] << 17;
  state[2] ^= state[0];
  state[3] ^= state[1];
  state[1] ^= state[2];
  state[0] ^= state[3];
  state[2] ^= t;
  state[3] = rotl(state[3], 45);
  return res;
}


> I just don't see the point of this topic going on and on and on.

We also don't see the point.

-- Roberto