<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
    <channel>
        <title>[PHP-DEV] Randomize hash-function in php</title>
        <description> Hi, All

I just came around that talk a couple of days ago ..
http://www.youtube.com/watch?v=R2Cq3CLI6H8

I don't know much about hash-maps and internal php-stuff at all, but they
say that the fix provided in 5.3.9 (and 5.4.0) is more a work-around than a
fix ...
Would it be an option to provide a real fix in PHP 6.0? They got the
feedback that this will take some time and is not trivial, but we have a
good time before PHP6 and can also break backwards compatibility for
php-plugins if really necessary.

As they said in the movie, PHP seems to have the algorithm DJBX33A
implemented as Ruby. So as they're so proud of the fix provided by the
Ruby-Team, may we can use that for PHP as well :)
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2011-4815

This is not much because some attacker can do something, but what if you
have a real-world-application that (for some reason) build up an array that
just will blow up because of that? I haven't experienced that until now,
but it's possible ...

Bye
Simon</description>
        <link>http://www.serverphorums.com/read.php?7,462383,462383#msg-462383</link>
        <lastBuildDate>Thu, 20 Jun 2013 00:56:47 +0200</lastBuildDate>
        <generator>Phorum 5.2.18</generator>
        <item>
            <guid>http://www.serverphorums.com/read.php?7,462383,464300#msg-464300</guid>
            <title>Re: [PHP-DEV] Randomize hash-function in php</title>
            <link>http://www.serverphorums.com/read.php?7,462383,464300#msg-464300</link>
            <description><![CDATA[ On 18/03/12 06:56, Tjerk Anne Meesters wrote:<br />
&gt; On Sun, Mar 18, 2012 at 8:12 AM, Stas Malyshev &lt;smalyshev@sugarcrm.com&gt; wrote:<br />
&gt;&gt; Obvious solution would be to use a salt for the hash, which prevents blind<br />
&gt;&gt; pre-computing of hash collisions. However, due to the fact that PHP hash<br />
&gt;&gt; values can be reused in different processes by bytecode caches, implementing<br />
&gt;&gt; it properly is not trivial.<br />
&gt; What if php uses salts for specific hashes only, such as GPC (or all<br />
&gt; hashes whose lifetime is limited to the current reuqest), and use a<br />
&gt; zero-value salt for all others?<br />
We'll need to have at least two kind of hashes, at that point, I think<br />
it makes sense<br />
to place the salt as a member of the HashTable struct. Bytecode caches<br />
would just<br />
store the salt with the hash. We can also mt_rand() the salt of each<br />
hash, for further<br />
randomization.<br />
<br />
<br />
-- <br />
PHP Internals - PHP Runtime Development Mailing List<br />
To unsubscribe, visit: <a href="http://www.php.net/unsub.php" target="_blank"  rel="nofollow">http://www.php.net/unsub.php</a>]]></description>
            <dc:creator>Ángel González</dc:creator>
            <category>php-internals</category>
            <pubDate>Sun, 18 Mar 2012 17:10:01 +0100</pubDate>
        </item>
        <item>
            <guid>http://www.serverphorums.com/read.php?7,462383,464221#msg-464221</guid>
            <title>Re: [PHP-DEV] Randomize hash-function in php</title>
            <link>http://www.serverphorums.com/read.php?7,462383,464221#msg-464221</link>
            <description><![CDATA[ Sent from my iPhone<br />
<br />
在 2012-3-18，15:05，Tjerk Meesters &lt;tjerk.meesters@gmail.com&gt; 写道：<br />
<br />
&gt; On 18 Mar, 2012, at 2:32 PM, Xinchen Hui &lt;laruence@gmail.com&gt; wrote:<br />
&gt;<br />
&gt;&gt;&gt; What if php uses salts for specific hashes only, such as GPC (or all<br />
&gt;&gt;&gt; hashes whose lifetime is limited to the current reuqest), and use a<br />
&gt;&gt;&gt; zero-value salt for all others?<br />
&gt;&gt; definitely no，thinking of pre-calculated hash.<br />
&gt;<br />
&gt; Pre-calculated hash of what? You mean binary serialisation?<br />
&gt;<br />
&gt;&gt; Or Ajax which use<br />
&gt;&gt; json_decode parse input json.<br />
&gt;<br />
&gt; That would be considered a request lifetime hash and therefore could be salted.<br />
&gt;<br />
&gt;&gt;<br />
&gt;&gt; IMO, this Make no sense but mess things up.<br />
&gt;<br />
&gt; We all have opinions. If a clear distinction between vulnerable and non vulnerable data can be reliably made, in my limited knowledge of the whole ecosystem I genuinely think this has a shot :)<br />
&gt;<br />
Ha, sorry for my rude words, I am not meaning you， but the point self;)<br />
<br />
And it's also why I am not usually saying words at internal@ , my poor<br />
English :)<br />
<br />
-- <br />
PHP Internals - PHP Runtime Development Mailing List<br />
To unsubscribe, visit: <a href="http://www.php.net/unsub.php" target="_blank"  rel="nofollow">http://www.php.net/unsub.php</a>]]></description>
            <dc:creator>Xinchen Hui</dc:creator>
            <category>php-internals</category>
            <pubDate>Sun, 18 Mar 2012 08:20:01 +0100</pubDate>
        </item>
        <item>
            <guid>http://www.serverphorums.com/read.php?7,462383,464220#msg-464220</guid>
            <title>Re: [PHP-DEV] Randomize hash-function in php</title>
            <link>http://www.serverphorums.com/read.php?7,462383,464220#msg-464220</link>
            <description><![CDATA[ On 18 Mar, 2012, at 2:32 PM, Xinchen Hui &lt;laruence@gmail.com&gt; wrote:<br />
<br />
&gt;&gt; What if php uses salts for specific hashes only, such as GPC (or all<br />
&gt;&gt; hashes whose lifetime is limited to the current reuqest), and use a<br />
&gt;&gt; zero-value salt for all others?<br />
&gt; definitely no，thinking of pre-calculated hash.<br />
<br />
Pre-calculated hash of what? You mean binary serialisation?<br />
<br />
&gt; Or Ajax which use<br />
&gt; json_decode parse input json.<br />
<br />
That would be considered a request lifetime hash and therefore could be salted. <br />
<br />
&gt; <br />
&gt; IMO, this Make no sense but mess things up.<br />
<br />
We all have opinions. If a clear distinction between vulnerable and non vulnerable data can be reliably made, in my limited knowledge of the whole ecosystem I genuinely think this has a shot :)<br />
<br />
<br />
-- <br />
PHP Internals - PHP Runtime Development Mailing List<br />
To unsubscribe, visit: <a href="http://www.php.net/unsub.php" target="_blank"  rel="nofollow">http://www.php.net/unsub.php</a>]]></description>
            <dc:creator>Tjerk Meesters</dc:creator>
            <category>php-internals</category>
            <pubDate>Sun, 18 Mar 2012 08:10:02 +0100</pubDate>
        </item>
        <item>
            <guid>http://www.serverphorums.com/read.php?7,462383,464218#msg-464218</guid>
            <title>Re: [PHP-DEV] Randomize hash-function in php</title>
            <link>http://www.serverphorums.com/read.php?7,462383,464218#msg-464218</link>
            <description><![CDATA[ Sent from my iPhone<br />
<br />
在 2012-3-18，13:57，Tjerk Anne Meesters &lt;datibbaw@php..net&gt; 写道：<br />
<br />
&gt; On Sun, Mar 18, 2012 at 8:12 AM, Stas Malyshev &lt;smalyshev@sugarcrm.com&gt; wrote:<br />
&gt;&gt; Obvious solution would be to use a salt for the hash, which prevents blind<br />
&gt;&gt; pre-computing of hash collisions. However, due to the fact that PHP hash<br />
&gt;&gt; values can be reused in different processes by bytecode caches, implementing<br />
&gt;&gt; it properly is not trivial.<br />
&gt;<br />
&gt; What if php uses salts for specific hashes only, such as GPC (or all<br />
&gt; hashes whose lifetime is limited to the current reuqest), and use a<br />
&gt; zero-value salt for all others?<br />
definitely no，thinking of pre-calculated hash. Or Ajax which use<br />
json_decode parse input json.<br />
<br />
IMO, this Make no sense but mess things up.<br />
<br />
Thanks<br />
&gt;<br />
&gt; --<br />
&gt; PHP Internals - PHP Runtime Development Mailing List<br />
&gt; To unsubscribe, visit: <a href="http://www.php.net/unsub.php" target="_blank"  rel="nofollow">http://www.php.net/unsub.php</a><br />
&gt;<br />
<br />
-- <br />
PHP Internals - PHP Runtime Development Mailing List<br />
To unsubscribe, visit: <a href="http://www.php.net/unsub.php" target="_blank"  rel="nofollow">http://www.php.net/unsub.php</a>]]></description>
            <dc:creator>Xinchen Hui</dc:creator>
            <category>php-internals</category>
            <pubDate>Sun, 18 Mar 2012 07:40:02 +0100</pubDate>
        </item>
        <item>
            <guid>http://www.serverphorums.com/read.php?7,462383,464217#msg-464217</guid>
            <title>Re: [PHP-DEV] Randomize hash-function in php</title>
            <link>http://www.serverphorums.com/read.php?7,462383,464217#msg-464217</link>
            <description><![CDATA[ On Sun, Mar 18, 2012 at 8:12 AM, Stas Malyshev &lt;smalyshev@sugarcrm.com&gt; wrote:<br />
&gt; Obvious solution would be to use a salt for the hash, which prevents blind<br />
&gt; pre-computing of hash collisions. However, due to the fact that PHP hash<br />
&gt; values can be reused in different processes by bytecode caches, implementing<br />
&gt; it properly is not trivial.<br />
<br />
What if php uses salts for specific hashes only, such as GPC (or all<br />
hashes whose lifetime is limited to the current reuqest), and use a<br />
zero-value salt for all others?<br />
<br />
-- <br />
PHP Internals - PHP Runtime Development Mailing List<br />
To unsubscribe, visit: <a href="http://www.php.net/unsub.php" target="_blank"  rel="nofollow">http://www.php.net/unsub.php</a>]]></description>
            <dc:creator>Tjerk Anne Meesters</dc:creator>
            <category>php-internals</category>
            <pubDate>Sun, 18 Mar 2012 07:00:01 +0100</pubDate>
        </item>
        <item>
            <guid>http://www.serverphorums.com/read.php?7,462383,464198#msg-464198</guid>
            <title>Re: [PHP-DEV] Randomize hash-function in php</title>
            <link>http://www.serverphorums.com/read.php?7,462383,464198#msg-464198</link>
            <description><![CDATA[ Hi!<br />
<br />
&gt; Anyway I was looking at the hash function in PHP the other week, and was<br />
&gt; playing around with some different implementations.  DJBX33A is fast,<br />
&gt; which I guess is why PHP uses it as it is hit so many times in the<br />
&gt; execution.<br />
<br />
Some time ago we've checked various implementations of hash functions <br />
and the result was none produces better results consistently than one we <br />
already have. Note that you have to account not only for the function <br />
itself but for the usage patterns - e.g., distribution of key sizes for <br />
variables, functions, classes, etc.<br />
However bigger question is - wouldn't another hash function be as <br />
vulnerable? Unless we have a perfect hash we'll still have collisions, <br />
and that means it still can be attacked if collisions are easy to generate.<br />
Obvious solution would be to use a salt for the hash, which prevents <br />
blind pre-computing of hash collisions. However, due to the fact that <br />
PHP hash values can be reused in different processes by bytecode caches, <br />
implementing it properly is not trivial.<br />
-- <br />
Stanislav Malyshev, Software Architect<br />
SugarCRM: <a href="http://www.sugarcrm.com/" target="_blank"  rel="nofollow">http://www.sugarcrm.com/</a><br />
(408)454-6900 ext. 227<br />
<br />
-- <br />
PHP Internals - PHP Runtime Development Mailing List<br />
To unsubscribe, visit: <a href="http://www.php.net/unsub.php" target="_blank"  rel="nofollow">http://www.php.net/unsub.php</a>]]></description>
            <dc:creator>Stas Malyshev</dc:creator>
            <category>php-internals</category>
            <pubDate>Sun, 18 Mar 2012 01:20:01 +0100</pubDate>
        </item>
        <item>
            <guid>http://www.serverphorums.com/read.php?7,462383,464197#msg-464197</guid>
            <title>Re: [PHP-DEV] Randomize hash-function in php</title>
            <link>http://www.serverphorums.com/read.php?7,462383,464197#msg-464197</link>
            <description><![CDATA[ On 17/03/12 23:17, Simon Schick wrote:<br />
&gt; Hi, All<br />
&gt;<br />
&gt; I just came around that talk a couple of days ago ..<br />
&gt; <a href="http://www.youtube.com/watch?v=R2Cq3CLI6H8" target="_blank"  rel="nofollow">http://www.youtube.com/watch?v=R2Cq3CLI6H8</a><br />
&gt;<br />
&gt; I don't know much about hash-maps and internal php-stuff at all, but<br />
&gt; they say that the fix provided in 5.3.9 (and 5.4.0) is more a<br />
&gt; work-around than a fix ...<br />
&gt; Would it be an option to provide a real fix in PHP 6.0? They got the<br />
&gt; feedback that this will take some time and is not trivial, but we have<br />
&gt; a good time before PHP6 and can also break backwards compatibility for<br />
&gt; php-plugins if really necessary.<br />
&gt;<br />
&gt; As they said in the movie, PHP seems to have the algorithm DJBX33A<br />
&gt; implemented as Ruby. So as they're so proud of the fix provided by the<br />
&gt; Ruby-Team, may we can use that for PHP as well :)<br />
&gt; <a href="https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2011-4815" target="_blank"  rel="nofollow">https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2011-4815</a><br />
&gt;<br />
&gt; This is not much because some attacker can do something, but what if<br />
&gt; you have a real-world-application that (for some reason) build up an<br />
&gt; array that just will blow up because of that? I haven't experienced<br />
&gt; that until now, but it's possible ...<br />
&gt;<br />
&gt; Bye<br />
&gt; Simon<br />
&gt;<br />
<br />
Hi,<br />
<br />
Fairly new to this list so go easy :P..<br />
<br />
Anyway I was looking at the hash function in PHP the other week, and was <br />
playing around with some different implementations.  DJBX33A is fast, <br />
which I guess is why PHP uses it as it is hit so many times in the <br />
execution.<br />
<br />
However I tried and benchmarked a few different algorithms, I didn't try <br />
the patch you mentioned, however the only algorithm that came anywhere <br />
close to matching the DJBX33A method is Paul Hseih's Super Fast Hash <br />
algorithm: <a href="http://www.azillionmonkeys.com/qed/hash.html" target="_blank"  rel="nofollow">http://www.azillionmonkeys.com/qed/hash.html</a><br />
<br />
I benchmarked the DJBX33A against Hseih's algorithm and compared the <br />
results using an Intel x86 architecture and an AMD 64 machine and both <br />
algorithms performed similarly.  The benchmarks weren't robust as they <br />
were only quick, 'let's hack and see' tests.  Would be interesting if <br />
anyone else has had a go.<br />
<br />
If I can find it I'll post a patch so you could?<br />
<br />
Cheers<br />
<br />
Sam]]></description>
            <dc:creator>Sam</dc:creator>
            <category>php-internals</category>
            <pubDate>Sun, 18 Mar 2012 01:10:02 +0100</pubDate>
        </item>
        <item>
            <guid>http://www.serverphorums.com/read.php?7,462383,464196#msg-464196</guid>
            <title>Re: [PHP-DEV] Randomize hash-function in php</title>
            <link>http://www.serverphorums.com/read.php?7,462383,464196#msg-464196</link>
            <description><![CDATA[ Hi!<br />
<br />
&gt; I don't know much about hash-maps and internal php-stuff at all, but<br />
&gt; they say that the fix provided in 5.3.9 (and 5.4.0) is more a<br />
&gt; work-around than a fix ...<br />
<br />
This is true, it is a workaround in a meaning that the hash stays the <br />
same, but the fix prevents one from using excessive amounts of data that <br />
makes the hash unusable.<br />
<br />
&gt; Would it be an option to provide a real fix in PHP 6.0? They got the<br />
<br />
Definitely. However doing this has some challenges. We're working on it.<br />
-- <br />
Stanislav Malyshev, Software Architect<br />
SugarCRM: <a href="http://www.sugarcrm.com/" target="_blank"  rel="nofollow">http://www.sugarcrm.com/</a><br />
(408)454-6900 ext. 227<br />
<br />
-- <br />
PHP Internals - PHP Runtime Development Mailing List<br />
To unsubscribe, visit: <a href="http://www.php.net/unsub.php" target="_blank"  rel="nofollow">http://www.php.net/unsub.php</a>]]></description>
            <dc:creator>Stas Malyshev</dc:creator>
            <category>php-internals</category>
            <pubDate>Sun, 18 Mar 2012 00:50:01 +0100</pubDate>
        </item>
        <item>
            <guid>http://www.serverphorums.com/read.php?7,462383,464194#msg-464194</guid>
            <title>[PHP-DEV] Randomize hash-function in php</title>
            <link>http://www.serverphorums.com/read.php?7,462383,464194#msg-464194</link>
            <description><![CDATA[ Hi, All<br />
<br />
I just came around that talk a couple of days ago ..<br />
<a href="http://www.youtube.com/watch?v=R2Cq3CLI6H8" target="_blank"  rel="nofollow">http://www.youtube.com/watch?v=R2Cq3CLI6H8</a><br />
<br />
I don't know much about hash-maps and internal php-stuff at all, but<br />
they say that the fix provided in 5.3.9 (and 5.4.0) is more a<br />
work-around than a fix ...<br />
Would it be an option to provide a real fix in PHP 6.0? They got the<br />
feedback that this will take some time and is not trivial, but we have<br />
a good time before PHP6 and can also break backwards compatibility for<br />
php-plugins if really necessary.<br />
<br />
As they said in the movie, PHP seems to have the algorithm DJBX33A<br />
implemented as Ruby. So as they're so proud of the fix provided by the<br />
Ruby-Team, may we can use that for PHP as well :)<br />
<a href="https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2011-4815" target="_blank"  rel="nofollow">https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2011-4815</a><br />
<br />
This is not much because some attacker can do something, but what if<br />
you have a real-world-application that (for some reason) build up an<br />
array that just will blow up because of that? I haven't experienced<br />
that until now, but it's possible ...<br />
<br />
Bye<br />
Simon<br />
<br />
-- <br />
PHP Internals - PHP Runtime Development Mailing List<br />
To unsubscribe, visit: <a href="http://www.php.net/unsub.php" target="_blank"  rel="nofollow">http://www.php.net/unsub.php</a>]]></description>
            <dc:creator>Simon Schick</dc:creator>
            <category>php-internals</category>
            <pubDate>Sun, 18 Mar 2012 00:20:01 +0100</pubDate>
        </item>
        <item>
            <guid>http://www.serverphorums.com/read.php?7,462383,462383#msg-462383</guid>
            <title>[PHP-DEV] Randomize hash-function in php</title>
            <link>http://www.serverphorums.com/read.php?7,462383,462383#msg-462383</link>
            <description><![CDATA[ Hi, All<br />
<br />
I just came around that talk a couple of days ago ..<br />
<a href="http://www.youtube.com/watch?v=R2Cq3CLI6H8" target="_blank"  rel="nofollow">http://www.youtube.com/watch?v=R2Cq3CLI6H8</a><br />
<br />
I don't know much about hash-maps and internal php-stuff at all, but they<br />
say that the fix provided in 5.3.9 (and 5.4.0) is more a work-around than a<br />
fix ...<br />
Would it be an option to provide a real fix in PHP 6.0? They got the<br />
feedback that this will take some time and is not trivial, but we have a<br />
good time before PHP6 and can also break backwards compatibility for<br />
php-plugins if really necessary.<br />
<br />
As they said in the movie, PHP seems to have the algorithm DJBX33A<br />
implemented as Ruby. So as they're so proud of the fix provided by the<br />
Ruby-Team, may we can use that for PHP as well :)<br />
<a href="https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2011-4815" target="_blank"  rel="nofollow">https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2011-4815</a><br />
<br />
This is not much because some attacker can do something, but what if you<br />
have a real-world-application that (for some reason) build up an array that<br />
just will blow up because of that? I haven't experienced that until now,<br />
but it's possible ...<br />
<br />
Bye<br />
Simon]]></description>
            <dc:creator>Simon Schick</dc:creator>
            <category>php-internals</category>
            <pubDate>Wed, 14 Mar 2012 21:30:02 +0100</pubDate>
        </item>
    </channel>
</rss>
