Catch 22 in ECC support of OpenPGP?

Andrey Jivsov openpgp at
Fri Jan 31 07:17:18 CET 2014

On 01/30/2014 07:46 PM, NIIBE Yutaka wrote:
> Hello, Andrey and Werner,
> Cc-ed to GnuPG Development List.
> I'm currently considering adding other curves and EdDSA signature
> scheme to Gnuk.  I'm also considering update of GnuPG's smartcard
> support for ECC.
> I think that adding curves would be no problem against RFC6637, as OID
> is unique.  Currently, development version of GnuPG supports curves
> defined by RFC6637 as well as three curves of Brainpool, and
> secp256k1.
> I think that adding new signature scheme requires its algorithm ID.
> Writing this mail today, I did some research.  Then, I found the
> discussion in OpenPGP at
> (1) Possible algorithm ID 22 for ECDH+ECDSA:
> (2) Possible algorithm ID 22 for EdDSA:
> It's better to sort it out now.
>     Algorithm ID 22 for ECDH+ECDSA
>     Algorithm ID 23 for EdDSA
> ?
> Sorry for interference, but I need Algorithm ID 22 (and 23) defined,
> indeed.

I am fine with 22.

I think it's premature to think that the 23 EdDSA is ready to go along 
the side of ECDSA. I am not saying that this will never happen, but 
rather that this needs to be discussed and benefits stated. ( Would it 
work to perhaps claim some higher-numbered ID in the mean time? If it 
turns to be popular, we can "upgrade" it later to the permanent number)

As for compact representation, I recently updated 
http:// to include 
curves other than simple Weierstrass curves. I would recommend it as a 
format for OpenPGP. NIIBE, perhaps you could double-check that you are 
OK with the representation for Curve25519.

To use the draft-jivsov-ecc-compact in OpenPGP there could be a separate 
draft, but its value will be mostly procedural because it will basically 
refer the reader to the draft-jivsov-ecc-compact (so one knows what to 
do without such a second draft already when, for example, a single "x" 
is encountered).

More information about the Gnupg-devel mailing list