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

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 <larry@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 >