Email list hosting service & mailing list manager

Proposal for passing bound and salt in a safe way John Cowan (16 Oct 2015 16:05 UTC)
Re: Proposal for passing bound and salt in a safe way taylanbayirli@xxxxxx (16 Oct 2015 17:26 UTC)
Re: Proposal for passing bound and salt in a safe way John Cowan (16 Oct 2015 17:34 UTC)
Re: Proposal for passing bound and salt in a safe way taylanbayirli@xxxxxx (16 Oct 2015 19:53 UTC)

Re: Proposal for passing bound and salt in a safe way taylanbayirli@xxxxxx 16 Oct 2015 19:53 UTC

John Cowan <xxxxxx@mercury.ccil.org> writes:

> Taylan Ulrich Bayırlı/Kammer scripsit:
>
>> Hmm, that's an interesting idea, but I'm not sure if it solves the
>> problem.  If I have existing hash function H which does not call
>> hash-salt, and now a hash table library tries to derive H2 from it by
>> wrapping it in a 'parameterize' for hash-salt, that won't work very
>> well, or will it?  It would be better for the library to call H with the
>> extra salt argument and cause a fast failure when H doesn't accept it.
>
> No, it won't.  The idea here is to preserve existing custom hash functions,
> and if you expose yourself to DoS in that context, that is your problem.

But the double-hashing implementation has no way to know that the given
hash function is unsuitable for double hashing (by calling it with
altered values of hash-salt), so how will it behave?

If my imagination serves right, it could apply a constant transform to
the result of the second hash function (which as far as I understand it
needs to do anyway to ensure non-zero values), which I suppose would
mean effectively degrading to linear probing.  Not sure if that's what
you intended or whether I'm totally off right now.  (I don't have any
experience implementing double-hashing and haven't spent that much time
reading about it either so apologies if I'm missing something obvious.)

Taylan