SeaHash: Explained
ticki.github.io
SeaHash: Explained
1–10 of 57 posts
Re: SeaHash: Explained
#2> SeaHash has mathematically provable statistical guarantees
I'm all for proofs but would love to see an empirical head-to-head against metroHash. Is it as good or better output distribution?
Re: SeaHash: Explained
#3> SeaHash has mathematically provable statistical guarantees I'm all for proofs but would love to see an empirical head-to-head against metroHash. Is it as good or better output distribution?
Should be easy to plug it into smhasher.
Re: SeaHash: Explained
#4I've been using blake2(b) for file hashing in some content addressable db stuff. What might be a scenario where i would choose Seahash over Blake2?
My main concern was speed and assurance that i would not see collisions. Beyond that, i am clearly naive on the subject.
Re: SeaHash: Explained
#5Discussion that came up the other week for those that missed it.
Re: SeaHash: Explained
#6I've been using blake2(b) for file hashing in some content addressable db stuff. What might be a scenario where i would choose Seahash over Blake2? My main concern was speed and assurance that i would not see collisions. Beyond that, i am clearly naive on the subject.
And on that note, has anyone seen any benches for blake2 vs Seahash/Metrohash? I'm not finding anything so far
Re: SeaHash: Explained
#7I've been using blake2(b) for file hashing in some content addressable db stuff. What might be a scenario where i would choose Seahash over Blake2? My main concern was speed and assurance that i would not see collisions. Beyond that, i am clearly naive on the subject.
The main question, aside from performance, is...
- Is there an (abstract) attack model? (Assuming that you have one if you ought to)
- Then: Can an attacker insert collisions into the DB, and is that problematic?
- Then: A non-cryptographic hash might be much easier to "reverse", especially for short inputs. Is that problematic?
If none of these are problematic you probably don't need a cryptographic hash.
Regarding performance: BLAKE2b on a Haswell gives you, in a "naive", pure C implementation (compiled to pure, non-vectorized AMD64 assembly), about 230 MB/s / GHz. (Referring to https://github.com/borgbackup/borg/issues/45#issuecomment-22... ), ie. something like 850-1000 MB/s on a desktop SKU. There are implementations that are around 10-30 % faster than that.
AFAIK all these newer n-c hash functions that popped up in the last couple years perform (on desktop SKUs) in the area of beyond ~10 GB/s.
Re: SeaHash: Explained
#8> `f : {0,1}^n → {0,1}^n` is a perfect PRF if and only if given a distribution `d : {0,1}^n → [0,1]`, `f` maps inputs following the distribution `d` to the uniform distribution.
Is this even possible? If the distribution `d` always returns 0, how can a function make it uniform?
It would be nice, if the article would go into more details on how SeaHash obtains this property, and how it related to collision avoidance.
Re: SeaHash: Explained
#9I've been using blake2(b) for file hashing in some content addressable db stuff. What might be a scenario where i would choose Seahash over Blake2? My main concern was speed and assurance that i would not see collisions. Beyond that, i am clearly naive on the subject.
The main question, aside from performance, is... - Is there an (abstract) attack model? (Assuming that you have one if you ought to) - Then: Can an attacker insert collisions into the DB, and is that problematic? - Then: A non-cryptographic hash might be much easier to "reverse", especially for short inputs. Is that problematic? If none of these are problematic you probably don't need a cryptographic hash. Regarding…
Re: SeaHash: Explained
#10> `f : {0,1}^n → {0,1}^n` is a perfect PRF if and only if given a distribution `d : {0,1}^n → [0,1]`, `f` maps inputs following the distribution `d` to the uniform distribution. Is this even possible? If the distribution `d` always returns 0, how can a function make it uniform? It would be nice, if the article would go into more details on how SeaHash obtains this property, and how it related to collision avoidance.
It's not clear what the author means here. This is not a very mathematical article.
(Nit: d is a distribution so it can not always return 0 -- it has to sum to 1. But your point stands.)