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.

Similar to T780 I guess.

Integrated into 2.0.

Fixed in 1.4 (r4445). I haven't integrated the fix to 2.0 yet.

David, I know you investigated this bug. What is the current status?

I don't have an immediate answer to this. Need to fire up the debugger.