Re: [RFC][DISCUSSION] Add RFC 4648 compliant data encoding API

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