guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#57599] bug#57576: bug#57599: [PATCH] openpgp: Add support for ECDSA


From: Maxime Devos
Subject: [bug#57599] bug#57576: bug#57599: [PATCH] openpgp: Add support for ECDSA with NIST curves.
Date: Tue, 6 Sep 2022 18:10:15 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0


On 06-09-2022 13:58, Ludovic Courtès wrote:
Hi,

ECDSA and the NIST curves (and in fact a large part of NIST’s crypto
standardization work¹) are actually considered with skepticism by some:

   
https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm#Concerns

That makes me wonder whether supporting them is a good idea, after all.
Evidently they’re not widely used in OpenPGP and not supporting them
hasn’t been much of a problem, it seems.  On one hand, we don’t want
Guix’s OpenPGP implementation to limit what users do with their OpenPGP
keys; on the other hand, we don’t want to encourage algorithms that
bring little to the table at best and are suspicious at worst.

What do people think?

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.

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.

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

(*) I mean proof, like in mathematical proofs, not merely evidence.

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.

Zhu Zihao wrote:

My opinion: Maybe NSA recommend NIST family because they know how to get
around it.
If so, I believe this is an argument against allowing these curves, to avoid a method NSA could use for attacks.
But they also have to believe foreign government can't break
it easily.
For people outside the US, the US (of which the NSA is an agency) _is_ a foreign government. As Guix is not an US-specific project, I do not think this is an argument for allowing the curves.

Greetings,
Maxime.
Ludo’.

¹ https://blog.cr.yp.to/20220805-nsa.html


Attachment: OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]