Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127830
Precedence: bulk
MIME-Version: 1.0
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>
In-Reply-To: <0a17ccaf-46e1-441a-b53d-9a3c6b893a03@app.fastmail.com>
Date: Wed, 2 Jul 2025 08:26:04 +0200
Message-ID: <CAOV5rgYB4Lp_oSnhjiqCjCayBKNb-fLd=BTNj15bH3G4VcxfNQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Add RFC 4648 compliant data encoding API
To: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000963b3b0638ec567b"
From: nyamsprod@gmail.com (ignace nyamagana butera)

--000000000000963b3b0638ec567b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Larry,

I have updated the wording of the RFC to give the reason for the default
selected variant for each function family. I have also dropped the Variant
suffix from the algorithm variant enum.

Hope this answers your remarks

On Tue, Jul 1, 2025 at 4:20=E2=80=AFPM Larry Garfield <larry@garfieldtech.c=
om>
wrote:

> On Fri, Jun 20, 2025, at 3:17 AM, ignace nyamagana butera wrote:
>
> > - it'd be great to default to url-safe base64. The RFC-compliant
> > variant is a very common risk, it'd be great to be on the safe side by
> > default
> >
> > I went with the RFC recommendation to set up the default. In case of
> > Base64 the URL Safe variant is not the default. While we support URL
> > safe variants there are plenty of applications which do not expect the
> > URL Safe variant, for instance, the data URLs do not use the URL Safe
> > variant.
>
> This should be included in the RFC, so it can be included in the future
> documentation.
>
> > - why do we need to decide between constant-time and unprotected? Can't
> > we always go for the constant-time behavior? If not, what about
> > defaulting to constant-time, again, safe by default?
> >
> > In an ideal world I would use the constant-time behavior everytime, But
> > this will depend largely on the implementation and if it can be applied
> > to every scenario hence why I went defensive on this option.
>
> 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.
>
> 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; an=
d
> even then, I'd expect to be able to default to it.
>
> For the long-names issue that Tim pointed out, perhaps drop "Variant" fro=
m
> the enum names?  As they're namespaced, `Base32::Ascii` seems fairly
> self-explanatory.
>
> I am overall in favor of this RFC, modulo notes above.
>
> --Larry Garfield
>

--000000000000963b3b0638ec567b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi Larry,</div><div><br></div><div>I have updated the=
 wording of the RFC to give the reason for the default selected variant for=
 each function family. I have also dropped the Variant suffix from the algo=
rithm variant enum.=C2=A0</div><div><br></div><div>Hope this answers your r=
emarks</div></div><br><div class=3D"gmail_quote gmail_quote_container"><div=
 dir=3D"ltr" class=3D"gmail_attr">On Tue, Jul 1, 2025 at 4:20=E2=80=AFPM La=
rry Garfield &lt;<a href=3D"mailto:larry@garfieldtech.com">larry@garfieldte=
ch.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex">On Fri, Jun 20, 2025, at 3:17 AM, ignace nyamagana butera wrote:<br>
<br>
&gt; - it&#39;d be great to default to url-safe base64. The RFC-compliant <=
br>
&gt; variant is a very common risk, it&#39;d be great to be on the safe sid=
e by <br>
&gt; default<br>
&gt;<br>
&gt; I went with the RFC recommendation to set up the default. In case of <=
br>
&gt; Base64 the URL Safe variant is not the default. While we support URL <=
br>
&gt; safe variants there are plenty of applications which do not expect the=
 <br>
&gt; URL Safe variant, for instance, the data URLs do not use the URL Safe =
<br>
&gt; variant.<br>
<br>
This should be included in the RFC, so it can be included in the future doc=
umentation.<br>
<br>
&gt; - why do we need to decide between constant-time and unprotected? Can&=
#39;t <br>
&gt; we always go for the constant-time behavior? If not, what about <br>
&gt; defaulting to constant-time, again, safe by default?<br>
&gt;<br>
&gt; In an ideal world I would use the constant-time behavior everytime, Bu=
t <br>
&gt; this will depend largely on the implementation and if it can be applie=
d <br>
&gt; to every scenario hence why I went defensive on this option.<br>
<br>
I don&#39;t follow.=C2=A0 Every function listed allows a timing mode to be =
set, so I presume that means every function *can* use constant-time.=C2=A0 =
The implementation is, well, this RFC. :-)=C2=A0 So I don&#39;t see why we =
can&#39;t just force constant-time everywhere and be secure-by-default.<br>
<br>
If there&#39;s a reason we cannot just blanket decide to use constant-time =
everywhere always, we need concrete examples of why that&#39;s a bad idea; =
and even then, I&#39;d expect to be able to default to it.<br>
<br>
For the long-names issue that Tim pointed out, perhaps drop &quot;Variant&q=
uot; from the enum names?=C2=A0 As they&#39;re namespaced, `Base32::Ascii` =
seems fairly self-explanatory.<br>
<br>
I am overall in favor of this RFC, modulo notes above.<br>
<br>
--Larry Garfield<br>
</blockquote></div>

--000000000000963b3b0638ec567b--