Edit report at https://bugs.php.net/bug.php?id=74961&edit=1
ID: 74961
Comment by: bluebaroncanada at gmail dot com
Reported by: bluebaroncanada at gmail dot com
Summary: "Disallow non-crypto hashes in HMAC and PBKDF2"
implemented poorly
Status: Open
Type: Bug
Package: *Encryption and hash functions
PHP Version: 7.2.0beta1
Block user comment: N
Private report: N
New Comment:
The more we add things like this, too, the heavier the code gets. The more we have to remember to
implement new stuff. The more cumbersome and time consuming it is. I think, just generally, we
should have high prejudice against things like that.
Previous Comments:
------------------------------------------------------------------------
[2017-08-10 03:40:16] bluebaroncanada at gmail dot com
TBH, I really don't care in the end. All I'm saying is that now there's the
potential for more problems.
"abchash doesn't implement is_crypto = true"
"xyzhash doesn't implement is_crypto = false"
"Oh. My bad. I put it in the function that lists all available functions. I'll add
that."
"Oh. Should I check both places? Why do we have two places?"
"We just invented this new class of hashing functions. Should it have is_crypto?
Hmm. Well maybe yes, maybe no. It doesn't really fit that paradigm."
Not to mention it's simply extraneous if there's going to be a lookup function and
is_crypto. It's a make-work addition.
------------------------------------------------------------------------
[2017-08-10 03:23:55] pollita@php.net
I'm confused why you care how the flag (flag mind you, not function) is implemented. Why does
it matter that the algo has a bit set on its definition rather than having a completely separate
lookup table? The way it looks from userspace is the same.
------------------------------------------------------------------------
[2017-07-27 19:07:20] bluebaroncanada at gmail dot com
The rest of the request is to undo some of these changes that are cumbersome, difficult to maintain,
and hard to research to build new code on top. It's certainly unnecessary and highly-coupled
to put is_crypto functions that are only used once inside the hash functions. That's just an
extra layer of coupling for no reason. It's going to make it more likely to have a bug.
Instead, let's have a canonical function that tells all that both the user and the developer
can rely on.
------------------------------------------------------------------------
[2017-07-23 18:39:24] pollita@php.net
I'm a little unclear on what you're looking for when you say "rewritten".
I see the request for hash_algos_hmac() which is entirely reasonable (or a variant thereof), but
I'm not sure what the rest of the request is...
------------------------------------------------------------------------
[2017-07-21 09:10:08] bluebaroncanada at gmail dot com
Description:
------------
Commit https://github.com/php/php-src/commit/d89d149edf39cf4ce9ab41979f246e82510d43a5#commitcomment-23109176
is a poor implementation of its goal.
It salted the code and added a new is_crypto function which wasn't necessary and is also
insufficient.
It should provide a new hash_algos_hmac to extend http://php.net/manual/en/function.hash-algos.php
The documentation now says "Returns FALSE when algo is unknown." and 7.2.0 Usage of
non-cryptographic hash functions (adler32, crc32, crc32b, fnv132, fnv1a32, fnv164, fnv1a64, joaat)
was disabled. However it does not say that it will return false only when providing one of these
non-cryptographic functions, which is what it actually does. There could be future deprecation of
more functions.
I suggest that either the is_crypto function is extended to the users, but better than that, we
should remove the is_crypto function and create the hash_algos_hmac to extend the hash_algos
function for the same reason its predecessor exits and also so that we can use that function
internally to decide if the hashing algorithm should be available and thus easily allow future
deprecation and pedantic decisions on available algorithms without further damaging the code.
The reason that this bothers me so is that phpseclib extends this functionality and it cannot
properly test with this implementation or properly extend this functionality to pass on to its
users. In the future, if there is further deprecation, users would be treated with an undetectable
error.
This commit should be removed and rewritten.
Test script:
---------------
if (!hash_hmac('crc32', 'The quick brown fox jumped over the lazy dog.',
'secret'))
die('run for your lives');
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=74961&edit=1