[PATCH] g10: Fix ECDH secret compressed/uncompressed format
arnaud.fontaine at ssi.gouv.fr
Wed Oct 26 10:00:53 CEST 2016
Le 26/10/2016 02:31, NIIBE Yutaka a écrit :
> 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
> 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
(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
but I agree with you that it should be addressed in the OpenPGP card
specification so that
every one will follow the same rule.
More information about the Gnupg-devel