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