I checked a card reader: https://pcsclite.alioth.debian.org/ccid/readers/CardMan3121.txt

02.... Short APDU level exchange

This means that this card reader can't handle larger data, like the one for RSA-4098. So, it can be only used when the data is short.

For Gemalto Shell Tokens: http://support.gemalto.com/index.php?id=tokens
There are three variants. Please describe detail.

It seems that firmware update for Gemalto Shell Token is needed (in some cases):
https://developer.gemalto.com/threads/gemalto-usb-shell-token-v2-not-working-under-debian-73

Here two other Reader example - same message - same problem:
Reader: Gemalto USB Shell Token V2 (00483E73) 00 00
Reader: ACS ACR 38U-CCID 00 00

2017-12-06 20:46:30 scdaemon[4159] DBG: chan_5 <- SERIALNO
2017-12-06 20:46:30 scdaemon[4159] DBG: chan_5 -> S SERIALNO D276000124010201000500004E580000 0
2017-12-06 20:46:30 scdaemon[4159] DBG: chan_5 -> OK
2017-12-06 20:46:30 scdaemon[4159] DBG: chan_5 <- SETDATA 009DC7DF95075C8901A93D1448A35B3611D57BC0A9446F490DE1CE56C5CA3423E402B29C955CF13B4605FAF677EA0BA8D2072ABCE943E7F47E48DD580863818E70566FDEA3BCF6F072B024835D0C39E73B77A6249B39E46664BDD72CA5EF0706D4CF8A224D22BFB8952B4FEE88EB7B67DBCED9166B71211FFA60E68E49E2CB61039ADC02861679E895A629462F2AD6CF35E251744759D2A6F83300B4622409D6D269AE2359640464486BDC2653E20450C906BFAF2105211B96C337AEC52E80096E2BEA97D23B540AF494098B4CB8E1370F0CDEBC48560C5C8562C2A444AC3FA811F4974D373286BEA52A1BFE507E7FB5D7734049361243ABAD93CB0C38403F4E79C0AC43463F8076E6E01D8F2B56C1EFA9A479DFB5F8711CF6EE645D2869E8FA4DB4950AFEA2F1DDD04E01ABFDCC7253DAE67DC0EFEE3BBB975017398129E31031691352B83CFDD5B9EC63FC29F2A6F64DF4890AD141F50F8A0EE7B723AA23721ACC91D0637ACAFAAE8605091D81B51F25C9BBEB2129EBEC8DFCEAFF563C48879D09077AAFC438DF321C392DE01B6864EA24CB9FC4650ABE9BC0B03D44C88F12ED30DC9CB195D3B6C80D5A5BECC1552E788E623D5D9066D60A9A5F6CE516FD4FC915773C5B87916B4FC03396E952EC1E37F2326D93522DA143240ABE
2017-12-06 20:46:30 scdaemon[4159] DBG: chan_5 -> OK
2017-12-06 20:46:30 scdaemon[4159] DBG: chan_5 <- SETDATA --append 55DA1911DB12172A85F446CB0B5BE91B62F42A491632CF18B5B10FDED735C13E4731129069
2017-12-06 20:46:30 scdaemon[4159] DBG: chan_5 -> OK
2017-12-06 20:46:30 scdaemon[4159] DBG: chan_5 <- PKDECRYPT OPENPGP.2
2017-12-06 20:46:33 scdaemon[4159] operation decipher result: Missing item in object
2017-12-06 20:46:33 scdaemon[4159] app_decipher failed: Missing item in object
2017-12-06 20:46:33 scdaemon[4159] DBG: chan_5 -> ERR 100663364 Missing item in object <SCD>
2017-12-06 20:46:33 scdaemon[4159] DBG: chan_5 <- RESTART
2017-12-06 20:46:33 scdaemon[4159] DBG: chan_5 -> OK

If it is a reader problem - which one would work ?

For Gemalto USB Shell Token V2, libccid has known issue: https://ludovicrousseau.blogspot.jp/2017/03/gemalto-idbridge-k30-k50-ct30-and-zero.html
I don't know about ACR 38U.

Please note that RSA-4096 key requires large data, which causes troubles for many card readers, especially old one.

For in-stock CCID driver of GnuPG (not PC/SC), I have this list: https://wiki.debian.org/GnuPG/CCID_Driver
but this list is mainly created when people used RSA-1024 or RSA-2048, so, need update.

I still have trouble beliving it is the reader. Since I tried now 3.
As well I have a 4096 bit key and everybody has been encrypting this with my key. Therefore it does not make sense to me.

However - I belive you refrer to a problem with the large APDU. I now order a reader which should support this: https://pcsclite.alioth.debian.org/ccid/supported.html#0x04E60x5116
Lets see.

Hopefully I can tell you more in some days.

Thank you for your cooperation.

If it is somehow easy for you, with Gemalto USB Shell Token V2, it would be good try newer libccid: https://launchpad.net/ubuntu/+source/ccid

The new reader arrived. Works find for every message - except obviously this one sender.
See reader https://pcsclite.alioth.debian.org/ccid/supported.html#0x04E60x5116 ti should support large APDU. Same error messages
I think we are on the wrong error track here. It is not the reader. I now tested 4.

As well I spend some hours updating to Ubuntu 17.10 with libccid 1.4.27-1 . No change - same problem.
(Now I will spend some hours disabling ssh-agent and gnome keyring for ssh - never works like documented)

Again I have 4096 keys - everyone encrypting to me will generate large data. I have only one sender for which it fails.
This does not sound to me like it is a reader problem. It rather has to do with the sender.

Do you mean, GnuPG fails for a particular message, while it works for other messages?
Or do you mean, GnuPG fails for messages from a particular sender, while it works for messages from other senders?

To distinguish if its smartcard+reader issue or not, it may helps if you try decrypting with a key on host PC. If you have a backup of your key, could you please try decrypting a particular message (or messages from a particular sender) on host PC?

Im mean GnuPG fails for messages from a particular sender, while it works for messages from other senders.

To distinguish if its smartcard+reader issue or not, it may helps if you try decrypting with a key on host PC. If you have a backup of your key, could you please try decrypting a particular message (or messages from a particular sender) on host PC?

hmmm possible - will take some days. I will keep you posted.

Thanks a lot. Please note that there is a bit of possibility the messages which cause failure are one of attack vectors. (While most likely case is they are generated by broken implementation.)

Typical attack is to observe timing difference between success and failure to guess private key information.
While GnuPG on host (libgcrypt crypto computation) cares (some of) such attacks, some hardware implementation would not. Attacker would expect that.

I'm asking OpenPGPcard developer for error code.

Looking an example code of http://g10code.com/docs/openpgp-card-v21-free-source.zip (Note that this is just an example code), 6A88 can be occurred for PSO:DECIPHER when:

• SELECT command is not yet issued
• Decrypt key is not yet registered

I don't think latter applies here.

So, I wonder if the first case may occur in your environment.
Are you using other applications other than GnuPG for your smartcard access?

Either (or both) of follwing makes sense to locate the problem:

• Please disable such applications (for testing) and try again.
• Please disable pcscd (apt remove pcsd for testing) and try using the in-stock CCID driver of GnuPG with SCR3310 (which is supported by the driver)
  • You can put following lines in .gnupg/scdaemon.conf to get more debug information:

verbose
debug-ccid-driver

As said - it took me a while. Sorry for the delay.
I could dig out the Key in some archives. So I was able to test the decryption of the message on a computer without smartcard.
It worked.

Regarding attack vecotr. I know the person sending me the message. I strongly belive I´m not under attack.

If this still makes sense I will try debugging with the ccid- driver next.

All right - that was quicker.
I deinstalled pcscd (apt remove pcscd)
I changed .gnupg/scdaemon.conf as you proposed.
I tried again to decrypt the message (in the meantime I have a file) which works decrypting withoutl SmartCard when I use it on a pc with the key.
Still failed. Can I send you the Logfile encrypted ? If so - what is you eMail / key.

Thanks a lot for your testing. Here are my keys:

pub   ed25519 2015-08-12 [SC]
      249C B377 1750 745D 5CDD  323C E267 B052 364F 028D
uid           [ultimate] NIIBE Yutaka <gniibe@fsij.org>
sub   cv25519 2015-08-12 [E]
sub   ed25519 2015-08-12 [A]

pub   rsa2048 2010-10-15 [SC]
      1241 24BD 3B48 62AF 7A0A  42F1 00B4 5EBD 4CA7 BABE
uid           [ultimate] NIIBE Yutaka <gniibe@fsij.org>
sub   rsa2048 2010-10-15 [E]
sub   rsa2048 2010-10-22 [A]

Thank you for your efforts. Logfiles is in the mail

Thanks, I received the log file.

I can't find any problem in the transaction; The command APDU is:

CLA=00 INS=2A P1=80 P2=86 Lc=000201 (means 513-byte) DATA=[513-byte] Le=0800

and TPDU is correct.

But it returns the response APDU of 6A 88.

If the card works well, this result of 6A 88 can be only happened when the card is once SELECT-ed as OpenPGPcard application, then, for some reason, SELECT-ed as another. I wonder if you can find another line in the log, which is like:
scdaemon[5670] DBG: chan_5 <- SERIALNO undefined
or you have other applications which accesses the card.

Well, my speculation of SERIALNO undefined may be wrong.

Looking the log again, I focused the last part in the transaction:

2017-12-28 16:59:37 scdaemon[5670] DBG: ccid-driver:   // The command APDU sent
2017-12-28 16:59:40 scdaemon[5670] DBG: ccid-driver: RDR_to_PC_DataBlock:
2017-12-28 16:59:40 scdaemon[5670] DBG: ccid-driver:   dwLength ..........: 6
2017-12-28 16:59:40 scdaemon[5670] DBG: ccid-driver:   bSlot .............: 0
2017-12-28 16:59:40 scdaemon[5670] DBG: ccid-driver:   bSeq ..............: 101
2017-12-28 16:59:40 scdaemon[5670] DBG: ccid-driver:   bStatus ...........: 0
2017-12-28 16:59:40 scdaemon[5670] DBG: ccid-driver:   [0010]  00 40 02 6A 88 A0
2017-12-28 16:59:40 scdaemon[5670] operation decipher result: Missing item in object

It took three seconds.

I think that the card accepts TPDU correctly, and computes decrypted plaintext (in three seconds).

The possible case of 6A 88 returning OpenPGPcard is the decrypted plaintext does not conform to PKCS#1 format. Let me see how GnuPG decryption works in such a case.

OK, I got the picture, now.

GnuPG (on host PC) supports "old format":
https://dev.gnupg.org/source/gnupg/browse/master/g10/pubkey-enc.c;945381c4c26ffa5a9b1b0781294d0440e55d2ade$244

While the OpenPGPcard specification particularly requires conformance to PKCS#1 format, which is like:

0  2  RND(n bytes)  0  A  DEK(k bytes)  CSUM(2 bytes)

I think that your sender uses old PGP, perhaps.

Ok - thats good news.
Thank you very much for your analysis.

So the HOST PC accepts more than the card.
This means everything is o.k. only the sender has software using the old format.
Can you give a hint what he has to do / upgrade.
Maybe following Metadata helps with identifying what can be improved.

This is an OpenPGP/MIME encrypted message (RFC 2440 and 3156)
--Apple-Mail=_41DB5473-E14C-4C92-BFED-EEB0AF1F9CD4
Content-Transfer-Encoding: 7bit
Content-Type: application/pgp-encrypted
Content-Description: PGP/MIME Versions Identification

Version: 1

--Apple-Mail=_41DB5473-E14C-4C92-BFED-EEB0AF1F9CD4
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
	filename=encrypted.asc
Content-Type: application/octet-stream;
	name=encrypted.asc
Content-Description: OpenPGP encrypted message

-----BEGIN PGP MESSAGE-----
Comment: GPGTools - http://gpgtools.org

The conformance problem may (only) happen between PGP 2.6 and OpenPGPcard, because PGP 2.6 uses old format not compatible to PKCS#1, but OpenPGPcard requires PKCS#1.

I think that GPGTools never generates encrypted message in PGP2.6 format (I assume it's MacGPG2).

So, I wonder what's going on, actually.

The problem of decryption by OpenPGPcard is identified, I suppose. Let me consider more, how such a message can be generated by GnuPG.

Could you please give me the debug output line for DEK frame: by encrypted mail to me? So far, I can't find any likely scenario where an error occurs with smartcard. (Use of PGP2.6 is unlikely.)

On decryption with --debug=crypto flag, when your secret key is available on host PC, you can see something like following:

$ gpg --debug=crypto -o /dev/null -d encrypted-file.asc
gpg: enabled debug flags: crypto
gpg: DBG: DEK frame: 02 7A 23 42 FC BD 8D 11 30 16 94 7B DA 76 ED 5C 3D 64 22 6C 13 48 99 01 44 AA 07 C1 4B 4A 77 D0 2D B1 1D 8E 67 FB 2E 17 2D 40 11 59 27 13 C0 56 BF C4 0B 5E 23 23 52 63 B7 D1 DF B5 75 1F 28 1D DF 5E 56 77 60 70 6B B2 41 88 A6 A7 14 F4 F1 6E 9B 55 2F C1 CD 65 EB 1D 99 10 21 ED 98 99 D2 4D 7C 27 85 3C 7A 5E 5F 6F E0 8A 40 72 61 99 5F A6 81 9E D5 21 3D 57 26 A0 55 68 1B 16 02 7D 20 C5 56 2C 58 6B 41 47 32 6F F8 73 FC B0 E9 E4 58 11 BB F1 C0 F0 57 31 23 5E B6 AA 3F 69 8B 66 9B A1 6F FA E2 F9 60 6A 2A A4 BE E4 B5 28 BA 74 54 E6 26 05 8A 7E 3F A6 EA C4 7D B0 23 3B 6E A2 4E F4 CD 4B 20 3B 7C C8 EB 14 71 FF 41 07 71 EE 92 6F 61 3E 88 03 F0 46 CF 9A 6C B1 FD 90 3E 4C 7E E7 D6 C7 89 91 40 F2 11 5A D1 94 8A 92 8C E7 C6 06 A0 B3 B2 31 17 1B F8 98 FA 1B 04 51 72 F9 18 FC 25 22 72 65 0B E8 F5 16 B0 92 43 8F 16 F0 3B 93 4A E9 0A B7 E2 9D 02 3B 1E A3 37 86 8D EA D5 67 39 F4 61 87 0A A9 B2 A0 69 20 C6 71 5C E6 76 5E 13 C7 E8 2D 8F 26 05 2D F2 2A 26 53 F7 05 E3 61 60 63 BB E7 02 03 C5 C6 C1 8F 38 7A 9C 3A FE C6 1B B4 05 DD 1A B7 9A F4 42 3D 5D D7 C4 80 D0 75 6F BB FE 14 8C 02 EC D5 E7 85 4C F8 7C 55 02 EB A3 FA 8E 1A A6 3E 28 4F CA 75 70 49 C2 35 E9 71 6E 8D F0 11 96 0B A6 48 4D AD F3 DE 45 87 01 70 1A B5 F5 53 B2 62 39 80 C3 3C EA 9C EC EC DD 43 1E 7A 7A 9D AE A2 E6 97 47 8C 9D 43 A9 24 E3 B5 6F B0 4F F8 76 34 B4 17 DA AE 98 E1 60 E1 1F 0A 95 B7 78 CE E8 59 ED 1F 39 B4 67 48 6C 5D 27 B5 2B A8 57 03 C2 15 42 4F 4D 2C 76 00 09 3A 42 E9 92 BB 75 99 07 27 57 4C DF F7 25 F7 BE A3 F6 3C 7D BC 52 2D C1 CB 1C 7F 73 FD 6D 5D 6D 10 9C
...

The above output is created in my environment. It is correct format of PKCS#1 for RSA-4096 key; It is 511-byte (sans initial 0x00). It begins with 0x00, which is not shown, and next is 0x02, and has random bytes, then 0x00, DEK (256-bit) and checksum (16-bit).

Only a single line of DEK frame: is needed. Or, you can check the line by yourself. If it's correct format:

• 511-byte
• begins with 02
• has 00
• DEK of 32-byte (or 16-byte, depends on symmetric cipher)
• last two-byte

FWIW, the old format was only used up to PGP 2.3 . PGP 2.6 used the new format. This is actually more indication that the message has not been generated by an old PGP version.

I sent the gpg: DBG: DEK frame via encrypted eMail to you. Hope this helps.

OK. I managed to reproduce same behavior. I think that it is a bug of OpenPGP card implementation.
Here is the log:

Here is an extract of the log file which shows the assumed cause

gpg: DBG: DEK frame: 02 72 0B A8 5A 7F F6 A6 A8 45 4D 90 F3 CA 70 ED D7 E6 79 93 A0 14 E7 
[...] 8A 00 02 AA 1B BF 54 27 77 34 66 6E 2F F3 1D 51 C0 D2 43 FC 5A 38 44 CA 30 0C 5B 0A 16

This is the DEK with the leading 00 02 (the 00 is not shown here), followed by random bytes without a 00 where the last is 8A (second line), the 00 byte and a 02 byte indicating 3DES. Finally followed by the actual key and a 2 byte checksum.

So the assumption is it is an Error of the GnuPG card.
I tried today with an Yubikey 4 and it works. This confirms the theorie.
However - my preference is on the Smartcards. So how would we proceed now. Who can check for the error and correct it / flash a new version on a card.
I would offer to verify if it is fixed.

I forwarded the bug report to the OpenPGP card author.
I think that 2.0 card is OK, 2.1, 2.2, and 3.3 card have this bug.

FWIW, I ran the same test with three card versions:

1.1 - works
2.0 - works
2.1 - fails

Except for the 1.1 card I created new keys. The 2.0 card is one of the early test cards I once received from Achim, The 2.1 is card was acquired last year from floss-shop.

I also have the 2.1 Card which has this bug
Version ..........: 2.1
Manufacturer .....: ZeitControl

Can you exactly explain how you tested this?

I find your question confusing. I'm the reporter of this bug. All the efforts and tries of gniibe and myself are documented above.
Or do you refrer to something else ?

@werner It's just simple; With --personal-cipher-preferences 3DES (3DES only), make a encrypted message. Then, try to decrypt the message with OpenPGPcard (version 2.1 and later).

I guess that the sender (to @dirk) has this preference of 3DES only (for some reason).
Because this is not common, this problem of OpenPGPcard has not been found.

Oh dear what an evening and morning. I reversed the facts I reported. Sure 2.1 is borken - that is the whole point. ( I realized that only after install 2.2.4 and generating fresh keys). To avoid confusion I will delete my last comments.

Hello again,

I got myself OpenPGP Version 3.3 cards because I was under the
impression this was only on V2.1 and earlier cards.

Under a lot of pain I upgraded my airgaped machine to GPG 2.2.5 compiled
with option --enable-ccid-driver
to work around the problem the key could not be moved to the v 3.3 card.

Finally I made it.

And surprise. I try to decrypt the same message as before:

gpg: encrypted with RSA key, ID 1D8A5AD0E73625F2
gpg: encrypted with 4096-bit RSA key, ID F172E00269895FA1, created
2016-12-29
     <xxx@o.banes.ch>"
gpg: public key decryption failed: Missing item in object
gpg: decryption failed: No secret key

When will it be fixed ?

best regards

Dirk

New cards will come with a fix. I am not sure whether a production run has yet been done, though.

However - and that is important - you should tell the sender of the message that the use of 3DES is a bad idea and should be avoided under all circumstances. The OpenPGP specs still say that 3DES is a mandatory and fallback algorithm, but in the real world it is not used anymore. Some widely used OpenPGP implementations even support only AES and not 3DES.

Recent gpg versions will even print a warning when you encrypt more than 150 MiB with 3DES This is demanded by NIST recommendations.

Hallo Werner,

thanks for the insight that 3DES should be not used.
This is why I proposed to the OpenPGP working group mailing list to
disregard it use in the future for encryption - only  backward
compatiblity it should be used.

However - as you say it is in the standard. The Card has to support it.

Please inform here by when a defect free card can be bought.
Or who else can give this information ?

best regards

Dirk

Does v3.3.1 fix this? (The release notes for it seem to imply that's not the case.)

Now there it gets complicated. According to the card software author in 3.3 and even 2.2 there is a fix. BUT there was a small amount of cards already created in 3.3 without the fix. Nobody ever told my how to diferentiate them.
There is no Version 3.3.1 you can by - it is only 3.3. So you can buy one and hope you have a good one.
At least this is my understanding.