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

[NIIBE Yutaka]

Hello,

Arnaud, please be patient.  Examining your patch, I realized
that we need to clarify things for ECDH by smartcard/token.

On 10/25/2016 09:09 PM, Werner Koch wrote:
> I see.  For EdDSA we extended the meaning of the flag octet like this:
> 
>      Flag  Description
>      ----  -----------
>      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)?

I think that the representation between scdaemon and GnuPG should
always have the prefix to avoid ambiguities.

Arnaud, could you please consider a possibility to change your OpenPGP
card implementation to have the prefix 0x41 for the result of ECDH
decryption, or padding zero to be always fixed size of bytes?  No,
it's not decided yet, but I'd like to see how we can change (which
part of code and how).

			*	*	*

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.


In Gnuk 1.2 (my own implementation of OpenPGP card), it doesn't use
any prefix of ECDH with Curve25519 (X25519).  It just uses its native
format.

For ECDH with Curve25519 (X25519), it is scdaemon which handles the
prefix of 0x40.  For public key, scdaemon adds the prefix 0x40 to the
returned value from Gnuk, which is returned to GnuPG.  For decryption,
scdaemon removes the prefix 0x40 from GnuPG's representation and sends
it to the token.  Then, the token returns native 32-byte of
x-coordinate only to scdaemon.  Scdaemon adds the prefix 0x40 to the
bytes to send back to GnuPG.

For classic ECC, it is possible for scdaemon to do similar thing.  But
we need to handle the ambiguities.  If it's size is smaller than
x-coordinate and it starts with 0x41, it's not clear if it's the
prefix or not.


For completeness of the specification, this should be addressed in the
OpenPGP card spec.
-- 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20161026/94860d1f/attachment-0001.sig>