On 9/16/16 1:59 AM, Thomas Hruska wrote:
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.
The difference is big enough that people won't want this as a precaution
affecting all of PHP's hashes.
But it's small enough that people might opt for it as a defensive
measure in case of serious attacks in the wild. So having an
implementation but not compiling it by default would be interesting.
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.
This is consistent with what Nicholas Clark wrote[1] that I mentioned
already in my reply to Scott.
However, he also says
> I've got a sneaking suspicion that this story still has legs, and
that someone will pop up with some new surprise or twist. Hence I'm
keeping an eye open to spot any more developments in this decade old
saga, in case there is action Perl 5 needs to take.
In which case it is nice for Perl to have SipHash implemented but not
compiled by default.
Tom
[1]
http://news.perlfoundation.org/2012/12/improving-perl-5-grant-report-11.html
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
