On 4/9/19 10:53 AM, Peter Levart wrote: > On 4/9/19 10:11 AM, Aleksey Shipilev wrote: >>> 2. No risk of hashcode recomputation for the 2^-32 case. >>> This might seem laughable, until you remember that it's exactly >>> those cases that DOS attackers like to create. >> Alt-hashing covers this obscure case in the course of mitigating much easier >> and much broader attack >> on String hashcode. We don't get to wave in every single hack into class >> libraries under "security" >> justification, especially when the mitigation already exists. > > Which alt-hashing are you talking about? The one which was removed from Java > code of String in > transition from JDK 7 -> JDK 8 ? > > AFAIK, there's no alt-caching for pure java code for Strings any more > (there's something for > internal JVM use). It was dropped when (Concurrent)HashMap got tree-ification.
Oh snap, I misremember things. Okay, so treefication mitigates the attack on colliding hashcodes by going the String.compare route, and thus resolving the O(n^2) algorithmic attack. I still don't see zero hashcode presents a similar same attack surface: computing the hashcode for the incoming string would take the same time, regardless of what hashcode value it produces. Although I can see the defense-in-depth argument more clearly now, I am still on the fence it warrants a fix. -Aleksey
