Re: what is the role of the `seed` field in the Lua global state?

[Philippe Verdy <verdyp@...>]

The fact that this field is initialized once and then never changes is
still the security issue. Programs can run over very long periods of
time.
This field however may be reset each time for generating newer sets of
hashes, and its initialization may come from reading from a global
store which could be fed asynchronously (at randomized periods or with
an adminsitrative manual order) with some antropic sources (which
would be implementation dependant and unknown from the attackers
because these sources would not be exposed directly).
Not all hashes have to be equal for the same value; they have to be
consistent only for the set of data hashed in the same index. Nothing
prevents also reindexing a table at any time using a new hashing
function (or the same hashing function but with a new seed generated
from the antropic source; reindexing tables by rehashing its content
is sometimes desirable as a maintenance tool, notably if the
cardinatity of sets has changed significantly, or because there's a
need to compact the size of indexes to save memory used by stable
data, or to increase it to avoid too frequent reallocations with
unstable data).

Le mar. 10 mars 2020 à 23:24, Norman Ramsey <nr@cs.tufts.edu> a écrit :
>
> I've been poking at the implementation of Lua, and I've noticed that
> in Lua 5.2, Lua's global state acquired a `seed` field.  This field
> is initialized at startup and never changes, and as far as I can
> tell, it affects only the hash values of strings.
>
> What does this seed accomplish?  What problem does it solve?
>
>
> Norman
>