Because I got down voted:
1) If he's arguing that SipHash (or any keyed) hash function is insufficient because one can presume that the key can be acquired, then that would render all encryption schemes insecure. The security of any keyed cipher or hash is always predicated on maintaining the secrecy of the key, period. If you throw that presumption out the door than they're all "broken".
2) If he's arguing that he can generate collisions by timing when an injected key collides, he never shows how that information can be used to reliably generate new collisions. At best he only _alludes_ to this. He says something about having code to do it, but then refuses to provide the code.
If a hash table only has two buckets, it's trivial to create collisions. For a uniformly random hashing function you have a 50% chance. But so what? Unless the hash table is a fixed size, when you try to inject more keys (usually 50%-80% of the hash table size) the table will be resized. This will happen regardless of the collision rate, and indeed you want to avoid predicating resize on actual collision rate because otherwise an attacker can force you to use up all memory. All you need for this is a simple counter for the table. (And of course your hash should evenly distribute keys, as SipHash does.)
If you use a fixed-sized table, then not only will a secure hash not help you, but neither will anything else. If an attacker can reliably generate biased collisions, then he can always cause worse-case performance, including triggering whatever fancy reshuffle logic the hash table uses after a collision, violating the presumption of amortized O(1) work.
Note that the paper cited in the Github thread (Wool 2009) presumes a small key space:
We have demonstrated that a remote algorithmic complexity
attack, against randomized hash tables, is possible if the
secret value is chosen from a small enough space. More
secret bits cause more effort, time and space to be consumed
in the information gathering stage. Thus, it seems that a
random value of 32 bits would render this attack impractical
with today's technology. Note though that in this paper the
attacker iterates over all possible random values in a
brute-force manner, searching for bucket collisions.
However, the search space may be limited to a smaller subset
of random numbers by taking advantage of the vulnerabilities
in the Linux Random Number Generator as suggested in
(Gutterman et al., 2006). This might lead to a feasible
attack against a server with a longer secret value.
SipHash takes a 128-bit key. The Wool attack isn't even remotely feasible. Even if the hash table is small and you're reducing the 64-bit SipHash-generated key to only, say, 10 bits, you still can't recover the key and you can't generate biased collisions. As for targeting Linux's PRNG, that same argument applies to
all cryptographic software schemes.
EDIT: Previously said the Wool paper relied on fixed-sized hash tables. But it actually relies on a small key space permitting a brute force, oracle attack.