Bug #74961 [Opn]: "Disallow non-crypto hashes in HMAC and PBKDF2" implemented poorly

Edit report at https://bugs.php.net/bug.php?id=74961&edit=1 ID: 74961 Updated by: nikic@php.net 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: There are two reasons why this was moved into the hash structure, rather than having a secondary structure: * To make sure that there is a "single source of truth" regarding hash function metadata. This makes it impossible to forget to specify whether or not the function is cryptographic when a new hash is added. * To avoid double-lookups. It's not good to scan through lists multiple times, especially if it involves case-insensitive string comparisons. I've recently done a similar change in mbstring (https://github.com/php/php-src/commit/633a471ba0c9acc6d1cca04880c1e69e7b2dc18e), because it turned out that scanning those lists was dominating the runtime of some functions. Previous Comments: ------------------------------------------------------------------------ [2017-08-10 03:42:49] bluebaroncanada at gmail dot com 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. ------------------------------------------------------------------------ [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... ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=74961 -- Edit this bug report at https://bugs.php.net/bug.php?id=74961&edit=1