SipHash 1-3 is almost as fast as HashDoS-vulnerable hash functions:
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com>
On Fri, Sep 16, 2016 at 1:59 AM, Thomas Hruska <thru...@cubiclesoft.com>
> On 9/15/2016 5:20 PM, Stanislav Malyshev wrote:
>> On 9/15/16 11:48 AM, Scott Arciszewski wrote:
>>> Would the Internals team be open to discussing mitigating HashDoS in a
>>> future version of PHP? i.e. everywhere, even for json_decode() and
>>> by fixing the problem rather than capping the maximum number of input
>>> parameters and hoping it's good enough.
>>> I'd propose SipHash (and/or a derivative):
>> I am worries about performance. Base hash structure has to be *very*
>> fast. I have doubts that cryptographic function can perform at these
>> levels. Did you test what is performance of this function compared to
>> existing hash function?
> If anyone wants a VERY rough estimate of relative performance degradation
> as a result of switching to SipHash, here's a somewhat naive C++
> implementation of a similar data structure to that found in PHP:
> (See the "Hash performance benchmark" results at the above link.)
> In short, there's a significant degradation just switching from djb2 to
> SipHash depending on key type. A similar effect would probably be seen in
> Randomizing the starting hash value for djb2 during the core startup
> sequence *could* also be effective for mitigating HashDoS. Extensive
> testing would have to be done to determine how collision performance plays
> out with randomized starting hash values. I can't find any arguments
> anywhere against using randomized starting hash values for djb2. Also of
> note, the 33 multiplier seems more critical than anything else for mixing
> bits together.
> Thomas Hruska
> CubicleSoft President
> I've got great, time saving software that you will find useful.