On Thu, 24 Sep 2015 at 02:46 NIIBE Yutaka <gni...@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
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
