Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:96014 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 58952 invoked from network); 16 Sep 2016 05:59:58 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 16 Sep 2016 05:59:58 -0000 Authentication-Results: pb1.pair.com smtp.mail=thruska@cubiclesoft.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=thruska@cubiclesoft.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain cubiclesoft.com designates 149.56.142.28 as permitted sender) X-PHP-List-Original-Sender: thruska@cubiclesoft.com X-Host-Fingerprint: 149.56.142.28 28.ip-149-56-142.net Received: from [149.56.142.28] ([149.56.142.28:59046] helo=28.ip-149-56-142.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id F2/26-09226-35A8BD75 for ; Fri, 16 Sep 2016 01:59:47 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: thruska@cubiclesoft.com) with ESMTPSA id 075973E852 To: Stanislav Malyshev , Scott Arciszewski , PHP Internals References: Message-ID: <7d5727ba-da33-e3c5-1d1f-318c45d81616@cubiclesoft.com> Date: Thu, 15 Sep 2016 22:59:39 -0700 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] HashDoS From: thruska@cubiclesoft.com (Thomas Hruska) 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/