Re: propose renaming gnulib memxfrm to amemxfrm (naming collision with coreutils)

[Paul Eggert]

On 08/07/10 04:40, Simon Josefsson wrote:

> I suspect FNV or Xorshift would be faster, since they are so simple:

Yes, they'd be faster, but there may be some collision
problems with those.  FNV would seem better suited, since it's
a hash function.  I did quick scan for relevant articles and
found this quote:

  "FNV is not a collision-resistant function and has some known
  collision issues, which are common among multiplicative
  functions. Therefore, the probabilistic rationale presented in the
  paper, which assumes a perfect hash, should be taken with a grain of
  salt.  Generally, given that the performance benchmark is
  block-level crypto hashing, using MD5 would seem an appropriate
  choice, especially for inputs with lower entropy which would present
  a serious problem for simple hashes."

  Roussev V, Richard GG III, Marziale L.  Multi-resolution similarity
  hashing.  Digit Invest 4, 1 (2007), S105-13.
  <http://www.dfrws.org/2007/proceedings/p105-roussev.pdf>

True, sort -R isn't intended for crypto applications, but it is
supposed to work well with low-entropy keys.  Perhaps we should
leave well enough alone.