3 ms·

The seed is kept secret. Observing siphash outputs will not reveal the seed, unless an entirely infeasible quantity of outputs are observed.

by zx2c4 10y ago

thomasahle 10y ago
This is a nice "worst case" feature of siphash. However I don't think its authors would recommend using it in case you know outputs will be easily observable.
- zx2c4 10y ago
  Citation?
- dchest 10y ago
  It's not "worst case" feature, it's the standard, minimal feature of any secure cryptographic PRF.
  - thomasahle 10y ago
    It's worst cast in the model of security that hash tables are usually evaluated under. The authors of Siphash state as much: > Stopping advanced hash flooding. The _worst possible_ exposure of hash-table indices would simply show the attacker H(m) mod `for any attacker-selected string m. We advocate protecting against this maximum possible exposure, so that applications do not have to worry about how much exposure they actually provide. The attacker’s goal, given this exposure, is to find many strings m having a single value H(m) mod `. https://131002.net/siphash/siphash.pdf https://131002.net/siphash/siphash.pdf They also state that the "Target applications include network traffic authentication and hash-table lookups protected against hash-flooding denial-of-service attacks". It's nice to have a fast random hash function, that is also reasonably cryptographically strong, in case an attacked gets access to the hash values. That doesn't mean it's as cryptographically strong as hash functions specifically designed for full exposure. I'm just saying, use it for hash-tables, but don't use it as a general replacement for HMAC-SHA-1 in your encryption schemes. At least I don't see the authors recommending that anywhere.
    - dchest 10y ago
      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.

The seed is kept secret. Observing siphash outputs will not reveal the seed, unless an entirely infeasible quantity of outputs are observed.

by zx2c4 10y ago

The seed is kept secret. Observing siphash outputs will not reveal the seed, unless an entirely infeasible quantity of outputs are observed.

thomasahle 10y ago

This is a nice "worst case" feature of siphash. However I don't think its authors would recommend using it in case you know outputs will be easily observable.

zx2c4 10y ago
Citation?
dchest 10y ago
It's not "worst case" feature, it's the standard, minimal feature of any secure cryptographic PRF.
- thomasahle 10y ago
  It's worst cast in the model of security that hash tables are usually evaluated under. The authors of Siphash state as much: > Stopping advanced hash flooding. The _worst possible_ exposure of hash-table indices would simply show the attacker H(m) mod `for any attacker-selected string m. We advocate protecting against this maximum possible exposure, so that applications do not have to worry about how much exposure they actually provide. The attacker’s goal, given this exposure, is to find many strings m having a single value H(m) mod `. https://131002.net/siphash/siphash.pdf https://131002.net/siphash/siphash.pdf They also state that the "Target applications include network traffic authentication and hash-table lookups protected against hash-flooding denial-of-service attacks". It's nice to have a fast random hash function, that is also reasonably cryptographically strong, in case an attacked gets access to the hash values. That doesn't mean it's as cryptographically strong as hash functions specifically designed for full exposure. I'm just saying, use it for hash-tables, but don't use it as a general replacement for HMAC-SHA-1 in your encryption schemes. At least I don't see the authors recommending that anywhere.
  - dchest 10y ago
    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.