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

[Maxime Devos <maximedevos@telenet.be>]

[-- Attachment #1.1.1: Type: text/plain, Size: 2720 bytes --]


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 #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]