GNU bug report logs - #57599
[PATCH] openpgp: Add support for ECDSA with NIST curves.

Previous Next

Full log

Message #17 received at 57599 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Maxime Devos <maximedevos <at> telenet.be>
Cc: 57576 <at> debbugs.gnu.org, 57599 <at> debbugs.gnu.org,
 Zhu Zihao <all_but_last <at> 163.com>, Andreas Enge <andreas.enge <at> inria.fr>
Subject: Re: bug#57576: bug#57599: [PATCH] openpgp: Add support for ECDSA
 with NIST curves.
Date: Tue, 06 Sep 2022 22:02:55 +0200

Hi,

(Cc’ing Andreas for extra advice.)

Maxime Devos <maximedevos <at> telenet.be> 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’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.