[rurban]

Still not secure if you can read out the seed. Brute forcing SipHash collisions with the known seed is also just a matter of seconds to minutes. http://perl11.org/blog/seed.html

A proper security fix can only be to fix the collision resolution, never using a slower hash function. It's also 10x faster then.

[minitech]

> Still not secure if you can read out the seed.

Which you do as an attacker by… asking politely? Or is it easy to leak the seed by accident?

In other news, there’s a relatively low-cost attack on AES when you know the key.

[rurban]

With dynamic languages like python it's trivial. Calculate the position and peek it.

With static languages it's still easy when you got enough information: source code, timing info and ordering (e. g JSON). With a proper SAT solver doable.

Leaking by accident is e.g even more trivial in perl, just set a magic ENV var. But peeking the fixed offset is easiest.

It's all just security theatre. There's no real use-case for something so slow as Siphash.

[minitech]

Do you often give DoS threats arbitrary code execution or the ability to set environment variables? Because there’s no need to bother with hash collisions to DoS yourself.

  while True: pass

As for finding the seed with a SAT solver: no, not doable. Not from actual hashes, let alone timing and order hints at actual hashes.

[tromp]

Finding (cycles of) collisions in siphash is used as a memory-hard Proof-of-Work:

https://github.com/tromp/cuckoo

[rurban]

Only for hash tables which use all bits. (e.g. prime sized).

Almost nobody does. For normal power-of-2 hash tables finding collisions in the lowest bits leading to a successful amplification is trivial by brute-force. Since Siphash is so slow it can last up to 4 minutes, for smaller tables still < 5s.