Subject: [Cfrg] GPG and the way forward

From: Watson Ladd <[email-masked]>
Date: Thu, 6 Nov 2014 21:37:45 -0800

Dear all,

GPG has just added Curve25519. It may be worth considering getting
some sort of document describing Curve25519 out there, and waiting for
someone to get convinced of something on the TLS recommendations. (I
know I promised to write the best argument I could for NUMS by now,
but I'm still thinking about how to defend the twist choice)

Even if we recommend the NUMS curves in some form, Curve25519 and
Ed25519 will not be going away. I doubt that the GPG authors will be
willing to remove support so soon after adding it. If we recommend
NUMS in the twisted, originally specified form, implementors will not
implement this but instead implement Curve25519, because it's
significantly easier to avoid mistakes and much simpler. Even in the
untwisted form tweetnacl.c has wormed its way into hearts everywhere,
and has been translated into a dozen languages.

Between GPG, SSH, and half-a-dozen other projects there will be
demands to add Curve25519 to standards to describe existing practice.
Are we going to say no to that? If we specify short Weierstrass form
for backwards compatibility with HSMs, do we then force applications
without that constraint to use a point format that is less convenient
for them?

I think the answer to both these questions is no. So I would recommend
we do the following:
- Advance a draft describing the current Curve25519 and Ed25519
- Separately decide what we want to recommend should be used in TLS
- Write and work on the draft for that recommendation

This doesn't make our recommendation problem any easier, but it does
remove one of the barriers to picking NUMS, namely the existing
adoption of Curve25519. That's not going away: being the only fast
alternative to P256 for 8 years has lead to adoption, unsurprisingly.

Sincerely,
Watson Ladd

---

From: Andrey Jivsov <[email-masked]>
Date: Fri, 07 Nov 2014 13:43:33 -0800

On 11/06/2014 09:37 PM, Watson Ladd wrote:
> Dear all,
>
> GPG has just added Curve25519.

Just to provide some context,

the main developer of GnuPG announced that he wrote code for Ed25519 in 
Nov 2013. Curve25519 was added earlier in 2014.

Note that ECC support is disabled in gnupg2 and is only available in the 
dev. version that one compiles himself.

  gpg2 --expert --gen-key

doesn't offer any ECC choices I believe it used to have (did this on 
Fedora core 20).

( I believe gpg2 used to offer them, but this was removed soon after 
Snowden ).

It may be worth considering getting
> without that constraint to use a point format that is less convenient

he interoperability base is a major concern for OpenPGP. Unlike TLS, 
there is no real-time negotiation in the OpenPGP protocol regarding 
algorithms involved in signing (e.g. public key, hashes). So, less is 
more for adoption of signing algorithms in OpenPGP, and encryption 
algorithms to some extent as well.

Given that P-256 had troubles gaining traction in its golden years prior 
to Snowden, OpenPGP will benefit from one blessed standard for non-NIST 
ECC. GnuPG also had Brainpool curves, with probably ~ zero adoption 
outside of Germany. The new reality is that if one wants to to 
interoperate with ECC in OpenPGP in the next 5 years, one will need 
P-256 and the second to-be-selected curve. The main benefit of the 
second curve, which unfortunately splits the interoperability base, is 
user demand for a trusted non-NIST choice. Performance arguments, 
simplicity of implementation, side channels, etc are not really a 
concern driving the demand for the non-NIST choice.

> alternative to P256 for 8 years has lead to adoption, unsurprisingly.

Speaking for OpenPGP implementations in general, in my opinion the right 
thing for OpenPGP community is to wait for CFRG recommendation and then 
prioritize the implementation of this choice. Given the past experience, 
this will take years in the best-case scenario.

Note that OpenPGP was friendly with 4K RSA keys for a decade. ECC is 
disabled in gpg2 and is completely absent in the codebase of gpg, which 
caused some dissatisfaction of users, but apparently users feel good 
about RSA. The OpenPGP community can wait for a few months for a CFRG 
recommendation.

( Past that, there are other technical issues to sort out for OpenPGP 
such as point compression and the desire to have a public key that can 
be used for both encryption and signing, which was traditionally a 
capability of any public key algorithm in OpenPGP. )

>
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/cfrg
>

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 07 Nov 2014 16:57:36 -0500

> dev. version that one compiles himself.

A couple clarifications:

The release of gnupg 2.1.0 ("modern") earlier this week makes it
available to anyone running that version of gpg, which is available
pre-built in at least in debian's experimental repository, maybe
elsewhere too.

While generation of ECC keys is hidden behind the --expert flag, support
for the use of ECC keys is *not* disabled in gnupg 2.1.0.

so if you already have such a key, or if your correspondent has such a
key, gpg 2.1.0 should "just work" with it.

This supports NIST curves, and Ed25519.

I don't think that any released branch of gpg2 has offered ECC in the past.

I agree with Andrey's general point about the OpenPGP community being
likely to be willing to adopt whatever stronger curve CFRG recommends,
if such a recommendation is forthcoming.

	--dkg

---

From: Derek Atkins <[email-masked]>
Date: Fri, 07 Nov 2014 12:54:23 -0500

> but I'm still thinking about how to defend the twist choice)

There is a draft on using 25519 (Ed form, IIRC) in OpenPGP, written by
Werner Koch.  Are you looking for some other, more general draft?

[snip]
> alternative to P256 for 8 years has lead to adoption, unsurprisingly.

-derek
-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Watson Ladd <[email-masked]>
Date: Sat, 8 Nov 2014 18:46:19 -0800

> Werner Koch.  Are you looking for some other, more general draft?

The Koch draft is similar to the original Turner draft. There were
several objections to the Turner draft that would carry over:

1: The least serious one is that the paper isn't a description
adequate for implementation.

2: More serious is that we don't want to depend on a paper that isn't
a standard. I have no idea how serious this objection actually is.

3: The crosscutting issue, and the reason we didn't say "yes, use
Curve25519" is that apparently CFRG is supposed to choose curves. As
far I know, this is new: I don't recall discussion of Brainpool
security in this forum.

We can finesse issue 3 by making our recommendations TLS only, and
ignore issues 1 and 2. But this cuts across a lot of early emails in
which people complained about these two points and wanted us to make
IETF wide recommendations. It also should be noted that putting the
curves into Weierstrass form wasn't considered, even if it would make
coding easier and reuse of smartcards easier.

Sincerely,
Watson Ladd

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Werner Koch <[email-masked]>
Date: Mon, 10 Nov 2014 08:57:30 +0100

> for the use of ECC keys is *not* disabled in gnupg 2.1.0.

To add on this: This is a general strategy when we introduce a new
algorithm.  We first implement it in a kind of read-only way until the
deployment is wide enough to allow creating data using this new
algorithm.  Only then we make this algorithm more visible.  Prime
example for this is the introduction of DSA > 1024.  It would have been
useless to allow people to create keys with 2048 DSA if only a few
deployed implementations were able to use them.

BTW, ECDH using Curve25519 is not yet implemented because we have no
usable specs for this and in OpenPGP it is more important to have a
signing algorithm available - it is easy to add or change an encryption
subkey at any time later.

> I don't think that any released branch of gpg2 has offered ECC in the past.

Except for a Andrey's first implementation which is not widely known and
not maintained.

Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.