Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124694
Message-ID: <31ef5c07-b472-431b-9214-f4a9c23080d4@bastelstu.be>
Date: Tue, 30 Jul 2024 22:57:58 +0200
Precedence: bulk
MIME-Version: 1.0
Subject: Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4
To: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>, internals@lists.php.net
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>
 <3563cf9b-8eab-4c82-b525-a5d2f9a767bb@varteg.nz>
 <38920A4B-790D-48C7-B2F6-C49D3F506232@rwec.co.uk>
 <0824789d-0e36-4628-85c1-4b8d9b7f86af@varteg.nz>
 <F791876D-1A33-4DB7-938A-DEC048493D87@rwec.co.uk>
Content-Language: en-US
In-Reply-To: <F791876D-1A33-4DB7-938A-DEC048493D87@rwec.co.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

Hi

On 7/28/24 08:42, Rowan Tommins [IMSoP] wrote:
>> Why a SHA2 algorithm? Why not a SHA3 one? How about standalone functions for both, and then when SHA4 comes along (as it inevitably will) another standalone function for one of its variants?
> 
> You tell me. As I have repeatedly said, I don't actually know anything about these algorithms. SHA-256 is the only one on the list which I've heard of, and I'm aware it's newer than SHA-1. I don't know why SHA-512 isn't "better", I don't know why nobody talks about SHA-3, and I don't know if one of the others in the list is absolutely amazing and should be everyone's default forever.
> 
> As far as I can see, nobody, in this whole discussion, has actually stepped up and explained what users should be using, once we have taught them that MD5 and SHA-1 are bad.

Let me attempt to give an explanation. As of today users should use in 
order of priority:

1. The hash function they need for interoperability: If a service 
provides a SHA-1 checksum, then there is no choice and SHA-1 needs to be 
used.
2. The hash function their security team requests them to use.
3. A function from the SHA-2 family, with SHA-256 being a good default 
choice, because that's the secure default choice across the industry.

See also: https://news.ycombinator.com/item?id=14469614 and specifically 
https://news.ycombinator.com/item?id=14469730 ("there are hash 
cryptographers who think SHA-2 may never be broken").

To expand on (3):

- SHA-256 and SHA-224 are literally the same, except for the initial 
values and the fact that SHA-224 returns fewer bits.
- SHA-512, SHA-384, SHA-512/224 and SHA-512/256 are literally the same, 
except for the initial values and the fact that the latter 3 return 
fewer bits.
- The main structure of SHA-512 and SHA-256 is the same, SHA-512 just 
uses 64-bit operations and larger chunks. Wikipedia explains this in 
detail: https://en.wikipedia.org/wiki/SHA-2#Pseudocode
- SHA-512 and its variants are faster than SHA-256 and its variants, the 
reason is that SHA-256 is restricted to 32-bit operations. But: See below.
- The truncated variants are immune to so-called length-extension 
attacks, but using a HMAC protects against that and thus is the 
recommended usage.

As for the speed difference, I've created a (pending) PR to improve the 
speed of SHA-256 2x to 5x (depending on the input length), by leveraging 
the SHA-NI instruction set when available. When it's not available, the 
SSE2 implementation improves the speed by 1.3x:

https://github.com/php/php-src/pull/15152

(Credit where credit is due: The implementation was written by Dr. Colin 
Percival, I just did the PHP integration).

>> Or leave them them the 60-piece set (which includes flat-head and Phillips screwdrivers, so they're not being taken away), and write some tips on how to use it correctly.
> 
> So go ahead and write those tips. You don't need an RFC vote to improve the documentation.
> 
> 
> Here is my offer to those arguing in favour of this deprecation: If you show me a draft of a comprehensive improvement to the manual to explain how users should be choosing a hashing algorithm, I will consider changing my vote.
> 
> I am also happy to help with proofreading, and working out how to format it into DocBook that fits nicely in the manual.
> 
> As long as the deprecation rests on "somebody in the next 10 years might get round to improving the manual", my vote remains a firm No.
> 

I'm seeing that you already found the issue discussing improvements to 
the documentation, but for reference for readers following along:

https://github.com/php/doc-en/issues/3616

Please also see my previous email regarding the docs improvements I've 
already made: The examples for the hash() functions should now all use 
sha256 (matching the explanation above), please point out if I missed any.

Best regards
Tim Düsterhus

PS: I know that life can get in the way, but as it fits the topic of 
your last paragraph I'd like to note that I don't believe you followed 
up regarding the documentation feedback back when the PHP 8.3 
deprecation RFC (https://externals.io/message/120422#120601) happened.