Hacker News Reader

Comment by b7kich | Hacker News Reader

Two wrongs don't make a right. The fact that "a".hash == "\0a" hash is an issue with the hash function. nothing else. Seeding the hash function so it is unique for each process does not solve the issue.

View on HN

Recent versions of Ruby also use a much better hash function. Java's hash function on strings has a slightly less trivial process for generating collisions, but it's still very easy to generate enough of them to pose a DoS risk.

Edit: actually, Java's String.hashCode() has exactly the same problem — prepending null chars doesn't change the hash code. And because the hash function is actually part of the Java standard library docs, it will probably never be changed (unlike Ruby's).

They have already announced that the hash function will be changed for Java 8 and you can enabled the change in the current version of Java 7 (u6).

http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-Ma...

It solves the issue where an attacker can easily prepare a chain of collisions for a DOS-type attack, doesn't it?

How in the world would does the described issue with hash codes on distributed systems fix the issue of hash collisions in a request? Usually the attacker would send multiple parameters for "a","\0a","\00a" in a single request anyhow.

Sorry, I think I misunderstood your first post then. By "the issue", I thought you were referring to the issue that the randomized-hash set out to solve (DOS attacks/pathological performance due to predictable hashes)

Reply on news.ycombinator.com