Moving forward with Curve25519

[Werner Koch]

On Wed,  6 Aug 2014 00:40, openpgp at brainhub.org said:

> For all protocols that I know, including OpenPGP, the Y coordinate is
> not used in the calculation of the shared secret in ECDH. This is

Sure.  I mentioned 0x42 only for completeness.  We do not need it.

> X has aesthetically pleasing 32 byte size. X is an integer, which fits
> perfectly into the OpenPGP container, which is an MPI.

Only 50% of those values would fit as 32 bytes into an OpenPGP MPI.  As
soon as the high bit is set we should prefix it with a 0x00 byte to
avoid signed/unsigned problems.  Further, OpenPGP _requires_ us to strip
off leading zero bytes.  Thus there won't be a fixed length anyway.

Using a constant prefix makes things easy.  With the prefix byte we
always have 35 bytes (2 bytes length, 1 byte prefix, and 32 byte value)
and the length will always be 263 (bits).  This allows to keep the code
very small by writing or reading the constant string 0x01,0x07,0x40
which is the followed by the 32 bytes for X.  And other implementations
may use the regular MPI machinery for processing the data.

Actually you did the same in RFC-6637 by requiring the 0x04 prefix.

> I think that OpenPGP should adopt X as the format for the ECDH. This
> works with Curve25519 encryption or any other ECDH scheme.

I concur.

> ( Besides, the value 41 or 42 is implied by the curve OID in the
> following way. If we are talking about encryption and the OID is
> Curve25519, you know it's 41. The value 40 v.s. {41,42} is implied by
> the curveID and the size of the MPI. )

Sure.  I actually considered to make that implicit by either the OID or
even by looking at the size of the MPI and map that to a certain curve.
However, this breaks with the existing ECC format and has is slightly
annoying in that we do not known in advance what will come. (We have a
similar problem with the IV for the key protection which depends on the
block length of the cipher algorithm; if you do not known that algorithm
you can't properly parse the packet).

A more compact key representation would be useful but I do not think we
should do that with v4 packets.  If we need a shorter key presentation
we can do that outside of OpenPGP.  For example in a QR code we may want
a different encoding of the key data (e.g. human readable with checksum).



Shalom-Salam,

   Werner

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