Hi On 7/28/24 14:24, Kamil Tekiela wrote:
I have voted yes only because I thought it's about removing inconsistent function alias. I can't see anything wrong with this hashing algorithms and I don't consider them unsafe. However, as someone pointed out this doesn't seem to be correct as the crc32 function isn't part of the depreciation proposal. I am confused now as to why we are trying to deprecate these
crc32() is different, because the hash() function is not a direct drop-in replacement. The crc32() function returns an integer, whereas the hash() function returns raw bytes / hex encoded bytes (as with all hash functions it provides). Unfortunately one also needs to remember to use the 'crc32b' algorithm value, because 'crc32' is taken up by the bit-reversed bzip2 variant of CRC32. The 'crc32b' naming is something PHP-specific and non-standard :-/
The standalone crc32() could probably also be deprecated, given the big red warning in documentation. But it's sufficiently different from the standalone md5() and sha1() functions to not bundle it with them.
functions at all. If it's about people confusing the hashing algorithms with password key stretching algorithms then that's not a valid reason. A red warning in the documentation should aid people in clearing this confusion.
No, it's about MD5 and SHA-1 being a bad choice nowadays and nevertheless being more prominently available than the alternatives.
Best regards Tim Düsterhus
