Decryption fails with 4096bit key on SmartCard

[Marcus Ilgner]

On Thu, 24 Sep 2015 at 02:46 NIIBE Yutaka <gniibe at fsij.org> wrote:

> On 09/22/2015 10:26 PM, Marcus Ilgner wrote:
> > Thank you for the hint. I updated the gist at
> > https://gist.github.com/milgner/b823685c8a5960f1f13b to include both the
> > output of `gpg --card-status` (which works fine) as well as the log for
> > trying to decrypt with CCID disabled in scdaemon.conf (which
> unfortunately
> > it yields the same error as before).
>
> Thank you.  Other than the particular error of decryption failure,
> everything looks fine.
>
> > all data stems from the secret key? I.e. the key is moved to the
> > card in full and the blinded/public key as well as the fingerprints
> > are derived from it there?
>
> When you wrote your private key to the card (with gpg --edit-key and
> its sub-command "keytocard"), gpg sent your private key to the card.
> After that, gpg sent fingerprint and timestamp to the card.  Public
> key is generated by the card from private key.
>

Thanks for the explanation! It always helps to know what is (or should be)
going on.


> Could you please try following commands (with debug option in
> .gnupg/scdaemon.conf enabled) to see what's going on?
>
>     $ gpgconf --reload scdaemon
>     $ rm <old-debug-log of scdaemon>
>     $ gpg --card-status
>
> The scdaemon accesses public key information on the card.
>
> You'll see the debug dump of following line:
>
>     raw apdu: 00 47 81 00 02 B8 00 00
>

Not sure whether that is significant but there were a few zero bytes more:
raw apdu: 00 47 81 00 00 00 02 B8 00 08 00

This is to read public key (of decryption) from the card.
>
> It should have valid response of public key as a response of
> this command.
>
> In my case (of RSA-2048 key), it's like:
>
[...]

> '7F 49 82 01 09 81 82 01 00' is a header for the public key.
>

Also some slight differences: it says
7F 49 82 *02* *0A* 81 82 *02* 00


> Then,
> raw RSA public key of 256-byte.  Followed by '82 03 01 00 01', which
> is public exponent.
>
> 65F67E742101C7FE6D5B33FCEFCF4F65EAF0688C is a keygrip of my decryption
> key.  "OPENPGP.2" is the name of decryption key of the card (2 means
> second key on the card; first key is for singing, third key is for
> authentication).
>

That part looks ok again. Although my public exponent is different, too but
I guess that's expected :) Yet 527 bytes total sounds plausible for a
4096bit key.
You can find the full output at
https://gist.github.com/milgner/b823685c8a5960f1f13b#file-public_key_read-log


> If you will see success of this public key retrieval from your card, I
> think that your private key is on your card correctly, but something
> was going wrong for decryption operation.
>
> If you will see failure of this public key retrieval from your card, I
> think that your private key is not on your card correctly.  Something
> was going wrong when you invoked "keytocard" sub-command, but it was
> not reported so (and proceeded to register fingerprint and timestamp)
>

I would assume that the key was indeed transferred successfully then.
Thanks for the help, I have a feeling we're making some headway towards a
solution.

All the best
Marcus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150925/6ac0f211/attachment-0001.html>