Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:67465
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.219.47 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CADajX4CskTALYnO=x4LQS_oy7mAyNUKL3_Lg7_8LLKmyiZkEnw@mail.gmail.com>
References: <CAF+90c-6yGbQwi0LfAAer5wqgN=7j1N+h6BYBDWNh0x8a8=v+A@mail.gmail.com>
	<CADajX4CskTALYnO=x4LQS_oy7mAyNUKL3_Lg7_8LLKmyiZkEnw@mail.gmail.com>
Date: Thu, 23 May 2013 23:11:05 +0200
Message-ID: <CAF+90c9D1PyFfEzggA9e0o5M0sfk7naoRLy0_+f1sS9E56gr0g@mail.gmail.com>
To: Adam Harvey <aharvey@php.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b2e4b5eda685a04dd691e69
Subject: Re: [PHP-DEV] Re: hash_pbkdf2 vs openssl_pbkdf2
From: nikita.ppv@gmail.com (Nikita Popov)

--047d7b2e4b5eda685a04dd691e69
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Thu, May 23, 2013 at 10:39 PM, Adam Harvey <aharvey@php.net> wrote:

> On 23 May 2013 13:31, Nikita Popov <nikita.ppv@gmail.com> wrote:
> > On Sat, May 18, 2013 at 11:48 AM, Nikita Popov <nikita.ppv@gmail.com>
> wrote:
> >
> >> Hi internals!
> >>
> >> I just noticed that we added the PBKDF2 algorithm two times in PHP 5.5=
.
> >> Once in the hash extension, once in the OpenSSL extension.
> >>
> >> The hash_pbkdf2 function was added via this RFC:
> >> https://wiki.php.net/rfc/hash_pbkdf2
> >>
> >> The openssl_pbkdf2 function probably was not noticed at that time
> because
> >> it was just commited, but not mentioned anywhere else (NEWS, UPGRADING=
,
> >> etc). Only saw it in vrana's documentation updates just now. The
> relevant
> >> commit is here: https://github.com/php/php-src/commit/f4847ef
> >>
> >> It would be nice if we could have only one of those functions. I'm
> >> currently tending towards the hash_ variant because of the commit
> message
> >> of the openssl_ function:
> >>
> >> > No easy way to put these in the hash extension since we don't really
> >> support optional
> >> > parameters to certain algorithms. Implemented in openssl for now sin=
ce
> >> it has it already
> >> > and is pretty stable.
> >> >
> >> > Only SHA1 is confirmed to work as an algorithm but openssl has a
> >> parameter so it can be
> >> > changed in the future.
> >>
> >> It seems that the author already would have preferred it in the hash
> >> extension and that the openssl variant only works with sha1 (or was on=
ly
> >> tested with it? not sure).
> >>
> >> Nikita
> >>
> >
> > No more opinions? It would be nice to have this resolved before 5.5,
> > otherwise there will be no way back.
>
> I'm not really convinced this is a problem in practice =97 hash_pbkdf2()
> is likely to be the commonly used one because it doesn't have the
> OpenSSL dependency, but it probably doesn't hurt to have the ability
> to also call OpenSSL's independent implementation (say, if a bug is
> found in one or the other).
>
> Adam
>

If a bug is found we fix it. Proving several implementations of the same
thing to account for potential bugs isn't a good idea imho.

If two functions for the same thing exist people need to wonder about which
one of them should be used, and in the worst case decide to use a pattern
like "if function1 exists call function1, if function2 exists call
function2, etc". Just like nowadays to generate a random string you usually
check something like four of five different functions. I think it's
preferable to have one and only one function in a default-enabled extension=
.

Nikita

--047d7b2e4b5eda685a04dd691e69--