Thank you for your report and the log, but it doesn't have useful information so
that I can debug.

The information of card reader is required, if the problem happens for specific
card reader only. Please include full log which includes card reader information.

There seems to be a problem with your reader. We would need to closer analyze
the log (which I copy below):

DBG: send apdu: c=00 i=A4 p1=00 p2=0C lc=2 le=-1 em=0
DBG: ccid-driver: PC_to_RDR_IccPowerOn:
DBG: ccid-driver: dwLength ..........: 0
DBG: ccid-driver: bSlot .............: 0
DBG: ccid-driver: bSeq ..............: 145
DBG: ccid-driver: bPowerSelect ......: 0x01 (5.0 V)
DBG: ccid-driver: [0008] 00 00
DBG: ccid-driver: RDR_to_PC_DataBlock:
DBG: ccid-driver: dwLength ..........: 21
DBG: ccid-driver: bSlot .............: 0
DBG: ccid-driver: bSeq ..............: 145
DBG: ccid-driver: bStatus ...........: 0
DBG: ccid-driver: [0010] 3B DA 18 FF 81 B1
DBG: ccid-driver: [0016] FE 75 1F 03 00 31 C5 73 C0 01 40 00 90 00 0C
DBG: ccid-driver: PC_to_RDR_XfrBlock:
DBG: ccid-driver: dwLength ..........: 4
DBG: ccid-driver: bSlot .............: 0
DBG: ccid-driver: bSeq ..............: 146
DBG: ccid-driver: bBWI ..............: 0x00
DBG: ccid-driver: wLevelParameter ...: 0x0000
DBG: ccid-driver: [0010] FF 11 18 F6
DBG: ccid-driver: RDR_to_PC_DataBlock:
DBG: ccid-driver: dwLength ..........: 4
DBG: ccid-driver: bSlot .............: 0
DBG: ccid-driver: bSeq ..............: 146
DBG: ccid-driver: bStatus ...........: 0
DBG: ccid-driver: [0010] FF 11 18 F6
DBG: ccid-driver: PC_to_RDR_SetParameters:
DBG: ccid-driver: dwLength ..........: 7
DBG: ccid-driver: bSlot .............: 0
DBG: ccid-driver: bSeq ..............: 147
DBG: ccid-driver: bProtocolNum ......: 0x01
DBG: ccid-driver: [0008] 00 00 18 10 FF 75 00 FE
DBG: ccid-driver: [0016] 10
DBG: ccid-driver: RDR_to_PC_Parameters:
DBG: ccid-driver: dwLength ..........: 7
DBG: ccid-driver: bSlot .............: 0
DBG: ccid-driver: bSeq ..............: 147
DBG: ccid-driver: bStatus ...........: 0
DBG: ccid-driver: protocol ..........: T=1
DBG: ccid-driver: bmFindexDindex ....: 18
DBG: ccid-driver: bmTCCKST1 .........: 10
DBG: ccid-driver: bGuardTimeT1 ......: FF
DBG: ccid-driver: bmWaitingIntegersT1: 75
DBG: ccid-driver: bClockStop ........: 00
DBG: ccid-driver: bIFSC .............: 254
DBG: ccid-driver: bNadValue .........: 16
DBG: ccid-driver: PC_to_RDR_XfrBlock:
DBG: ccid-driver: dwLength ..........: 5
DBG: ccid-driver: bSlot .............: 0
DBG: ccid-driver: bSeq ..............: 148
DBG: ccid-driver: bBWI ..............: 0x00
DBG: ccid-driver: wLevelParameter ...: 0x0000
DBG: ccid-driver: [0010] 10 C1 01 FE 2E
DBG: ccid-driver: RDR_to_PC_DataBlock:
DBG: ccid-driver: dwLength ..........: 4
DBG: ccid-driver: bSlot .............: 0
DBG: ccid-driver: bSeq ..............: 148
DBG: ccid-driver: bStatus ...........: 0
DBG: ccid-driver: [0010] 00 82 00 82
DBG: ccid-driver: invalid response for S-block (Change-IFSD)
apdu_send_simple(0) failed: unknown host status error
DBG: send apdu: c=00 i=A4 p1=04 p2=00 lc=6 le=-1 em=0

Without pcscd running, I get a "Not supported" error. The scd.log is attached.
Using pcscd, it works, except for that special case.

debug 2048
debug 1024

is what I need.

Thanks. We need to know some more detailed information. Please
put

debug 2018
debug 1024
log-file /somewhere/scd.log

into scdaemon.conf, kill scdaemon and try again. It seems you have not yet been
asked for a PIN so the log won't reveal the PIN. Anyway, you may want to send
the log to me by PM (wk@gnupg.org - key 1e42b367).

Fails with 2.0.29 too, compiled from source. With enabled debug-all verbose in
scdaemon.conf, the log ends with:

2016-03-19 10:12:09 scdaemon[1988] DBG: response: sw=6A88 datalen=0
2016-03-19 10:12:09 scdaemon[1988] operation decipher result: Missing item in object
2016-03-19 10:12:09 scdaemon[1988] app_decipher failed: Missing item in object
scdaemon[1988]: chan_7 -> ERR 100663364 Missing item in object <SCD>
scdaemon[1988]: chan_7 <- RESTART
scdaemon[1988]: chan_7 -> OK

We should create a test case for trust signatures before we start to fix it.

The current version is 2.0.29 - please try again using this version.

Marking as resolved since this is available in 2.1 and we are not going to
backport this to 1.4 or 2.0. Thanks.

I guess you are reporting for GnuPG 2.0 or 1.4.
We already implemented your suggestion in 2.1.

Why is this a reasonable assumption? This proposal changes the way that GnuPG
has been working for years and will inevitably break someone's setup. It would
be much better for the receiver to use a non-critical notation to indicate the
desired behavior.

Please give me the output of lsusb -v -d 058f:9540
and debug log of scdaemon.
Do you mean --card-status works bug --decrypt fails?

There are no known attacks on SHA-1. MD5 is disabled anyway in recent versions.
But please continue at gnupg-users - if you like.

Thank you for the prompt response.

I am familiar with the standard. The only violation of a MUST I'm aware of is that
recipient and personal digest preferences are ignored for hashes with known attacks;
perhaps some of these changes cause GnuPG to behave badly in other cases?

This has been discussed at gnupg-users at lengths. You need to read the OpenPGP
standard to understand some of the defaults. For the others you may start yet
another disucssion thread at gnupg-users.

re 4) The iteration count used depends on the machine.

Sorry for the delay, the passphrase is 512 characters long (now I should change
it after publishing that here ;-)) and just ascii characters.

With GnuPG 1.x, Enigmail takes care of presenting the passphrase dialog.
With GnuPG 2.x GnuPG does it of its own. For that it spawns a small tool
called pinentry which asks for the passphrase. We actually have several
versions of that pinentry. The one you are using is based on Qt (a toolkit) and
has a limit of 256 bytes for the passphrase. The limit may actually be lower if
you are using non-ascii characters, but I can't see how that value is not
sufficient.

How long is your passphrase and does it contain many non-ascii characters (e.g.
Umlauts)?

Hello, Thank you for your reply.

I used the gpg4win-2.2.1.exe binary which I downloaded from gpg4win.org

The popup I mentioned is the screen that asks me for my password when I try to
open an encrypted mail in my mailbox via thunderbird/enigmail. See the
screenshot. In the newer gpg version this popup is replaced by a prompt screen
that says pinentry and will allow only for shorter passwords.

I understand that my password is exceptional long, as I still was (and maybe
still am) a beginner on the encrypted mail part. But backwards compatibility
seems pretty important in the case of encrypted mails and passwords to decrypt them.

What do you mean by "openpgp popup"?

Which installation options did you used whethn installing gpg4win? Depending on
the version you get a different pinentry version - we have a qt based one, a GTK
based base, and a very simple native windows pinentry.

Fix for 1.4.13 (commit 64e7c23).

Hello Werner,

Hallo Werner!

For the given use case you should ask the former employee to revoke the uid.
And in case you can't contact him, the signers may revoke their signatures
(--edit-key, "revsig").

We can't do anything about it.
Cards with manufacturer id 5 and serial numbers up to 346 (0x15a) are affected.
Newer cards work fine.

Done in trunk (2.1), rev 5233

This is now a known problem. The likely reason is bug in the card's code. The
workaround is to forget about card based 3072 bit encryption keys.

Does the fact that I can encrypt, sign, and authenticate correctly with 3072 bit
keys affect your hypothesis?

According to http://pcsclite.alioth.debian.org/shouldwork.html#0x0B970x7762
this reader should work but it has not been tested.

Is there any more information I can provide? Can you reproduce it?

This is the built-in reader in my Dell Latitude D430, by the way.

This is the relevant lsusb output:

What card reader are you using?

Closing this report. If further support is required, please reopen.

Note: It also works for gpgme_op_decrypt_verify, but the error code
GPG_ERR_NO_DATA needs to be ignored in this case. This is because we didn't get
a DECRYPTION_OKAY status message, and this is semantically the same as for a
signed but not decrypted file. We can consider making this case better in a
major upgrade when we change the ABI anyway, but not now.

Works fine for me with gpgme_op_verify, which actually runs the gpgme -o command
as you gave it. Did you rewind the output data object before trying to
read the data?

Marcus: Can you please check whether we can easily add this to gpgme_op_decrypt?

Background info: My e-mail program is currently calling gpg via fork() and
exec() and is thus very GnuPG version dependent. It does not create such
messages, but can display them. Trying to get rid of the version dependency,
I've tried to switch to GPGME and stumbled about a test message I've received
years ago. Unfortunately the header lines do not mention what mail program was
used for sending.

I was not aware that such OpenPGP messages are actually used. We need to see how
to implement that.