Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:124442 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by qa.php.net (Postfix) with ESMTPS id B54EC1A00B7 for ; Mon, 15 Jul 2024 23:09:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1721085079; bh=MVd9tLrc8nKXIyylVJ9Z63jz+Rnyr32LCiUqbDkFUfU=; h=In-Reply-To:References:Date:From:To:Cc:Subject:From; b=Pm9XcQXiGz6QvZ36cInTHa1gUARk1ylvcrWWvS88eYrkkiqYsvn9EHjlG9sKIpC1+ WuF4jrWomeEFIY56cves2xH0Q3QHI0VCExK1dzxmNCEs9MQyyNuXmq9KGwm4XXZA4a fs3ErIEAmzYnx7I8Tu7CpfBtcHxFes5JO+KJLKUYbfRn8qHkoxTt879eDThPpcRFdE DXHpk+ifTNDrvPugMzdmEtVlcdWbvblob6zSK+9YugdDm0dYNt3eZn7veSVtaDeyCv HUQ199Sn8s4I0I/KG5hiDxcwIIbI2am2OW6dhghhTTXHz+VTEc033bV8NJD7nWg7Uj Ay9Hep0MnSjTg== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 9972B18007A for ; Mon, 15 Jul 2024 23:11:18 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-0.1 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_MISSING,HTML_MESSAGE, RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: No X-Envelope-From: Received: from fhigh4-smtp.messagingengine.com (fhigh4-smtp.messagingengine.com [103.168.172.155]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Mon, 15 Jul 2024 23:11:17 +0000 (UTC) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailfhigh.nyi.internal (Postfix) with ESMTP id 353DD1147EC0; Mon, 15 Jul 2024 19:09:48 -0400 (EDT) Received: from imap49 ([10.202.2.99]) by compute1.internal (MEProxy); Mon, 15 Jul 2024 19:09:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bottled.codes; h=cc:cc:content-type:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to; s=fm3; t=1721084988; x= 1721171388; bh=w9xI4nSrs1MIzGNPC6h3UJ2RzwNjaXk47+jy3i6B1GE=; b=n 58yDlsrWnPdhsvcIFQ8rUYS/2abYf6Mzvs0QsSCB6qw9mmEPJSyoHZV2/lydt0k+ U/7xnDm8RK9lWfhCO3pMQR6CGNxQMuEzQuNCedlPkItkqrxe2LIQ2dm2Fd8So9XK atLk8zYdquJ6genFpXkcJ0cxmx06fmwI4MQy7MQeIm6rclzz8JxwWo0q3m9HMLd5 xaBtchVIlPuzL4HDeXHKbtyLQyUVBAK8QqHnhmCNNd2LPrBjtVbuhkEBTxTLYBj7 xPdwKeDclsZB7MvA5WwQHdXDHPVUKR1r7tQ7/4EEuOOXioZMW+AOKsq9P4oVzi07 Ee6mDXdhtpq7Ti3MAvAug== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1721084988; x=1721171388; bh=w9xI4nSrs1MIzGNPC6h3UJ2RzwNj aXk47+jy3i6B1GE=; b=Zdmd3vvyznuOcHW0k36lqzDPcbY+l4418371QAj1vS8I cHpOUmF5sqzgdjGcipFpeJUF5C2U0s0NXPQkFhMwiXitjVXNE6DnWQQdBTFvkDVX 1b4pCPuengyR4EOu6p6FF01dcHE5Rd1Rc5haF9XKpaHRN5w5+NFYOp6H7wV4nL1B w95q+Xj6+xeIDE3dgKUOhMlOcunmb3z4JKAhqBa5zlZwwLf47Pg7B868bY37Qq0z 9vFkLYMUp3w28CjmB0/gLsvpL5kUb7LXBQ7Vy0N0QuBpCLJdzifBXVdyeLlUzmAK vHbuQEuTIw/3J0JyHESx3+Kud5YfT+ImXxtKPZzCFQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrgeefgddukecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvfevufgtsegrtd erreerreejnecuhfhrohhmpedftfhosgcunfgrnhguvghrshdfuceorhhosgessghothht lhgvugdrtghouggvsheqnecuggftrfgrthhtvghrnhepleejtedttdegtdelhfeltedvie dtudekueekveefudekleelleehffejveeuteffnecuffhomhgrihhnpehsthgrtghkvgig tghhrghnghgvrdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomheprhhosgessghothhtlhgvugdrtghouggvsh X-ME-Proxy: Feedback-ID: ifab94697:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 56BED15A0092; Mon, 15 Jul 2024 19:09:46 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.11.0-alpha0-568-g843fbadbe-fm-20240701.003-g843fbadb Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net MIME-Version: 1.0 Message-ID: <5a232cee-00fe-43ec-8e3f-1953a302692e@app.fastmail.com> In-Reply-To: <7322787a-2c35-4926-baae-84cf46a6acea@bastelstu.be> References: <6683CDE4.7050607@adviesenzo.nl> <668B5728.40300@adviesenzo.nl> <3XlxyoEWXN5MLqWhlh4uQMXGc2DRs7OH72f_InABxrhsBVTZIPOrfO3qEKqG94844M2r3FUS_zGMa60dENgvLP6TC8zOWZASkN6w6ZxsaxM=@gpb.moe> <7322787a-2c35-4926-baae-84cf46a6acea@bastelstu.be> Date: Tue, 16 Jul 2024 01:08:39 +0200 To: =?UTF-8?Q?Tim_D=C3=BCsterhus?= , "Gina P. Banyard" , "Juliette Reinders Folmer" Cc: internals@lists.php.net Subject: Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4 Content-Type: multipart/alternative; boundary=476d064325c64f14b3d6866f7c981817 From: rob@bottled.codes ("Rob Landers") --476d064325c64f14b3d6866f7c981817 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Mon, Jul 15, 2024, at 23:29, Tim D=C3=BCsterhus wrote: > Hi >=20 > On 7/15/24 16:12, Rob Landers wrote: > > This always gets me. "safer" doesn't have a consistent meaning. For >=20 > Yes it does. SHA-256 is safer than MD5. And on modern CPUs with sha_ni=20 > extensions, it's also faster. The following is on a Intel i7-1365U: >=20 > > $ 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=3D0x7ffaf3ffffebffff:0x98c027bc239c27eb > > The 'numbers' are in 1000s of bytes per second processed. > > type 16 bytes 64 bytes 256 bytes 1024 bytes 8= 192 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 2= 017296.38k 2047377.41k > > sha256 150670.11k 460483.71k 1054829.57k 1553830.57k 1= 807897.94k 1823981.57k > > sha512 41246.76k 181566.07k 341457.66k 645468.50k = 781042.81k 804296.02k >=20 > ---- >=20 > > 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 >=20 > This is false. For a hash algorithm to be considered cryptographically=20 > secure (which I consider to be a reasonable definition of "safe"), it = -=20 > among other properties - needs to have the "avalanche effect" property= ,=20 > which means that any change in the input is going to affect each outpu= t=20 > bit with 50% probability. from a practical perspective across hundreds of millions of hashes of un= ique ids, I can say that there is a practical and detectable bias when t= runcating sha-256 hashes. Enough that we were having to throw out a/b te= st results=E2=80=A6 I=E2=80=99m not going to write a paper on it and I=E2= =80=99m not going to bother arguing the point that no hash function is p= erfect, but I will point out that =E2=80=9Ctheory=E2=80=9D and =E2=80=9C= reality=E2=80=9D don=E2=80=99t always agree.=20 >=20 > This means that for a cryptographic hash algorithm - such as the SHA-2=20 > family - the resulting hash is indistinguishable from uniformly select= ed=20 > random bits. And this property also holds after truncation - you just=20 > have fewer bits of course. >=20 > See also: https://security.stackexchange.com/a/34797/21705 >=20 > > 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. > >=20 >=20 > I'm afraid I don't understand what you are attempting to say here. >=20 > Best regards > Tim D=C3=BCsterhus >=20 =E2=80=94 Rob --476d064325c64f14b3d6866f7c981817 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable

=
On Mon, Jul 15, 2024, at 23:29, Tim D=C3=BCsterhus wrote:=
Hi

On 7/15/24 16:12, Rob Landers wrote:
> This always gets me. "safer" doesn't have a consistent meaning. Fo= r

Yes it does. SHA-256 is safer than MD5. A= nd 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=3D0x= 7ffaf3ffffebffff:0x98c027bc239c27eb
> The 'numbers' are= in 1000s of bytes per second processed.
> type &n= bsp;           16 byte= s     64 bytes    256 bytes &nbs= p; 1024 bytes   8192 bytes  16384 bytes
>= ; md5           &= nbsp; 114683.10k   286174.51k   550288.90k &nbs= p; 715171.50k   783611.22k   788556.46k
> sha1          &= nbsp; 138578.57k   440607.38k  1082163.29k  1674088.= 45k  2017296.38k  2047377.41k
> sha256 &= nbsp;        150670.11k   4= 60483.71k  1054829.57k  1553830.57k  1807897.94k  18= 23981.57k
> sha512      &= nbsp;    41246.76k   181566.07k   341= 457.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 num= ber
> (such as a GUID), you may be tempted to take SHA-= X and just truncate
> it. However, this biases the resu= lting 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 "sa= fe"), it - 
among other properties - needs to have th= e "avalanche effect" property, 
which means that any = change in the input is going to affect each output 
b= it with 50% probability.

from = a practical perspective across hundreds of millions of hashes of unique = ids, I can say that there is a practical and detectable bias when trunca= ting sha-256 hashes. Enough that we were having to throw out a/b test re= sults=E2=80=A6 I=E2=80=99m not going to write a paper on it and I=E2=80=99= m not going to bother arguing the point that no hash function is perfect= , but I will point out that =E2=80=9Ctheory=E2=80=9D and =E2=80=9Crealit= y=E2=80=9D don=E2=80=99t always agree. 


This mea= ns that for a cryptographic hash algorithm - such as the SHA-2 
=
family - the resulting hash is indistinguishable from uniform= ly selected 
random bits. And this property also hold= s after truncation - you just 
have fewer bits of cou= rse.


> be considered unsaf= e (such as using it in an A/B testing tool). Just
> bec= ause you have a short hash, doesn't make it "unsafe" as longer
=
> hashes can also be considered "unsafe." What people usually me= an by
> this is in the context of encryption, and in th= ose cases it is
> unsafe, but in the context of non-enc= ryption, usage of truncated
> larger hashes is just as = unsafe.
> 

I'm afraid= I don't understand what you are attempting to say here.
<= br>
Best regards
Tim D=C3=BCsterhus


=E2=80=94= Rob
--476d064325c64f14b3d6866f7c981817--