Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SeaHash: Explained

ticki.github.io

Post reply on HN
Print view View original

31–40 of 57 posts

Re: SeaHash: Explained

#31

Post by tptacek »

ticki_ wrote: post #20
leeoniya wrote: post #9

Earlier quoted context omitted.

https://github.com/ticki/tfs/issues/5#issuecomment-266031657

SeaHash is obviously not cryptographic (nor is SipHash), but I hope it is a secure PRF (i.e. the keys cannot be extracted), and this was the best attack I was able to construct. Still, it isn't a practical attack, but I suppose it is possible to improve. Note that I am not a cryptographer, and my only piece of advice is: For the sake of god, don't use hash functions not designed for cryptographic security, if you nee…

SipHash is a cryptographic hash with a pretty good pedigree. The distinction between SipHash and Blake2 is more subtle than "cryptographic vs not".

Re: SeaHash: Explained

#32

Post by dom0 »

tptacek wrote: post #31
ticki_ wrote: post #20

Earlier quoted context omitted.

SeaHash is obviously not cryptographic (nor is SipHash), but I hope it is a secure PRF (i.e. the keys cannot be extracted), and this was the best attack I was able to construct. Still, it isn't a practical attack, but I suppose it is possible to improve. Note that I am not a cryptographer, and my only piece of advice is: For the sake of god, don't use hash functions not designed for cryptographic security, if you nee…

SipHash is a cryptographic hash with a pretty good pedigree. The distinction between SipHash and Blake2 is more subtle than "cryptographic vs not".

Sure. For starters SipHash targets a lower-end spectrum of device (in a way) than Blake2, and is also less flexible. Since SipHash produces a 64 bit digest it isn't suitable for many applications in the first place. The two also differ significantly in other cryptographic properties, making Blake2 a more secure and easier (safer) to apply choice.

I would tend to say that SipHash is, in a cryptographic context, more an "if you know what you're doing" choice, and not at all a general purpose [cryptographic] hash function.

Re: SeaHash: Explained

#33

Post by JoshTriplett »

notheguyouthink wrote: post #4

I'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.

For a content-addressable database, you absolutely want a cryptographic hash. (And please, don't make the mistake Git did: please include the name of the hash function in the "address", to make it possible to change the hash function.)

Re: SeaHash: Explained

#34

Post by loeg »

libeclipse wrote: post #15

Could someone explain what the point is? Is there a use-case for this for "general hashing" and such, where sha256 is _genuinely_ insufficient?

> Is there a use-case for this for "general hashing" and such, where sha256 is _genuinely_ insufficient?

Yeah. There are often times when you want to hash data but don't want to waste sha256-levels of cycles doing so. Applications are pretty much everything except cryptographic signing. Load-balancing, higher-quality checksuming, etc.

Re: SeaHash: Explained

#35

Post by loeg »

llimllib wrote: post #22
libeclipse wrote: post #15

Could someone explain what the point is? Is there a use-case for this for "general hashing" and such, where sha256 is _genuinely_ insufficient?

A good example is for a bloom filter: using sha256 is much too slow for good filter performance, you want something like siphash or some other non-cryptographic hash. Here's a good story of the performance benefits of switching from cryptographic to non-crypto hashes: https://github.com/bitly/dablooms/pull/19 (But I don't recommend you use murmur anymore: https://emboss.github.io/blog/2012/12/14/breaking-murmur-has..…

> But I don't recommend you use murmur anymore

I think xxHash was/is the fastest good non-crypto hash, and now SeaHash may be best. Although I'd like to see a bit more data on that (small keys? large keys? benchmarking methodology) than SeaHash's author is providing.

Re: SeaHash: Explained

#36

Post by stcredzero »

mdergosits wrote: post #30
falcolas wrote: post #29

Earlier quoted context omitted.

A trade off between collision potential vs. speed. Sometimes you need speed more than you need cryptographic levels of collision avoidance. For example, finding unique files on the file system. After looking at size, first and last bytes, it would be better to filter quickly on an imperfect hash (with, say, a 1 in 1^56 chance of collision) than slowly on a perfect hash (with a 1 in 1^256 chance).

I hope you mean 2^56 and 2^256 :)

We can increase that by one to the fourth power!

http://aperiodical.com/2013/05/the-maths-of-star-trek-the-or...

Re: SeaHash: Explained

#37

Post by loeg »

JoshTriplett wrote: post #33
notheguyouthink wrote: post #4

I'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.

For a content-addressable database, you absolutely want a cryptographic hash. (And please, don't make the mistake Git did: please include the name of the hash function in the "address", to make it possible to change the hash function.)

It seems like Git could change the disk format eventually with backwards compatibility for current SHA1 addresses. You don't even need to rewrite old objects. You just need to know which hash method a given tree/commit object is using to verify history or perform checkout. That could be a flag or tag in the object.

Re: SeaHash: Explained

#38

Post by llimllib »

loeg wrote: post #35
llimllib wrote: post #22

Earlier quoted context omitted.

A good example is for a bloom filter: using sha256 is much too slow for good filter performance, you want something like siphash or some other non-cryptographic hash. Here's a good story of the performance benefits of switching from cryptographic to non-crypto hashes: https://github.com/bitly/dablooms/pull/19 (But I don't recommend you use murmur anymore: https://emboss.github.io/blog/2012/12/14/breaking-murmur-has..…

> But I don't recommend you use murmur anymore I think xxHash was/is the fastest good non-crypto hash, and now SeaHash may be best. Although I'd like to see a bit more data on that (small keys? large keys? benchmarking methodology) than SeaHash's author is providing.

yeah I should look into that more. aapleby seems to have given some pretty good arguments against SeaHash in the previous discussion: https://news.ycombinator.com/item?id=13058652

Re: SeaHash: Explained

#39

Post by zeveb »

libeclipse wrote: post #17
chadaustin wrote: post #16

Earlier quoted context omitted.

Hi, I recently used a hash function like this as part of a React-style delta calculation engine but for Swift / iOS. I needed a hash function that was fast but collision-resistant, and I did not need a cryptographic hash, as all data is trusted (and a hash collision would not actually matter that much). I chose SpookyHash V2 based on the advice of some peers and http://aras-p.info/blog/2016/08/09/More-Hash-Function-T…

Even when I've not needed a cryptographic hash, I've still used one, because why not? I've never not needed one so bad as to resort to some barely studied, homemade hashing algorithm. > A hash collision wouldn't matter that much. Interesting. What was the use for the hash function then?

> Even when I've not needed a cryptographic hash, I've still used one, because why not?

Performance. Take a look at djb's (non-cryptographic) hash, with a constant multiplier chosen to be implemented with a shift and an add — that's the level of performance a non-cryptographic hash (e.g. for hash tables & similar purposes) needs.

https://gist.github.com/hmic/1676398

Re: SeaHash: Explained

#40

Post by Null-Set »

llimllib wrote: post #38
loeg wrote: post #35

Earlier quoted context omitted.

> But I don't recommend you use murmur anymore I think xxHash was/is the fastest good non-crypto hash, and now SeaHash may be best. Although I'd like to see a bit more data on that (small keys? large keys? benchmarking methodology) than SeaHash's author is providing.

yeah I should look into that more. aapleby seems to have given some pretty good arguments against SeaHash in the previous discussion: https://news.ycombinator.com/item?id=13058652

That argument depends on the initial values being the same, you can easily make sure they are not.
Post reply on HN