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

51–57 of 57 posts

Re: SeaHash: Explained

#51

Post by ticki_ »

kibwen wrote: post #50
ticki_ wrote: post #47

Earlier quoted context omitted.

No, it's not a cryptographic hash function. It's a MAC function. The paper clearly states that it is not collision resistant.

I believe that you and tptacek may be using differing definitions of "cryptographic", because he tends to knows what he's talking about when it comes to cryptography (e.g. https://gist.github.com/tqbf/be58d2d39690c3b366ad ).

Oh, well.

What I think of as "cryptographic hash function" is a function resistent to pre-image attack, second pre-image attack, and collision generation.

Neither of those are satisfied by SipHash, and can thus not classify as a cryptographic hash function by the normal definition.

Re: SeaHash: Explained

#52

Post by tptacek »

ticki_ wrote: post #51
kibwen wrote: post #50

Earlier quoted context omitted.

I believe that you and tptacek may be using differing definitions of "cryptographic", because he tends to knows what he's talking about when it comes to cryptography (e.g. https://gist.github.com/tqbf/be58d2d39690c3b366ad ).

Oh, well. What I think of as "cryptographic hash function" is a function resistent to pre-image attack, second pre-image attack, and collision generation. Neither of those are satisfied by SipHash, and can thus not classify as a cryptographic hash function by the normal definition.

It's a cryptographic hash function, but not one suitable for all of the same applications as SHA2. It has security characteristics that other hash-table hashes (for instance) lack.

Re: SeaHash: Explained

#53

Post by ticki_ »

tptacek wrote: post #52
ticki_ wrote: post #51

Earlier quoted context omitted.

Oh, well. What I think of as "cryptographic hash function" is a function resistent to pre-image attack, second pre-image attack, and collision generation. Neither of those are satisfied by SipHash, and can thus not classify as a cryptographic hash function by the normal definition.

It's a cryptographic hash function, but not one suitable for all of the same applications as SHA2. It has security characteristics that other hash-table hashes (for instance) lack.

If you know the key, it is as weak as it gets (as the paper notes too, you can construct collisions easily if the key is known), so I disagree.

Re: SeaHash: Explained

#54

Post by tptacek »

ticki_ wrote: post #53
tptacek wrote: post #52

Earlier quoted context omitted.

It's a cryptographic hash function, but not one suitable for all of the same applications as SHA2. It has security characteristics that other hash-table hashes (for instance) lack.

If you know the key, it is as weak as it gets (as the paper notes too, you can construct collisions easily if the key is known), so I disagree.

Honestly, I really don't care about this debate, except to the extent that it's about whether SipHash "isn't cryptographic and therefore you might as well use CityHash or SeaHash", which just isn't true.

Re: SeaHash: Explained

#55

Post by xorxornop »

ticki_ wrote: post #46
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 lot of stuff. SHA256 is very slow, and that's no surprise. It's cryptographic after all. Here's a small list of usecases for non-cryptographic hash functions: - Checksums and error correction codes, as long as there is no way to maliciously use this. - Hash tables. These always use non-cryptographic hash functions. - Bloom filters. - Heuristic fingerprinting. They're not strong enough to be used for normal data fin…

I may be totally off-base here, but can't the SHA256 CPU instructions be used for this? Then it'd just be 1 (? Or is it more) instruction to perform?

Re: SeaHash: Explained

#56

Post by xorxornop »

rudolf0 wrote: post #49
0x6c6f6c wrote: post #42

> there is a major difference between cryptographic and non-cryptographic hash functions. SeaHash is not cryptographic Is this in reference to most used hash functions not leaving any way to trace the contents of what was hashed, or not being able to reliably reconstruct contents to generate a certain hash? Or something else entirely?

The latter. Even a very simple hash algorithm will almost always make it impossible to get the original contents back. You'd have to write an intentionally pathological algorithm to achieve that.

Well, yeah, unless the input is smaller than the digest, hashing is effectively a very lossy compression!

Re: SeaHash: Explained

#57

Post by ticki_ »

tptacek wrote: post #54
ticki_ wrote: post #53

Earlier quoted context omitted.

If you know the key, it is as weak as it gets (as the paper notes too, you can construct collisions easily if the key is known), so I disagree.

Honestly, I really don't care about this debate, except to the extent that it's about whether SipHash "isn't cryptographic and therefore you might as well use CityHash or SeaHash", which just isn't true.

I agree. SipHash is certainly strong if you don't know the key.
Post reply on HN