Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:58990 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 60494 invoked from network); 18 Mar 2012 00:12:29 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 18 Mar 2012 00:12:29 -0000 Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.133 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 67.192.241.133 smtp133.dfw.emailsrvr.com Linux 2.6 Received: from [67.192.241.133] ([67.192.241.133:60695] helo=smtp133.dfw.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id CF/E3-43639-D68256F4 for ; Sat, 17 Mar 2012 19:12:29 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp13.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id EC92E3D014A; Sat, 17 Mar 2012 20:12:25 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp13.relay.dfw1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 9BE983D0148; Sat, 17 Mar 2012 20:12:25 -0400 (EDT) Message-ID: <4F652868.7070901@sugarcrm.com> Date: Sat, 17 Mar 2012 17:12:24 -0700 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: Sam CC: "internals@lists.php.net" References: <4F65267D.3040005@googlemail.com> In-Reply-To: <4F65267D.3040005@googlemail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Randomize hash-function in php From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > Anyway I was looking at the hash function in PHP the other week, and was > playing around with some different implementations. DJBX33A is fast, > which I guess is why PHP uses it as it is hit so many times in the > execution. Some time ago we've checked various implementations of hash functions and the result was none produces better results consistently than one we already have. Note that you have to account not only for the function itself but for the usage patterns - e.g., distribution of key sizes for variables, functions, classes, etc. However bigger question is - wouldn't another hash function be as vulnerable? Unless we have a perfect hash we'll still have collisions, and that means it still can be attacked if collisions are easy to generate. Obvious solution would be to use a salt for the hash, which prevents blind pre-computing of hash collisions. However, due to the fact that PHP hash values can be reused in different processes by bytecode caches, implementing it properly is not trivial. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227