Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:124445 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 E31741A00B7 for ; Tue, 16 Jul 2024 07:29:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1721115073; bh=7S2KlEEWBpq4rwUbq0H76VP2kAb0Z7YUkuncm+41Qgs=; h=In-Reply-To:References:Date:From:To:Cc:Subject:From; b=ktFNHsNXyKEppEqeqedXKkoSN3FjsVmRdZxXPznK/zYAgh6yKI4UOYaqPzM2JSVPH XYeuUAV2MfwbPJmLH4sNsIFPKCxiKvlRRduInmoscBsf+wCxvYdeF47w9qW8FnvVZj 0iwoOGNECPi5jZj+9iwkm//cFt8VU9nxtd/6RruFjAUpnij9Ctjcw8A2E6RWN53gtD qaRy06kcEqbCOivxPmakUdNlUuFn8cI6F3gxjEfRpEZDdaovsrcxW351hw7GTpoiWU yCLrrEs3wRbMOLtfyzzLRDKz5GAj0vvTDPiZVzsZBlj2csA0liNED+t79qI4XXzSn0 uU6GBn004xANw== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 656D9180AE4 for ; Tue, 16 Jul 2024 07:31:12 +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 fhigh1-smtp.messagingengine.com (fhigh1-smtp.messagingengine.com [103.168.172.152]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Tue, 16 Jul 2024 07:31:11 +0000 (UTC) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailfhigh.nyi.internal (Postfix) with ESMTP id 1749511482FA; Tue, 16 Jul 2024 03:29:42 -0400 (EDT) Received: from imap49 ([10.202.2.99]) by compute1.internal (MEProxy); Tue, 16 Jul 2024 03:29:42 -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=1721114982; x= 1721201382; bh=W/jLJuKkfuhM0ilDNjf0x5EYRQKxr7pApKb9Gzo6les=; b=t YcS7jL7IULdE+WBKSokb7i61fySGCSvoQ4JDnN92WO3WK2YeZ8JVkarexAwIkptk Th0R0tMEmzE3sjVp4AHP22tLbj3Pi/HDarYcaqRj75wEgSn4ytTf7VuZtPztgjhy LXlGlGaHxRIdXJvmZlrgiZ8GdYeHnSxKw0wKH9KrvjIH+pT1o/P8AflHrTdXOw1F YF9Vw00CyoSyFA0kFr5KSo9/nT1GjHQMGf1YrKTuE1PfYmpiEhH63LRsKNQL9hn/ ReVYpUF1XyjHF0SeB53IBtveNHd8QQ9kMcXjHca0lCuidDEvJHwJ09jCih1b29+V ozTgiOWRRUXgmhskMykdw== 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=1721114982; x=1721201382; bh=W/jLJuKkfuhM0ilDNjf0x5EYRQKx r7pApKb9Gzo6les=; b=cJFRbqcR39zFJPdObKjRR+ttC0QFk3dKCtckFEiyScj3 9vHZ/0VUMJGPAmu6X5tU6uRDiKVkTSJByKqPfUKnN8X5HtTF5XJ57L7xrVuFVEOi YjAjsMruyL/JVsbCwRfBU7/y5SEF1XUJW+OfmHXsXW8FbipgLdZotiLcHw16y3ib RO6Vd3WmYan1auCx4MnxS+bKz/pXPxHOWxl8WL25dpUiVCIjT0V3otkp2rQM4A0U tehgTN2OlHCy2K9sJkpZ+hGHvbduAJCHEokMS1L1TAFujbg3X6dqaKWFcW5BYBCb RB7MOggWPz2K0GjKFYqowirJ4y2/Yi1JLSaML+b3Lw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrgeefgdduudelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvvefutgesrg dtreerreerjeenucfhrhhomhepfdftohgsucfnrghnuggvrhhsfdcuoehrohgssegsohht thhlvggurdgtohguvghsqeenucggtffrrghtthgvrhhnpedvheekteelveetfeevgeekgf ffvdeuhfelveehvdetiefggedtfeejheetgffhueenucevlhhushhtvghrufhiiigvpedt necurfgrrhgrmhepmhgrihhlfhhrohhmpehrohgssegsohhtthhlvggurdgtohguvghs X-ME-Proxy: Feedback-ID: ifab94697:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 764CE15A0092; Tue, 16 Jul 2024 03:29:40 -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: <97063534-f7f5-4fea-b336-7ce1de6d33a8@app.fastmail.com> In-Reply-To: <5a232cee-00fe-43ec-8e3f-1953a302692e@app.fastmail.com> References: <6683CDE4.7050607@adviesenzo.nl> <668B5728.40300@adviesenzo.nl> <3XlxyoEWXN5MLqWhlh4uQMXGc2DRs7OH72f_InABxrhsBVTZIPOrfO3qEKqG94844M2r3FUS_zGMa60dENgvLP6TC8zOWZASkN6w6ZxsaxM=@gpb.moe> <7322787a-2c35-4926-baae-84cf46a6acea@bastelstu.be> <5a232cee-00fe-43ec-8e3f-1953a302692e@app.fastmail.com> Date: Tue, 16 Jul 2024 09:29:19 +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=5843370bb6eb425186b0e319252e60db From: rob@bottled.codes ("Rob Landers") --5843370bb6eb425186b0e319252e60db Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Tue, Jul 16, 2024, at 01:08, Rob Landers wrote: >=20 >=20 > 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_n= i=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 = 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 >>=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 cryptographicall= y=20 >> secure (which I consider to be a reasonable definition of "safe"), it= -=20 >> among other properties - needs to have the "avalanche effect" propert= y,=20 >> which means that any change in the input is going to affect each outp= ut=20 >> bit with 50% probability. >=20 > 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= truncating sha-256 hashes. Enough that we were having to throw out a/b = test 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 i= s perfect, but I will point out that =E2=80=9Ctheory=E2=80=9D and =E2=80= =9Creality=E2=80=9D don=E2=80=99t always agree.=20 I have been corrected. The issue was due to a modulus causing the bias d= eeper in the code. =E2=80=94 Rob --5843370bb6eb425186b0e319252e60db Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable

=

On Tue, Jul 16, 2024, at 01:08, Rob Landers wrote:


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

On 7/15/24 16:12, Rob Landers wrote:
> This always gets me. "safer" doesn't have a consistent meani= ng. 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: W= ed Feb 21 10:45:39 2024 UTC
> options: bn(64,64)
> compiler: *snip*
> CPUINFO: OPENSSL_ia32ca= p=3D0x7ffaf3ffffebffff:0x98c027bc239c27eb
> The 'number= s' are in 1000s of bytes per second processed.
> type&n= bsp;            1= 6 bytes     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  16= 74088.45k  2017296.38k  2047377.41k
> sha256&= nbsp;         150670.11k &n= bsp; 460483.71k  1054829.57k  1553830.57k  1807897.94k&nb= sp; 1823981.57k
> sha512     &= nbsp;     41246.76k   181566.07k &nbs= p; 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 b= it number
> (such as a GUID), you may be tempted to tak= e SHA-X and just truncate
> it. However, this biases th= e resulting numbers, which this bias may

Th= is is false. For a hash algorithm to be considered cryptographically&nbs= p;
secure (which I consider to be a reasonable definition = of "safe"), it - 
among other properties - needs to h= ave the "avalanche effect" property, 
which means tha= t any change in the input is going to affect each output 
=
bit with 50% probability.

from a practical perspective across hundreds of millions of hashes of u= nique ids, I can say that there is a practical and detectable bias when = truncating sha-256 hashes. Enough that we were having to throw out a/b t= est 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. 

I have been corrected. The issue was due to a modul= us causing the bias deeper in the code.

=E2=80=94 Rob
--5843370bb6eb425186b0e319252e60db--