[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: [ANN] LuaJIT-2.0.0-beta1
- From: Florian Weimer <fw@...>
- Date: Wed, 04 Nov 2009 20:53:34 +0100
* Rob Kendrick:
> On Wed, 04 Nov 2009 20:33:28 +0100
> Florian Weimer <firstname.lastname@example.org> wrote:
>> * Rob Kendrick:
>> > One approach I've used in the past is to use an (extremely) trivial
>> > PRNG to decide which byte to hash next, using the current hash
>> > value as the seed, and the length of the string as the initial seed.
>> See the other thread---it's pretty easy to force collisions with
>> longer strings.
> To force, or accidentally come by? If the former, it's pretty easy
> whatever hash you use,
Sure? Try lookup3.c from Bob Jenkins.
> unless it's a cryptographic one, which you don't want at all in this
You don't want a slow function. But why not something resistant to
Those cryptographic hash functions try to solve a much more difficult
problem: absence of collisions without any secret. For some opaque
implementation, the "without any secret" part is certainly overkill.