On 24/07/2024 23:01, Morgan wrote:
And they would still be available as hash("md5") and hash("sha1"); the only reason they're called out as their own distinct functions today is historical inertia.
I don't agree that the reasons for including standalone functions are "historical". The RFC itself gives a good reason for having such functions:
> Unfortunately these cryptographically secure hash functions are only available by means of the generic hash() function ... making using them more verbose and thus seemingly more complicated
Rather than force people to use functions that we acknowledge are hard to use, surely the logical thing is to make the "right" code *easy* to use?
Which means if we want people to use SHA-256, let's add a sha256() function to make it easy.
This is what password_hash() and password_verify() did right: the functionality was already there in crypt(), but it's hard to use, and harder to use correctly. Providing clearer functions, even though they do the same thing, helps new developers "fall into the pit of success".
The hash() function isn't quite as confusing as crypt(), but according to the manual, it currently supports 60 different algorithms, most of which I have never heard of. I'm aware that "sha256" is better than "sha1", but should I be aiming higher, and using "sha384", or maybe one of the four flavours of "sha3"? Then there's the fun-sounding "whirlpool", the faintly rude-sounding "snefru", and a bewildering fifteen flavours of "haval".
A new user being told "don't use sha1(), use hash() and pick from this list" is more likely to say "ah, there's sha1, jolly good" than spend an afternoon reading cryptography journals. There's no pit of success to fall into.
Regards, -- Rowan Tommins [IMSoP]
