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_pbkdf2The 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/f4847efIt 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 since
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 only
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.
Nikita
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_pbkdf2The 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/f4847efIt 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 since
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 only
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 — 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
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_pbkdf2The 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/f4847efIt 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 since
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 only
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 —
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
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.
It's not a very good example, I admit, but my point is that it's not
as though they're actually the same code underneath.
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.
I think that horse bolted about a decade ago. Assuming the OpenSSL
version does actually work properly, I don't see why it's an issue.
Adam