Checksum error importing (unencrypted) ecdsa private key

Krzysztof Kotowicz koto at
Fri Sep 18 16:08:16 CEST 2015

On Tue, Aug 11, 2015 at 3:39 AM, NIIBE Yutaka <gniibe at> wrote:

> Hello,
> Sorry for late response.  Thanks a lot for your bug report with
> reproducible case.  It helps us to debug.

It looks like it hasn't been fixed yet, as I'm getting the same error in
2.1.8. Do you have a bug# to track this? We have another reproductible case

> On 01/29/2015 09:33 AM, KB Sriram wrote:
> > command 'IMPORT_KEY' failed: Checksum error
> > etc.
> >
> > 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.
> --
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel at

koto@ / Krzysztof Kotowicz / Google
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150918/6989d39f/attachment.html>

More information about the Gnupg-devel mailing list