On Thu, Sep 10, 2015 at 12:46 PM, John Cowan <xxxxxx@mercury.ccil.org> wrote:

> R6RS hash-tables are similarly underspecified, but SRFI-69 does
> not have this problem because it uses an explicit `bound' argument.

You can't rely on that argument actually being the number of hash buckets,
though; it can just always be max-fixnum or something.

Yes, that's exactly the information we need. Without this, for

a general-purpose hash function you have to conservatively

produce results that would be bignums on 32-bit machines.

In practice I'd probably compute two 28-bit values, then mix

them at the end for speed.

> Another consideration is a "salt" argument to the hash functions
> to be mixed in with the result, which is one way to avoid the
> hash collision DoS attack. This would also effectively allow an
> arbitrary number of hash functions, which is useful for more
> than just cuckoo hashing (double hashing).

I think the framework is free to do this, since the hash code returned
by the hash function may be used in any way the framework wishes.

Salt added afterwards does nothing to prevent collision attacks,

since the attacker need only find multiple keys with the same

pre-salted value. It has to be mixed into the beginning of the hash.

Alex