What I'm saying is that not revealing key from observing outputs is a required feature for such PRF to be cryptographically secure. What you cited is a "worst c

What I'm saying is that not revealing key from observing outputs is a required feature for such PRF to be cryptographically secure. What you cited is a "worst case" for hash table implementation — a hash table revealing its indices; which is fine with SipHash exactly because it's a cryptographic PRF. Network traffic authentication is basically, appending the output of SipHash(packet) to packet and then checking it — again, having many such outputs should not reveal the secret key or allow forging packets, because SipHash is a secure MAC. You're correct — it shouldn't replace HMAC in most cases mainly due to its short output (64 bits) and because it received less analysis than common cryptographic hash functions/MACs.