On Thu, 2024-07-25 at 22:34 +0100, Rowan Tommins [IMSoP] wrote:
> 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,
>
That's a good point. What if there were crypto functions that worked
like password_hash() in that they had one generic function name, but
magically used the new/better "best practice" algorithms as time went
by without the need to update any calling code?
Maybe there should be three generic-named functions:
fast_hash() // not secure, makes UIDs quickly
secure_hash() // uses best practice one-way hash algo
secure_crypt() // uses best practice reversible encryption.
Then the developer signals their *intent* by choosing a function name,
and the algorithm magically works underneath (perhaps with the option
of an ini override to make those functions work in different
environments).
