Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124439
Message-ID: <7322787a-2c35-4926-baae-84cf46a6acea@bastelstu.be>
Date: Mon, 15 Jul 2024 23:29:42 +0200
Precedence: bulk
MIME-Version: 1.0
Subject: Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4
To: Rob Landers <rob@bottled.codes>, "Gina P. Banyard" <internals@gpb.moe>,
 Juliette Reinders Folmer <php-internals_nospam@adviesenzo.nl>
Cc: internals@lists.php.net
References: <bw20I5b7ly3lSbI-2Bv3kfrfTVJbDo5RhwBiQa1PEwuLjprDJWptPajLiaialj1RLVKu7z1j0MofJUhhRVtzT_5i2E11oKeQx_VMUxnKhUE=@gpb.moe>
 <6683CDE4.7050607@adviesenzo.nl>
 <Skh-IB3l7OxslclNZdB5ZE3G5PaIvpoz3iojK10noNbXkj1odNNvzI5w7X1aSj7IKZ951646yQ8IrUW_wNaQuv94NB0jo3IXlFImcpu_hxc=@gpb.moe>
 <668B5728.40300@adviesenzo.nl>
 <3XlxyoEWXN5MLqWhlh4uQMXGc2DRs7OH72f_InABxrhsBVTZIPOrfO3qEKqG94844M2r3FUS_zGMa60dENgvLP6TC8zOWZASkN6w6ZxsaxM=@gpb.moe>
 <af9e728a-5961-4f90-85f9-f03b397fe837@app.fastmail.com>
Content-Language: en-US
In-Reply-To: <af9e728a-5961-4f90-85f9-f03b397fe837@app.fastmail.com>
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/15/24 16:12, Rob Landers wrote:
> This always gets me. "safer" doesn't have a consistent meaning. For

Yes it does. SHA-256 is safer than MD5. And on modern CPUs with sha_ni 
extensions, it's also faster. The following is on a Intel i7-1365U:

> $ openssl speed md5 sha1 sha256 sha512
> *snip*
> version: 3.0.10
> built on: Wed Feb 21 10:45:39 2024 UTC
> options: bn(64,64)
> compiler: *snip*
> CPUINFO: OPENSSL_ia32cap=0x7ffaf3ffffebffff:0x98c027bc239c27eb
> The 'numbers' are in 1000s of bytes per second processed.
> type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
> md5             114683.10k   286174.51k   550288.90k   715171.50k   783611.22k   788556.46k
> sha1            138578.57k   440607.38k  1082163.29k  1674088.45k  2017296.38k  2047377.41k
> sha256          150670.11k   460483.71k  1054829.57k  1553830.57k  1807897.94k  1823981.57k
> sha512           41246.76k   181566.07k   341457.66k   645468.50k   781042.81k   804296.02k

----

> example, if you were to want to create a "content addressable
> address" using a hash and it needs to fit inside a 128 bit number
> (such as a GUID), you may be tempted to take SHA-X and just truncate
> it. However, this biases the resulting numbers, which this bias may

This is false. For a hash algorithm to be considered cryptographically 
secure (which I consider to be a reasonable definition of "safe"), it - 
among other properties - needs to have the "avalanche effect" property, 
which means that any change in the input is going to affect each output 
bit with 50% probability.

This means that for a cryptographic hash algorithm - such as the SHA-2 
family - the resulting hash is indistinguishable from uniformly selected 
random bits. And this property also holds after truncation - you just 
have fewer bits of course.

See also: https://security.stackexchange.com/a/34797/21705

> be considered unsafe (such as using it in an A/B testing tool). Just
> because you have a short hash, doesn't make it "unsafe" as longer
> hashes can also be considered "unsafe." What people usually mean by
> this is in the context of encryption, and in those cases it is
> unsafe, but in the context of non-encryption, usage of truncated
> larger hashes is just as unsafe.
> 

I'm afraid I don't understand what you are attempting to say here.

Best regards
Tim Düsterhus