 |
lua-l archive |
|
|
||
|
You shouldn't be using math.rand for anything nontrivial, not just
crypto. I started a thread a while back about replacing it with a
mersenne twister and only providing it in an extended library (which
somebody has written already apparently). For my personal usage, I
wrote bindings to C++'s <random>.
For example:
Let's say I'm using Lua as a texture sampler for some physically based
renderer. Believe it or not, there is a scale at which the variance
introduced by C's naive rand implementation introduces real visual
noise (bias they call it).
Alternatively, suppose I'm writing a data analysis plugin in Lua and
need to randomly sample some data. You can bet math.rand will be a
terrible choice that could affect real business cases in a nontrivial
manner.
There are other things to consider too. Like the periodicity. Imagine
you wrote a loot drop computation for some game in Lua using
math.rand. If you expect your server to be running for a long time,
your game RNG could be reverse engineered and subsequently gamed, and
for popular games, I would expect nothing less from a hardcore
community.
On Sat, Apr 5, 2014 at 2:13 AM, Coroutines <coroutines@gmail.com> wrote:
> On Sat, Apr 5, 2014 at 2:09 AM, Justin Cormack
> <justin@specialbusservice.com> wrote:
>>
>> On Sat, Apr 5, 2014 at 6:17 AM, Andrew Starks <andrew.starks@trms.com>
>> wrote:
>> > There is a difference between the rest of Lua's library functions and
>> > the
>> > ones found in math that is important. Other Lua library functions deal
>> > with
>> > what is coming in (strings), what is going out (io) or dealing with
>> > structures and types (to*, table). There are also some basic so
>> > functions,
>> > but all of them are either supporting the language or helping it to
>> > interact
>> > with its host environment.
>> >
>> > The math library is an application library. If you're using Lua to do
>> > math,
>> > it's nice to have it right there. But given the nature of implementing
>> > certain math functions and the limitations of C89, this can sometimes be
>> > limiting, so it's a limited library, at that. It attempts to provide
>> > people
>> > with what they would expect, but expectations are moving while ANSI C89
>> > is
>> > not.
>> >
>> > Is it better to have a limited (sometimes surprisingly so) math library
>> > or a
>> > more we'll rounded separate library? Or is it better to have an even
>> > more
>> > limited math library?
>>
>> Agreed. And the quality of it depends on your libc implementation,
>> which will vary, which is a big problem if you actually want to use it
>> for serious stuff. There is a big problem about test coverage, eg if
>> one platform has rounding issues in a maths function, Lua will differ
>> and might be incorrect, while a standalone library can have test cases
>> and be consistent.
>>
>> > If anything, I think math.rand should be removed, if it cannot
>> > reasonably be
>> > improved within the design limitations set for Lua. This function
>> > illustrates the point that I'm attempting to make, better than anything
>> > else
>> > I can point to.
>>
>> Definitely. Whether a better one should be provided (like LuaJIT does)
>> though?
>>
>> Justin
>>
>
> I would like to mention that I frequently use math.rand() for a great many
> things from fuzzing to replacing the background image on my blog with an
> unpredictable texture. I almost never use math.rand() to be
> cryptographically-secure, but I consider it very valuable for practical
> uses. I would not like to see it removed. :> *tosses hat*