RFR: 8221836: Avoid recalculating String.hash when zero

[Aleksey Shipilev]

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