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 PM Larry Garfield <la...@garfieldtech.com>
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; and
> even then, I'd expect to be able to default to it.
>
> 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.
>
> I am overall in favor of this RFC, modulo notes above.
>
> --Larry Garfield
>

Reply via email to