Moving forward with Curve25519 (was: [PATCH] Curve25519 patch revised)

Werner Koch wk at gnupg.org
Tue Aug 5 13:01:27 CEST 2014


On Fri, 20 Jun 2014 15:28, gniibe at fsij.org said:

> For Montgomery curve, it doesn't compute y-coordinate, and the
> representation in my current implementation is:
>
> 	04 || X || ZERO

I would suggest to use

        41 || X

and we are done.  Simon's draft-josefsson-tls-curve25519-05 for TLS does
the same.

0x41 is not used by SEC1 but it is quite similar to it.  A nice property
of the prefix bytes is that they avoid misintrepretation as a negative
value and are thus compatible to OpenPGP MPIs.  Thus my suggestion is to
define these prefix bytes:

        40 := Native point format of the curve follows
        41 := Only X coordinate follows.
        42 := Only Y coordinate follows.

In GnuPG master (and libgcrypt 1.7) 0x40 is already supported for
Ed25519 keys.  I also working on an I-D for EdDSA (ed25519) support in
OpenPGP to get an algorithm id assigned.

> IIUC, draft-jivsov-ecc-compact-05 can be applied to 6637
> straightforwardly, and fingerprint (or keygrip) will be different when
> representation will be changed.  Is this right?

Should not because we are already using the Jivsov method for key
creation.

However, I doubt that we need that right now and I would propose to just
go forward and not wait on the IETF to decide on new curve and point
representation.  The whole thing is delayed way too long and there are
no signs that there will be any soon decision.  I am more and more
convinced we should set the standard by using it.  OpenSSH and several
other projects settled for the Chicago curves instead of waiting until
the IETF participants (where some of them work for the NSA or govt
contractors) agree on something.

Using the Montgomery coordinates for ECDH is just fine.  If an
implementation wants to use its Edwards maths it can be easily done and
mapped to Montgomery coordinates.  A revision of RFC-6637 can always be
made and document the new compression scheme.  We can also wait for an
successor of RFC-4880 to obsolete the current OpenPGP RFCs.


Shalom-Salam,

   Werner

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




More information about the Gcrypt-devel mailing list