Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:61075
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.49 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAESVnVr1gkB03m5Kuiez=47EKXP7cSoXCcjxjj8zasbcQLpeSg@mail.gmail.com>
References: <CAAyV7nGNb6A70JFxfWYJs6FCKzUgmqzA86JBXm7Ug47nLZGySg@mail.gmail.com>
	<CAESVnVr1gkB03m5Kuiez=47EKXP7cSoXCcjxjj8zasbcQLpeSg@mail.gmail.com>
Date: Mon, 2 Jul 2012 20:49:03 -0400
Message-ID: <CAAyV7nHtHQKPgK221VsCg310tUVX9UurmV6NpT3P9U2UVE-Mqw@mail.gmail.com>
To: Sara Golemon <pollita@php.net>
Cc: internals@lists.php.net
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [VOTE] Hash_pbkdf2
From: ircmaxell@gmail.com (Anthony Ferrara)

Sara,

On Mon, Jul 2, 2012 at 8:24 PM, Sara Golemon <pollita@php.net> wrote:
> I'd like to see hash_init() support this mode as well (for completeness).
> =A0Perhaps something like the following:
>
> $ctx =3D hash_init("sha512", HASH_PBKDF2, $salt,=A0array('length' =3D> 32=
,
> 'iterations' =3D> 5000));
>
> The new fourth parameter being an overloadable options generic so that we
> don't have an endless list of parameters for all the possible hashing typ=
es.

The only problem that I have with this sort of implementation is that
the only way it would work is to buffer the entire input (each
hash_update call), and run it all at the end. That's because the data
(password) is used in every iteration, so there's no pre-computation
that can be done. And at that point, what's the benefit to it?

public function pbkdf2($algo, $password, $salt, $iterations, $length) {
        $size   =3D getHashBlockSize($hash);
        $len    =3D ceil($length / $size);
        $result =3D '';
        for ($i =3D 1; $i <=3D $len; $i++) {
            $tmp =3D hash_hmac($hash, $salt . pack('N', $i), $password, tru=
e);
            $res =3D $tmp;
            for ($j =3D 1; $j < $iterations; $j++) {
                $tmp  =3D hash_hmac($hash, $tmp, $password, true);
                $res ^=3D $tmp;
            }
            $result .=3D $res;
        }
        return substr($result, 0, $length);
    }

Contrast that to a normal hash function (used by the current
hash_init) which iterates over blocks of input, and once it's done
with a block, it doesn't need it anymore (which is where using
something like hash_init/hash_update can make sense on large input).

Additionally, hmac only uses the message in a single hash, so it can
be streamed in as well (pre-compute the earlier hashes/data, stream
the intermediate hash, then hash the final one).

So while it could be added (just make hash_update buffer into a
context, then have hash_final actually run the derivation), I'm not
sure it makes sense to add it there.

Thoughts?

Anthony