4 ms·

Saying you can read the hash seed from memory sounds like a "wrong side of the airtight hatchway" problem. If I can already read bytes from the running executa

Saying you can read the hash seed from memory sounds like a "wrong side of the airtight hatchway" problem. If I can already read bytes from the running executable, I can just smash it to bits. If I can run processes on the machine at all, I don't need to slow it down with hash collisions, I can just fork bomb. Can you usefully attack without having that kind of access?

rurban 10y ago
No. The problem is the commit message, not yet the implementation. What will follow is what followed at all the other cases: ruby, python, php, rust, ... They will replace SHA1 with siphash (already done in this branch), their open-addressing with chaining and primes with power of 2. So they will loose all the previous performance and security by the false security and performance claim of siphash. siphash essentially says: we are DoS secure and we are fast. Both is provable wrong.
- zx2c4 10y ago
  Sorry but you still haven't substantiated your argument with any such "proof". It looks like you also made a "prediction" about what's going to be decided by people who certainly aren't you in the future. Got a cryptographically secure PRF that's faster than Siphash for small inputs and has undergone extensive cryptanalysis? If so, I'm all ears. If not, get lost, troll. There's a real use case for a secure PRF fast for small inputs. That's why this code has been added.
  - rurban 10y ago
    You are the troll when you dont see the obvious proofs. 1. DOS proof: a hash function can never lead to DoS proofness. Every hash function can be trivially brute forced to find enough collisions for such an attack. When you need to protect against such a worst case you don't make your hash function slower and get limited seed hiding, you rather check for such an attack and mitigate it directly, at the collision resolution. 2. Slowness: see my smhasher page. The slowest of all hash functions which is used in hash tables. I don't see a usecase for a slow PRF in net. All other PRF's are faster. I also don't see more security, only less. SHA1 replaced by SipHash surely makes it faster, but not safer.
- thomasahle 10y ago
  > No. The problem is the commit message, That's true. Calling it "cryptographically secure" could easily send the wrong signals. It's meant for network traffic authentication and hash-tables. Using it in all places where you previously used SHA is not a good idea. Hopefully the kernel developers will know when it's suitable.

rurban 10y ago

No. The problem is the commit message, not yet the implementation. What will follow is what followed at all the other cases: ruby, python, php, rust, ... They will replace SHA1 with siphash (already done in this branch), their open-addressing with chaining and primes with power of 2. So they will loose all the previous performance and security by the false security and performance claim of siphash. siphash essentially says: we are DoS secure and we are fast. Both is provable wrong.

zx2c4 10y ago
Sorry but you still haven't substantiated your argument with any such "proof". It looks like you also made a "prediction" about what's going to be decided by people who certainly aren't you in the future. Got a cryptographically secure PRF that's faster than Siphash for small inputs and has undergone extensive cryptanalysis? If so, I'm all ears. If not, get lost, troll. There's a real use case for a secure PRF fast for small inputs. That's why this code has been added.
- rurban 10y ago
  You are the troll when you dont see the obvious proofs. 1. DOS proof: a hash function can never lead to DoS proofness. Every hash function can be trivially brute forced to find enough collisions for such an attack. When you need to protect against such a worst case you don't make your hash function slower and get limited seed hiding, you rather check for such an attack and mitigate it directly, at the collision resolution. 2. Slowness: see my smhasher page. The slowest of all hash functions which is used in hash tables. I don't see a usecase for a slow PRF in net. All other PRF's are faster. I also don't see more security, only less. SHA1 replaced by SipHash surely makes it faster, but not safer.
thomasahle 10y ago
> No. The problem is the commit message, That's true. Calling it "cryptographically secure" could easily send the wrong signals. It's meant for network traffic authentication and hash-tables. Using it in all places where you previously used SHA is not a good idea. Hopefully the kernel developers will know when it's suitable.