Hacker News Reader

Hacker News

Comment by dom0 | Hacker News Reader

Parent Full thread

dom0

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.

View on HN

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 need cryptographic security. It's that simple.

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.

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.

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.

I agree. SipHash is certainly strong if you don't know the key.

Reply on news.ycombinator.com