hash functions should not be required to accept two arguments William D Clinger 09 Nov 2015 17:25 UTC
Re: hash functions should not be required to accept two arguments John Cowan 09 Nov 2015 22:35 UTC
Re: hash functions should not be required to accept two arguments Alex Shinn 10 Nov 2015 02:44 UTC
Re: hash functions should not be required to accept two arguments John Cowan 10 Nov 2015 05:43 UTC
Re: hash functions should not be required to accept two arguments William D Clinger 10 Nov 2015 12:02 UTC
Re: hash functions should not be required to accept two arguments taylanbayirli@xxxxxx 10 Nov 2015 13:00 UTC
Re: hash functions should not be required to accept two arguments John Cowan 10 Nov 2015 13:58 UTC
Re: hash functions should not be required to accept two arguments William D Clinger 10 Nov 2015 13:50 UTC
Re: hash functions should not be required to accept two arguments Alex Shinn 10 Nov 2015 14:15 UTC
Re: hash functions should not be required to accept two arguments taylanbayirli@xxxxxx 10 Nov 2015 14:26 UTC
Hash salt John Cowan 10 Nov 2015 06:37 UTC
Re: Hash salt taylanbayirli@xxxxxx 10 Nov 2015 10:00 UTC
Re: Hash salt John Cowan 11 Nov 2015 05:21 UTC
Re: Hash salt Shiro Kawai 11 Nov 2015 05:59 UTC
Re: Hash salt John Cowan 11 Nov 2015 06:22 UTC
Re: Hash salt taylanbayirli@xxxxxx 11 Nov 2015 07:54 UTC
Re: hash functions should not be required to accept two arguments taylanbayirli@xxxxxx 10 Nov 2015 09:58 UTC
Re: hash functions should not be required to accept two arguments John Cowan 11 Nov 2015 05:53 UTC

Re: Hash salt taylanbayirli@xxxxxx 10 Nov 2015 10:00 UTC

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

> William D Clinger scripsit:
>
>> There is no reason for clients or implementors of SRFI 126 to think
>> (h x 0) has anything to do with (h x 1), and so on.
>
> This reminds me that I'd like you to weigh in on the subject of
> hash-function clients being able to supply salt to hash functions to
> discourage DoS attacks based on the known behavior of standard hash
> functions.  The salt helps to populate the initial state of the hash
> algorithm, and is supplied by the framework on a per-process-instance
> basis, or more fine grainedly if desired (such as a per-hashtable basis).
>
> This salt could be supplied as yet another argument to the hash function,
> or by a parameter that the hash function is free to inspect but not to
> mutate (R7RS parameters can't be mutated anyway).  It would be an error
> to even inspect this parameter outside a hash function.
>
> Note that user-written hashes need access to the salt too, for we can
> often assume that the bad guy has the source of the program.

FWIW draft 9 of SRFI-126 will probably contain:

- `(hash-salt)` *procedure*

Returns a global and constant salt value for use in hash functions.
This is a random value for every run of the program, except when the
environment variable `SRFI_126_HASH_SEED` is set to a non-empty string
before program startup.

Taylan