IIRC, rfc2440 did not forbid partial length encoding for key-material so gpg could use that. rfc4880 limits partial length encoding to non-key-material which causes this error message.

Well, I'd expect gpg not to alter my digest/compression preferences when changing my cipher preferences and vice versa. So if a user's going to have to lose his previously set preferences for a key in this manner because that's the only reasonably viable way of maintaining backwards compatibility, I think it would be appropriate to let him know beforehand and also suggest that he set it all up at once (as I've so described above) so that nothing is lost in the process.

The way the setpref command works is implementation specific and thus the OpenPGP standard is irrelevant here
.
Are you requesting a change in the behaviour of the setpref command? That would not be easy to implement for backward compatibility.

Well, iff we implement that for gpg we also need to implement it for gpgsm.

A decision must be made what the desired behaviour should be.

• marcus (Marcus Brinkmann) <noreply@dev.gnupg.org> [20170622 16:41]:

So, the default change 7y ago and the world didn't end. Closing this.

So, the default change 7y ago and the world didn't end. Closing this.

Tested this again with 2.1.18 and it works now as expected. Export secret key
just exports a key if it has no passphrase. So I think this issue can be marked
as resolved.

It is a hack in OpenKeychain to allow the use of several devices. Frankly, I am
not sure whether this is really a good idea: The security is limited by the key
for the least secure device.

So i've tested this locally with:

    export GNUPGHOME=$(mktemp -d)
    gpg --quick-gen-key 'test user <test@example.org>'
    gpg --armor --export-secret-key 'test user <test@example.org>'

(choosing no passphrase during the prompts that come up during the quick-gen-key
step). The final export step works fine.

Can you show what steps you're taking that fail for you, Andre?

I'm using latest master and I still can't export a secret key without passphrase.

And Justus also has not closed this bug or wrote that he commited something
more. So I think the 2.1.13 announcement was mistaken and this problem still
exists. (Or am I missing some option / need a different pinentry mode?)

We got it for 2.1: -f or --recipient-file

Hi,
the 2.1.13 announcement has
"""

• gpg: Allow export of non-passphrase protected secret keys.

"""
(from https://lists.gnupg.org/pipermail/gnupg-announce/2016q2/000390.html)
so this defect may be fixed with 2.1.13 I guess, cool!
Probably only need a test to confirm?

Replacing revoked keys made me wonder if we actually need an auto-refresh key.
If we try to return one valid key with --locate-keys wouldn't it make more sense
semantically if we use the auto-key-locate mechanisms with locate-keys when a
key is expired in the local store?

This would also work better for revoked keys where a Parcimonie style auto
refresh would pick up the revocation and locate-keys would then look for a new key.

I can confirm one defect with 2.1.11:
The ability to export a secret key without passphrase available in gnupg2.0
is gone. My use case is to write a testcase that automatically imports the key.

I did not work on this other than what I merged. What I did is to enhance our
fake pinentry program to allow it to supply different passphrases, make it write
a log so that we can quantify the pinentry interaction in test cases, and to add
an export test documenting the status quo.

The question at hand is whether dkg's patch or Justus work is the way to go. I
have not yet reviewed dkg's patch, though.

dgk: You are right that Pinentry may be used even with --batch. In fact gpgme
uses --batch and a Pinentry is used nevertheless.

Right, there are no technical means right now to inhibit the export of private
keys. However, it would be easy to add this by not allowing gpg-agent to tell
the client the key used to encrypt the import/export command of keys.

A user migyt have used no passphrase for a key in the believe that an
unprotected key can't be exported.

I'm not convinced that this policy is effectively implemented in gpg-agent.

The patch series that starts here:

https://lists.gnupg.org/pipermail/gnupg-devel/2016-May/031121.html

resolves the export of secret key material stored as cleartext, and it does so
without modifying gpg-agent at all.

fwiw, I do not agree with T2324 (justus on Apr 18 2016, 05:22 PM / Roundup) that gpg --batch should not use pinentry at
all -- i think it's quite useful to be able to combine --batch with pinentry,
where the key is stored protected, or is otherwise marked by gpg-agent for
limited use.

re: T2324 (justus on Apr 18 2016, 05:22 PM / Roundup)

2. gpg --export-secret-key should export unprotected keys that are stored w/o a passphrase"

That would violate the policy we implement in gpg-agent. The
gpg-agent is responsible for private keys and a client may not use a
private key without the agent's consent. If we would allow that by
default there won't be any protection at all and keys can be easily
exported and used. A required confirmation via the Pinentry would
solve the practical problem. However, there is the question what to
do on unattended systems - the only way it can be done right now is
configuring gpg-agent to use a custom pinentry, or by extending the
loopback mode.

Werner: Yes please.

I have some stashed work to fix this but it is not ready - let me know if you
want to work on it.

*See also T2070

See also issue20170

I understand the reason for re-encrypting -- i'm quite happy that the agent is
sensible about improving the security of the key when it adopts it.

my concern is that users don't know what to expect, and that different workflows
result in different sets of keys stored in the agent.

So i'd recommend that when importing without --batch, if the password fails for
any reason, gpg should fall back to the fast migration "kludge" rather than just
skipping that keyblock. That way the imported secret key material will still be
available and can be cleaned up/hardened on first successful use.

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").