
HighwayHash: Fast hashing at over 10 GB/s per core in Golang - jtsymonds
https://blog.minio.io/highwayhash-fast-hashing-at-over-10-gb-s-per-core-in-golang-fee938b5218a
======
pjscott
This is a pretty sweet hash function, with security guarantees similar to
SipHash but about 5x faster. Here's more info:

[https://github.com/google/highwayhash](https://github.com/google/highwayhash)

------
DenisM
Wicked.

    
    
      BenchmarkHighwayHash            11986.98 MB/s
      BenchmarkSHA256_AVX512           3552.74 MB/s
      BenchmarkBlake2b                  972.38 MB/s
      BenchmarkSHA1                     950.64 MB/s
      BenchmarkMD5                      684.18 MB/s
      BenchmarkSHA512                   562.04 MB/s
      BenchmarkSHA256                   383.07 MB/s

~~~
nneonneo
HighwayHash is explicitly called out as being not cryptographically secure.
Every other hash in your list is (or was) considered cryptographically secure.
Therefore these aren’t really comparable, and it was somewhat disingenuous of
the authors here to make that comparison.

~~~
CJefferson
I think somewhat disingenuous is a bit soft, given these people should know
better, in my mind it is scientific misconduct to only compare against
cryptographicly secure hashes.

------
srgpqt
Would be interesting to see how MeowHash compares.

------
y4m4b4
For all enthusiastic folks you may want to read more here on SipHash
comparisons

[https://github.com/fwessels/HashCompare/blob/master/README.m...](https://github.com/fwessels/HashCompare/blob/master/README.md)

[https://github.com/fwessels/HashCompare/issues/1](https://github.com/fwessels/HashCompare/issues/1)

------
microcolonel
It is a very cool function. It'd be interesting if a more thorough
cryptanalysis were performed (though if you read the Google Research paper,
you get an impression that they are breaking fresh ground, so there would be a
lot more effort involved in such an analysis). I think this function or ones
like it may not only be very fast on AVX2, but on some other systems as well.

------
m0zg
Would be cool to have something like this in the standard library. This is
getting close to being memory bound. In fact it will be memory bound on most
amd64 machines if you use more than 2 cores. It's kinda pointless to optimize
much further, even if further optimization is possible.

------
inamberclad
Is it really written in Go if they're using optimized assembly to implement
parts of it?

~~~
dana321
Its written in C++ and Assembly, the go library is just a wrapper

~~~
y4m4b4
There is no C++ in the code, it is a native Go library of Google's HighwayHash
implementation

------
rurban
They claim the same "fastness" as Siphash whilst actually being on the slower
end of all good hash functions. Too slow for real world usage, and not secure
enough for real world security attacks. Compare
[https://github.com/rurban/smhasher](https://github.com/rurban/smhasher) and
my complaints
[https://github.com/google/highwayhash/issues/28](https://github.com/google/highwayhash/issues/28)

~~~
saagarjha
No offense, but you don't come off very nicely in that thread. Perhaps you
could rephrase your criticism in a way that would make the maintainers more
likely to listen to you?

~~~
rurban
No, it lead to actual harm on billions of users. And Google did listen and
reacted accordingly.

But they still didn't put their hash to external scrutinity, still waiting for
the pull request to get it tested with smhasher.

~~~
saagarjha
Still, there's no need to be rude.

~~~
rurban
I'm never rude.

~~~
saagarjha
…I personally find that very hard to believe. Maybe you weren't specifically
"rude" here, but you were clearly unpleasant–you called their claims "false"
and "nonsense" repeatedly, which is rarely if ever necessary.

~~~
rurban
Calling false claims "false" is necessary and not rude.

And I just added Highwayhash now to smhasher by myself and my initial analysis
was confirmed. It's the 2nd slowest of all tested good hashes, only behind
Siphash. Every other is simplier and faster. Chi-Square on the lower 32bits
was 0.00 so it's really a good one. But I see no usecase for it, really.

------
justinclift
Title should probably mention "(2018)".

