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

[Ludovic Courtès]

Hi!

All things considered, I prefer to drop this patch.  In the unlikely
event that we’ll get more requests to support these curves, we can
always revisit the issue.

What we should do, though, is improve error reporting in case an
unsupported curve or algorithm is encountered.

Thanks,
Ludo’.

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

[zimoun]

Hi,

On Wed, 07 Sep 2022 at 14:51, Ludovic Courtès  wrote:

> I’d like to see what other free software OpenPGP implementors decided
> (primarily Sequoia; GnuPG/Libgcrypt implement them).

Maybe related .


Cheers,
simon

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

[Ludovic Courtès]

Hi,

Thanks a lot for the explanations, Andreas!

As you write, the decision will be “political” as there’s no scientific
evidence to guide us.

I’d like to see what other free software OpenPGP implementors decided
(primarily Sequoia; GnuPG/Libgcrypt implement them).

Ludo’.

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

[Andreas Enge]

Am Wed, Sep 07, 2022 at 01:13:25PM +0200 schrieb Maxime Devos:
> Also, we _do_ have concrete evidence that the curves are flawed -- the website
> on the link mentions many issues in the process

The website (you mean the blog by D. Bernstein?) also mentions the use of
a hash function to arrive at the parameters. Maybe I overlooked something,
but I did not find other mentions of the curves (but I did not read the
page from A to Z).

> past that the NSA is in the habit of subverting communications.

But this is not concrete evidence that these curves are flawed.
As far as is publicly known, there are a few weak (and sparse) classes
of insecure elliptic curves, and the NIST curves do not belong to them.

So the only way these curves could be flawed is that there is an unknown
class of insecure curves, where the insecurity is known by the NSA.
Then if this class is sufficiently dense, one could start with a random
seed, hash the seed, and repeat until one obtains a weak instance;
see this link by a well-known cryptologist
   https://miracl.com/blog/backdoors-in-nist-elliptic-curves/
and the link given there (to another post by Bernstein).

This is possible, but speculation instead of evidence.

Newer constructions are better, but not perfect; optimally one would want
a process of "generation of public random numbers" as described here:
   https://eprint.iacr.org/2015/366

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

I said "political", which fits well the setting of multiple people involved.
And I meant this in opposition to "scientific", given the lack of evidence
against the NIST curves.

Andreas

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

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

[Andreas Enge]

Hello,

Am Tue, Sep 06, 2022 at 10:02:55PM +0200 schrieb Ludovic Courtès:
> (Cc’ing Andreas for extra advice.)

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, but ultimately this is a political decision (and a personal
decision about which type of key a user creates).

Andreas

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

[Ludovic Courtès]

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

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

[Maxime Devos]

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




OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

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

[Zhu Zihao]

My opinion: Maybe NSA recommend NIST family because they know how to get
around it. But they also have to believe foreign government can't break
it easily.

-- 
Retrieve my PGP public key:

  gpg --recv-keys 481F5EEEBA425ADC13247C76A6E672D981B8E744

Zihao

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

[Ludovic Courtès]

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?

Ludo’.

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