Catch 22 in ECC support of OpenPGP?

[NIIBE Yutaka]

Thank you for comments.

On 2014-01-30 at 22:17 -0800, Andrey Jivsov wrote:
> I am fine with 22.

Good.

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

Thank you for your suggestion.  It's good idea.  (I had an experience
of analyzing a bug report of gnupg which was in fact kernel
incompatibility issue.  It was caused by newly introduced system call
number difference [0].)

It seems for me that OpenSSH are adopting EdDSA, so, GnuPG users will
want to use EdDSA soon through gpg-agent's feature of SSH
authentication.

> As for compact representation, I recently updated 
> http://http://tools.ietf.org/html/draft-jivsov-ecc-compact 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.

Thank you for the reference.  I didn't know you have updated it.

Let me explain my understandings for current situation of Curve25519
and Ed25519 in libgcrypt.

In libgcrypt, there's no support for Curve25519 yet, but Ed25519
(specifically for EdDSA).  Ed25519 has its own compact representation
for elliptic curve point.  Namely, because x can be represented in
255-bit, we have another bit to represent the sign in 256th-bit.

When Curve25519 will be supported in GnuPG, I think that it's only for
ECDH (since people use EdDSA with Ed25519, instead of ECDSA with
Curve25519).  Thus, there will be no problem with the compact
representation (even though there is no condition p mod 4 == 3).

[0] Debian bug report to gnupg: http://bugs.debian.org/714107
--