[bug#57599] bug#57576: bug#57599: [PATCH] openpgp: Add support for ECDSA with NIST curves.

[Maxime Devos]

On 06-09-2022 22:02, Ludovic Courtès wrote:

> > 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.
>

In cryptography (and security), being a grey area and not known to be vulnerable is not sufficient -- rather, there has to be a reason for confidence that that the crypto is actually good and not-vulnerable for a decent amount of time.

Or, in other words, in cryptography and security there is no assumption of innocence -- rather, it starts with the assumption that anyone might be an attacker and whoever proposes a crypto thing has to convince others that their crypto is secure, and a communication party has to proof to the other party that they aren't an imposter (public key signing, with an previously agreed on key and algorithm).

Andreas wrote:

> well, I agree with your analysis. There is no concrete evidence that the
> NIST curves may be flawed, and a general belief that not all crypto
> standards of NIST are flawed or backdoored... So it makes sense to accept
> the curves, (and a personal decision about which type of key a user creates).
>       
      I followed you right until the conclusion, it appears that you are
      starting from an assumption of innocence, which might explain our
      different conclusions?

Also, we _do_ have concrete evidence that the curves are flawed -- the website on the link mentions many issues in the process and it has been shown in the past that the NSA is in the habit of subverting communications (*).

(*) I can give some sources if you don't know of them already.

Channels are for sharing things between multiple people.  The keys are for authenticating channels.  As multiple people are involved for a channel, this seems be be a non-personal decision by definition.

Greetings,
Maxime.

OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key

OpenPGP_signature
Description: OpenPGP digital signature