Checksum error importing (unencrypted) ecdsa private key

[Krzysztof Kotowicz]

On Tue, Aug 11, 2015 at 3:39 AM, NIIBE Yutaka <gniibe at fsij.org> 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
at https://github.com/google/end-to-end/issues/326#issuecomment-123585977


> 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:
> >
> >
> http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=agent/cvt-openpgp.c;h=8cf00233e4178ee34592273c167875d083406a17;hb=0c2bfd9d5a49a6134188f8f7820f6ccdebd9f181#l831
> >
> > 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 gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel
>



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