On Sun, Sep 13, 2015 at 7:16 AM, John Cowan <xxxxxx@mercury.ccil.org> wrote:
Alex Shinn scripsit:

> This is minor compared to the fact that the hash functions don't
> take salt as an input.  Hash collision attacks are well understood
> and have been fixed in Perl [1], and care was taken to fix this in
> Chicken's internal hash tables as well [2].  It seems irresponsible
> to design an API that prevents such security precautions.

A possibility would be to have a parameter hash-salt made available
to the hash functions.

A user-controllable parameter sounds like a good way to
break hash-tables.

The implementation-provided functions could use a salt
which is fixed at either system startup time or per table.

User-written hash functions could use their own salt, which
would have to be fixed at system startup time.  So if both
the core and third-party hash functions were conscientious
about this they could make it difficult to force collisions.

However providing the salt directly in the API has several
advantages:

  1. we encourage and make security the easy default
  2. we use a consistent API for all hash functions
  3. we make unit testing possible
  4. we provide stronger security by making per-table salt possible
      (possibly even dynamically regenerated after too many collisions)
  5. we make various hash-table strategies using 2 or more hashes possible

Adding this parameter seems clearly superior to me, and
in the trivial case the API is still easy to implement on top
of SRFI 69 or R6RS (simple wrappers would just discard
the salt).

The only question is whether we should also include
a bound, and if so how it should work:

  1. a specific bound which may actually be the # of buckets
  2. a bitmask to and with the result
  3. an suggested bound which may be 1 or 2 but is not enforced
      either way (i.e. you can ignore it and return a larger result)

-- 
Alex