Alex Shinn scripsit:

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

Do you mean allowing a salt argument to the constructors?  I thought the
whole point of the salt was that it's supposed to be produced from
a high-quality random source.

>   1. we encourage and make security the easy default

Not if you expect users to pass it: they will just pass some crap constant
like zero.

>   2. we use a consistent API for all hash functions

I'm not sure how this applies.

>   3. we make unit testing possible

We make depending on what you are not supposed to depend on possible.
If salt comes from the implementation, unit tests can't depend on the
order of keys, but that just means they have to take precautions.

>   4. we provide stronger security by making per-table salt possible
>       (possibly even dynamically regenerated after too many collisions)

How does passing the salt explicitly to the table help with this?

>   5. we make various hash-table strategies using 2 or more hashes possible

This I don't understand at all.

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

You need to convince Will Clinger of this, since he convinced me that
the bound is nothing but extra work for an implementer of hash functions
and no help to the framework author.  He feels very strongly about it.

--
John Cowan          http://www.ccil.org/~cowan        xxxxxx@ccil.org
We do, doodley do, doodley do, doodley do,
What we must, muddily must, muddily must, muddily must;
Muddily do, muddily do, muddily do, muddily do,
Until we bust, bodily bust, bodily bust, bodily bust.  --Bokonon