On Tue, Sep 29, 2015 at 8:00 PM, Taylan Ulrich Bayırlı/Kammer <xxxxxx@gmail.com> wrote:

xxxxxx@gmail.com (Taylan Ulrich "Bayırlı/Kammer") writes:

> I'll see that I add optional arguments to the R6RS hash functions to
> take a salt and bound.

Actually, it seems the typical salting strategy is to take a hash
function that has the salt built in, presumably seeded at program
start-up. This will work just fine with R6RS and draft 6 of SRFI-126.
Passing the salt to each call to the hash function seems excessive?

This was discussed on the 125 list, but I'll recap:

1. The explicit argument ensures security by default.

Otherwise it's up to every third-party hash function to

remember to use a global salt.

2. It's more consistent. Otherwise the default hash

functions and third-party hash functions all have

different ways to initialize the salt, making it impossible

to provide system-defined extensions such as

initializing a (single) global salt from env vars.

3. It makes it easier to unit-test the hash functions.

4. It's more secure.

a. It allows a separate salt per table.

b. It allows _changing_ the salt per table if any

given table has too many collisions.

5. It allows automatically extending any hash function

to become a set of hash functions by varying the salt.

In particular, this can be used for double hashing,

cuckoo hashing, and bloom filters.

Alex