We are currently using murmur3 as our hash function for small strings (up to 128 chars). We plan to replace it with a better non-crypto hash function which is fast and produces unique 128-bit hash for a given input across the platforms (32/64-bit, x86 & arm).

Farmhash could have been an ideal candidate with it's speed and collision resistance but it's quite machine dependent and produces different results on different platform which makes it useless for us.

Cityhash has been known for collision weakness as demonstrated by siphash. So it's out of considerations.

Siphash is too slow and so is Highway hash which appears to be derivative of siphash (feel free to correct)

metrohash, xxhash, and seahash are under considerations.

I wouldn't be bothered by minor difference in speed. However, uniqueness across platform and collision resistance are main criterions.

Please suggest.


closed as unclear what you're asking by D.W., kodlu, otus, CodesInChaos Jul 20 '17 at 16:36

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 3
    $\begingroup$ I'm voting to close this question as off-topic because it does not appear to be about cryptography, as defined in the help center. $\endgroup$ – D.W. Jul 20 '17 at 0:25
  • $\begingroup$ Do you want a keyed hash or an unkeyed hash? And what do you mean by collision resistance? What do you use the hash for? $\endgroup$ – CodesInChaos Jul 20 '17 at 7:31

If the space of inputs is predetermined before you deploy your system, you can create a perfect hash that is very fast to evaluate and guarantees unique hash values, such as with gperf or nbperf.

If the space of inputs is chosen by a non-adaptive adversary—i.e., an adversary picks a set of keys and then feeds them all to your system at once without picking some keys based on how the system reacted to others—then you can pick some (almost-)universal hash family such as Poly1305 with a secret key you choose uniformly at random: for any pair of inputs, the probability over all possible keys that the inputs collide is $O(1/m)$, where $m$ is the number of possible hash values.

If the space of inputs is chosen by an adaptive adversary and Siphash is too slow, you will need to describe your performance budget in more detail:

  1. How many keys do you have?
  2. What is the distribution of key lengths?
  3. How many cycles per byte can you afford?
  4. How many cycles per key can you afford?
  5. How many bytes can you afford to transmit/store?
  6. What is the cost of a collision? Of $n$ collisions?

(Transmitting 8 bytes on a network is not free! Exercise for the reader: How many nanoseconds and joules does it take to compute Siphash on a 16-byte input on your laptop's CPU, and how many nanoseconds and joules does it take your laptop's ethernet phy to transmit 8 bytes?)


Not the answer you're looking for? Browse other questions tagged or ask your own question.