Catch 22 in ECC support of OpenPGP?

[Andrey Jivsov]

On 01/30/2014 11:50 PM, NIIBE Yutaka wrote:
> 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.

If this is a standard method that everybody would be using, then this 
will work. I think that a compact representation of a point that fits 
the size of the scalar (or x coordinate, the underlying field) is the 
ideal encoding, as opposed to an encoding with a prefix.

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

The type of compression is not so important with ECDH, because you are 
using only the x coordinate as a shared secret (so the y will not need 
to be calculated). There are more choices because of this.

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