Comment 1:

Randomizing the hash function could be as simple as replacing the hash initialization
values (runtime/alg.c:20,22) with ones generated when the runtime starts.
Is there anything special about the magic numbers 2860486313 and 33054211828000289? They
have 19 and 27 set bits, respectively. I suspect any number with around half the bits
set and evenly distributed would have very similar performance.

Comment 2:

Labels changed: added priority-go1, removed priority-triage.

Owner changed to @rsc.

Status changed to Accepted.

Comment 3:

Owner changed to builder@golang.org.

Comment 4 by thirsteh:

This may be of interest if the hash function is being altered anyway:
http://code.google.com/p/cityhash/source/browse/trunk/README

Comment 5:

Cityhash is overkill for a runtime hash function, and probably isn't sufficiently random
for the lengths of data we're likely to be using as map keys. Jenkins one-at-a-time has
much simpler code and would be good enough here. It's also what Perl uses for their
hashes. As a side note, there's already an implementation of Jenkins at
http://github.com/dgryski/dgohash .

Comment 6:

ENOCOFFEE:  Forgot the runtime is in C.  Anyways, the original Jenkins' C code is in the
public domain anyway: http://burtleburtle.net/bob/hash/doobs.html

Comment 7:

We won't be changing the hash function this close to Go 1,
to avoid introducing last-minute bugs.
However, after Go 1, I do think we should look into
whether it makes sense to use a different hash function.
If someone wants to do the work and the benchmarking,
great.

Comment 8:

Labels changed: added go1-must.

Comment 9:

This issue was closed by revision 8e765da.

Status changed to Fixed.

Comment 10 by bboissin:

I might have misread the code, but I don't see a seed being used in alg.c (the "seed" is
mixed with the hash after the hash computation, so a collision will happen regardless of
the seed being changed.

Comment 11:

Since the seed is used in the hash computations, the set of keys that will collide is
different each time the program is run.  That avoids the stated problem.

Comment 12:

It helps, but the IV only adds so much randomness. A more long-term solution would be to
e.g. use https://131002.net/siphash/ down the road.

Comment 13:

I don't understand the benefit that would bring, but I do know this: if this is an
important issue that should be addressed, please open a new issue about it, rather than
adding a comment to an issue that is marked fixed.  Please don't simply reopen this
issue, as I believe the issue described in the original comment is indeed fixed.  Please
open a new issue describing the problem and the proposal.  Thanks.

Comment 14:

SipHash has similar speed to non-cryptographic hash functions, but it's about as hard to
find collisions as it is with cryptographically strong hash functions, rendering
pre-compute efforts futile even if the attacker guesses the IV/salt (or precomputes for
the set of all possible salts.)
I don't think it's terribly important, or that Go should adopt it yet--it's pretty
new--but point taken. I will, thanks. (FWIW, the Perl community was the first by far to
adopt IV randomization, and they've switched.)