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/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
