Catch 22 in ECC support of OpenPGP?
openpgp at brainhub.org
Sat Feb 1 07:09:42 CET 2014
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.
>> 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 .)
> 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
>> 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.
>  Debian bug report to gnupg: http://bugs.debian.org/714107
More information about the Gnupg-devel