Checksum error importing (unencrypted) ecdsa private key
gniibe at fsij.org
Tue Aug 11 03:39:37 CEST 2015
Sorry for late response. Thanks a lot for your bug report with
reproducible case. It helps us to debug.
On 01/29/2015 09:33 AM, KB Sriram wrote:
> command 'IMPORT_KEY' failed: Checksum error
> I may be wrong, but it seems like the issue is triggered around here:
> The line
> if (is_enc || curve)
> and subsequent comment assumes that encrypted parameters or ecc
> parameters should be stored as opaque gcry_mpi_t numbers; but seems
> to me that unencrypted ecc values should not enter this clause?
You are right. I confirmed that the code is wrong and your proposed
fix is right.
I think that agent/cvt-openpgp.c needs some more clean up, because we
have some experimental code remained (for ECC), and there are some
confusions about handling of opaque buffer.
I'll do that after 2.1.7 release, possibly this week.
In the libgcrypt computation of ECC, it uses opaque buffer for public
key of modern curves (Ed25519 and Curve25519), instead of (big endian)
MPI, as those keys are defined in little endian.
In GnuPG, the code under g10/ (gpg frontend) just treats it as if it
were MPI, and it works well because of the prefix 0x40 for keys of
modern curves. It should be also no problem for the code under agent/
(gpg-agent) to treat it as if it were MPI, and it does so successfully
at most parts.
Currentlyu, we have some code in agent/cvt-openpgp.c, trying
differently somehow, and it is not correct for both of modern curves
and traditional curves (NIST, Brainpool, etc.), unfortunately.
If we would do that faithfully, we need to distinguish the curve if
its key is opaque in libgcrypt or not. But for conversion from/to
openpgp to libgcrypt format, and for handling public key, I think
that we can treat it as if it were MPI.
Because GnuPG 2.1 doesn't allow exporting private key with no
protection, this bug can be only encountered with external keys.
More information about the Gnupg-devel