Re: HashDoS

On 9/15/2016 5:20 PM, Stanislav Malyshev wrote:

Hi! 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 friends, 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): https://www.131002.net/siphash/

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: https://github.com/cubiclesoft/cross-platform-cpp (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 PHP. 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. http://cubiclesoft.com/