Hi, (Cc’ing Andreas for extra advice.) Maxime Devos skribis: > We disallow signing with SHA-1, because it is known to be vulnerable > and as there are alternatives that are considered good, even if this > limits what users can do with their OpenPGP keys. Right, we know it’s affordable to break SHA-1 these days. > In case of those curves, I'm not aware of any 'crytopgraphic proof' > (*) that the curves are vulnerable (unlike for SHA-1), but as noted in > ¹ and elsewhere, there are other kinds of evidence that something is > wrong. It’s different from SHA-1 though: ECDSA is not known to be vulnerable, and AIUI we can’t tell that there’s a possibility NIST/NSA has a backdoor as is the case for DualEC. However, the whole NIST design process is tainted. So my understanding is that it’s really a gray area. > Except for the different nature of the evidence of vulnerability, it > seems about the same situation to me. As such, I don't think we should > support them (some nice error messages like 'This algorithm [...] is > not supported yet’ or ‘This algorithm [...] is (likely/known to be) > vulnerable’ would be good though!). Yes, that we can improve. :-) > An alternative option would be to allow the channel > .guix-authorization (of the previous commits, not the commit that is > about to be verified!) to decide what's considered a 'good algorithm' > (with some defaults) (with a field). Maybe we'll have to deprecate, > say, RSA or SHA-3 eventually, it would be nice to have a migration > method in place as early as possible, to minimise the risk of some > people doing a "guix pull" from a Guix that does not support that > field to a Guix or other channel that _does_ use that field. It’s tempting, but I’d rather avoid introducing such mechanisms to keep things as simple as possible. Thanks, Ludo’.