Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127824
Precedence: bulk
MIME-Version: 1.0
Date: Tue, 01 Jul 2025 16:32:45 +0200
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Add RFC 4648 compliant data encoding
 API
In-Reply-To: <0a17ccaf-46e1-441a-b53d-9a3c6b893a03@app.fastmail.com>
References: <CAOV5rgZjxhe+75YD13wWFRNghbS4fbUrJVouPtbUv9RdpKSAXw@mail.gmail.com>
 <CAOWwgpkbyPk6ifAUeK5RuNSzuMNf1nk8gmkzdzbxVGsTig_dWw@mail.gmail.com>
 <CAOV5rgb4Db7cSur6Z-x-OY+4S21oZgH5srtM=O9KsyOt=C2bcw@mail.gmail.com>
 <0a17ccaf-46e1-441a-b53d-9a3c6b893a03@app.fastmail.com>
Message-ID: <a94177a07f50b75181400c34e555b869@bastelstu.be>
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

Am 2025-07-01 16:18, schrieb Larry Garfield:
> I don't follow.  Every function listed allows a timing mode to be set, 
> so I presume that means every function *can* use constant-time.  The 
> implementation is, well, this RFC. :-)  So I don't see why we can't 
> just force constant-time everywhere and be secure-by-default.

Please see the note in the “Implementation” section. I wanted Ignace and 
the discussion to figure out the desired API from a “high level” 
perspective first, before checking individually whether or not a 
constant-time implementation is possible for each of the possible 
combinations of options, since depending on the API that is agreed-on 
certain combinations might not make it (allowing me to skip the effort 
of finding out how to do it constant time).

> If there's a reason we cannot just blanket decide to use constant-time 
> everywhere always, we need concrete examples of why that's a bad idea; 
> and even then, I'd expect to be able to default to it.

A constant-time implementation generally is (measurably) slower than 
non-constant time implementation, but also see above.

> For the long-names issue that Tim pointed out, perhaps drop "Variant" 
> from the enum names?  As they're namespaced, `Base32::Ascii` seems 
> fairly self-explanatory.

You probably meant s/Tim/Rowan/.

Best regards
Tim Düsterhus