[PATCH] g10: Fix ECDH secret compressed/uncompressed format

[Werner Koch]

On Wed, 26 Oct 2016 02:31, gniibe at fsij.org said:

>>      0x04  Standard flag for uncompressed format
>>      0x40  Native point format of the curve follows
>>      0x41  Only X coordinate follows.
>>      0x42  Only Y coordinate follows.
>> 
>> We only use 0x40 for EdDSA but the the new flag 0x41 is what I suggest
>> for your use.  We can prefix the x-coordinate in scdaemon with 0x41 so
>> that we do not run in ambiguities in other parts of the code.
>
> I agree.  Let us clarify.  Do 0x41 and 0x42 mean standard MPI (of big
> endian)?

Good question, given that 0x40 is the native format for the curve we
may either do this

      0x04  Standard flag for uncompressed format
      0x40  Native point format of the curve follows
      0x41  Only X coordinate follows in native endianess of the curve.
      0x42  Only Y coordinate follows in native endianess of the curve.

or this:

      0x04  Standard flag for uncompressed format
      0x40  Native point format of the curve follows
      0x41  Only X coordinate follows in big endian format
      0x42  Only Y coordinate follows in big endian format

I am unsure.  How would it best fit into Libgcrypt?

> Besides, in GnuPG and libgcrypt, ECDH with Curve25519 (X25519) also
> uses the prefix 0x40 for its point representation.  It is
> little-endian and x-coordinate only.

Which is kind of okay because 0x40 is the native format of the curve and
ECDH requires only the X coordinate.  Depending on how we interpret 0x41
we may want to allow 0x41 also.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 162 bytes
Desc: not available
URL: </pipermail/attachments/20161026/d672f8df/attachment.sig>