Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124594
Message-ID: <9041cba85d6439682bb44fcb29210c944dbe3911.camel@ageofdream.com>
Subject: Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4
To: internals@lists.php.net
Date: Thu, 25 Jul 2024 18:00:51 -0400
In-Reply-To: <aa6bc7aa-28d9-40ca-974f-65075adb6199@rwec.co.uk>
References: 
	<USzt7tZZlO1DmAbSTLhD-bqa23FqZn0zk2aah8Ndxgk9c7RY5PefQ8MjbYPUYAzr2_m4Cf-5AI4PuNBTS84rim_FNS6RaT-cWSv714HEvvU=@gpb.moe>
	 <1a88918e-e808-d778-45e1-53797660e093@php.net>
	 <CAPrKfG5Cw_nU7g7FR+t4C1-YZ8CDsDO_-sRs=yEsHO5kCTZL+A@mail.gmail.com>
	 <c03eb187-bd21-4a4b-9faf-8d0243eaa994@varteg.nz>
	 <aa6bc7aa-28d9-40ca-974f-65075adb6199@rwec.co.uk>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.46.4-2 
Precedence: bulk
MIME-Version: 1.0
From: lists@ageofdream.com (Nick Lockheart)

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=20
> > only reason they're called out as their own distinct functions
> > today=20
> > is historical inertia.=20
>=20
>=20
> I don't agree that the reasons for including standalone functions are
> "historical". The RFC itself gives a good reason for having such
> functions:
>=20
> =C2=A0> Unfortunately these cryptographically secure hash functions are
> only=20
> available by means of the generic hash() function ... making using
> them=20
> more verbose and thus seemingly more complicated
>=20
>=20
> Rather than force people to use functions that we acknowledge are
> hard=20
> to use, surely the logical thing is to make the "right" code *easy*
> to use?
>=20
> Which means if we want people to use SHA-256, let's add a sha256()=20
> function to make it easy.
>=20
>=20
> This is what password_hash() and password_verify() did right: the=20
> functionality was already there in crypt(), but it's hard to use, and
> harder to use correctly. Providing clearer functions, even though
> they=20
> do the same thing, helps new developers "fall into the pit of
> success".
>=20
> The hash() function isn't quite as confusing as crypt(), but
> according=20
> 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=20
> "sha1", but should I be aiming higher, and using "sha384", or maybe
> one=20
> of the four flavours of "sha3"? Then there's the fun-sounding=20
> "whirlpool", the faintly rude-sounding "snefru", and a bewildering=20
> fifteen flavours of "haval".
>=20
> A new user being told "don't use sha1(), use hash() and pick from
> this=20
> list" is more likely to say "ah, there's=C2=A0sha1, jolly good" than spen=
d
> an=20
> afternoon reading cryptography journals. There's no pit of success to
> fall into.
>=20
>=20
> Regards,
>=20

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).