2018-08-10 6:57 GMT+08:00 Faré <fahree@gmail.com>:

On Wed, Aug 8, 2018 at 2:33 AM Marc Feeley <feeley@iro.umontreal.ca> wrote:
>
> Add a feature request issue for this. Non-determinism is bad for debugging. And I view “production runs” as debugging because when something goes wrong in production once in a blue moon you need to debug that particular run.
>
If Gambit were to salt its hashes, the salt(s) and/or the random seed
used to compute the salt(s) ought to be setable by users early enough
(if needs be on the command-line).

Adam: can the salt be per-table (or per-type) or does it have to be
global? Can you do it in user-space?

As I understand it, the salt can be both per table and global. There is no reason that the user would not be allowed to specify the salt per table. If random u8vector may not be super fast, then maybe just copy the default per-table salt from a global variable that's generated once at startup.

Having salt randomization on by default would follow a "secure by default" reasoning - someone could use a hashtable in an exploitable place, and not be aware of the DDOS implications hashtables can have.

Of course as a user you can add hash salting on top of Gambit's hashtables yourself, by cons:ing on a random constant to all your table keys, or by implementing your own hashing function and telling Gambit to use it.

(Some more thoughts,

I see the point about determinism of software execution, however isn't the only effect of the randomization that table operations will have slightly different execution times which mean nondeterminism, aren't there some other common sources of nondeterminism around such as variance in OS thread execution speed or IO speed, that could complicate debugging already and even more than hashtable behavior -

Anyhow an optional salt works too. Hashtable DDOS security is really not a normally notable threat, it just occurred to me to bring it up for completeness, that was all. Yep should add a feature request.)