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

[Arnaud Fontaine]

Le 26/10/2016 02:31, NIIBE Yutaka a écrit :
> Hello,
> 
> Arnaud, please be patient.  Examining your patch, I realized
> that we need to clarify things for ECDH by smartcard/token.
Ok :-)


> 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).
Actually, the result my applet is returning is padded with zeros, but after it is
received it is stored in the shared_mpi and then copied to secret_x using
gcry_mpi_print
(g10/ecdh.c line 125), so the leading zeros have disappeared.
Adding a prefix could solve this problem, and it would not be a problem to
impement it,
but I agree with you that it should be addressed in the OpenPGP card
specification so that
every one will follow the same rule.