[PATCH] g10: Fix ECDH secret compressed/uncompressed format
gniibe at fsij.org
Wed Oct 26 10:42:47 CEST 2016
On 10/26/2016 05:00 PM, Arnaud Fontaine wrote:
> 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
> 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.
Thank you for your explanation. I understand the situation.
So, how about the following?
* In the OpenPGP card specification
The result from card should be one of:
(1) Standard one, that is: 04 || X || Y
(2) Fixed length native x-coordinate only
In case of classic ECC, native means big-endian MPI.
For X25519, native means little endian.
* Modification in scdaemon
In case of (2) for classic ECC, just like the case of X25519, scdaemon
adds the prefix of 0x41 to the result by card/token. GnuPG frontend
receives the bytes with the prefix, it is always fixed length.
* Modification in gpg
Add the support of the prefix 0x41 handling.
More information about the Gnupg-devel