Alex Shinn <xxxxxx@gmail.com> writes:

> 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.

Hmm, we have a problem of backwards compatibility there first of all.
If the salt argument is mandatory, we break R6RS compatibility.  If it's
optional, that makes the point mostly moot.

There's also the risk that programmers will be lazy and pass the hash
function the same salt every time, when they call them themselves, thus
doing more harm than good.

> 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.

I don't see the problem with an env var that affects both the built-in
hash functions and which users can obey in theirs?

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

That's a good point, but since it can be solved post-hoc by specifying
an env var to set the global salt/seed, and doesn't immediately affect
users of the library, I'd rather keep it out for the time being.

For now, unit-testing of the built-in hash functions is the duty of the
Scheme implementer, who can do it with any number of tricks depending on
the implementation, and unit-testing of user-defined hash functions is
no problem since they can use their own salt within the hash function.
They can also use 'make-hash-function' constructors that take a salt.

> 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.

A separate salt per table could be provided in the hash table
constructor, or hash function constructor, if really desired.

Re. b., are there any known implementations doing that?  It sounds like
an interesting idea, but I'd rather not complicate the API for a
use-case whose usefulness isn't demonstrated.

> 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.

This too should be covered by hash function constructors if I'm not
mistaken, which is a less intrusive change to the API and can be added
post-hoc if really desired.

On the grand scheme of things, while there are some good points, I don't
think they're convincing enough to warrant the proposed API change.

Taylan