We should not backport this to 2.2; better update to the current stable version (2.4)

Using Ubuntu, it's GnuPG 2.2 (which doesn't have the fix of T4585). Without the fix, killing gpg (by CTRL-C) causes problematic situation where pinentry remains asking.
That's because gpg-agent and pinentry don't know the frontend side has been killed. T4585 introduced a watching thread into gpg-agent, so that it can correctly detect lost of frontend.

Hi @gniibe - thanks for your fix.

Pushed the fix for SIGINT handling of pinentry-tty and pinentry-curses by: rPa6f63fe37dbf: tty,curses: Upon SIGINT, let pinentry exit gracefully.
This fix should improve the situation.

Thank you for the report.
I found a bug in pinentry-curses and pinentry-tty for handling SIGINT. I am going to fix this.

In T6085#162923, @ikloecker wrote:

In T6085#162918, @ebo wrote:

well, when creating openPGP keys with kleopatra I did not see any hints. I do not think that the issue would be vaild for password based encryption. There the common usecase is autogeneration, anyway

Autogeneration isn't viable if an organization has stupid password constraints that the autogenerated passwords do not satisfy. In particular, the autogenerated passwords do not contain any non-alphanumeric characters, but many password policies require such a character.

Currently, Kleopatra cannot do anything about this. get_passphrase in protect-tool.c asks those questions and doesn't support a way to give the user more context (e.g. by providing the file name). Once gpg-agent allows giving context, Kleopatra can add for example the file name to the data to import.

Applied to master.

Applied to 2.4.

yes, one down, two to go...

Meanwhile the AppImage (same binaries as the current Gpg4win version) can be found here among the binary releases: https://gnupg.org/download/index.html

@jukivili Good to know.

My vote would be to invert the logic of the last patch and add "no-hashing-in-parallel" as a compatibility flag and make the other behavior default and then to push it at least to master or even to 2.4.

There are some more surprising results like on my windows test keyring it would always report "5 new signatures" regardless of how often I ran the script ;)

Update the patch to allow --compatibility-flags hashing-in-parallel.

Problem with SHA-256 on x86-64 is that it took long time for Intel to introduce SHA acceleration (SHA1 & SHA256) to their main CPU products.

Fixed in master.
Will backport into 2.4, after testing.

So some more data from 2.4.3. Once unpatched and once with your patch.

Am I correct that the reason for the speed up is that it can use a second CPU's engine. If there is a real performance improvement here, we should add this for example using a --compatibility-flag. This way we can gather experience and eventually make it the default. The compatibility flags won't introduce an API incompatibility.

I found this important to do because the SHA-256 results from your test looked extremly slow.

For comparison here are my benchmark results on the same system. Once on Linux 64 bit and once on W32 and once with W64. All runs are native to exclude any virtualization issues.

Updated the patch:

I did a little bit of testing with okular, and it kind of gives similar numbers.

This is a patch for master (which uses nPth for gpg):

I'm trying to use a thread for computation of hashing. It works, but no performance gain, due to nPth.
I do:

npth_unprotect ();
gcry_md_write (mfx->md, mfx->buf, mfx->written);
npth_protect ();

to expect hashing is done in parallel.

It seemed I was wrong that it is due to buffering.
In the use case of --sign and --encrypt, hashing is done with IOBUF's 64KiB buffer (already).

I observed the benchmark by libgcrypt (Windows emulation 32-bit on Debian):

OK. I'll take the signing part (possible performance improvement).

I looked through the code. What I observed is:

• By jussi's improvements, AEAD code is optimized with AEAD_ENC_BUFFER_SIZE of 64KiB
  • this contributes much for better performance
• If we invoke gpg --sign | gpg --encrypt then we can take advantage of multiple CPUs (but gpg is currently not automatically threaded in that way)
  • signing could be improved likewise, using larger buffer like 64KiB
• CFB+MDC, it uses two functions together; encryption and hashing, and not with larger buffer like 64KiB
  • when signed, it also does hashing for signing, so three functions

! In T6561#172087, @werner wrote:
FWIW, gpg shows the actual cipher and encryption mode with -v. For example

FWIW, gpg shows the actual cipher and encryption mode with -v. For example

In T6561#172083, @werner wrote:

s/CBC/CFB+MDC/

s/CBC/CFB+MDC/

See for T6545 for a new request to support IDP.

Thank you.
Applied to master, 2.4 branch and 2.2 branch.

Thank you.
Applied to master, 2.4 branch, and 2.2 branch.

I consider the entire idea of receiving a passphrase and data on the same channel to be a bad for security and robust coding. The whole thing is a historical oddity which we kept for the sake of mutt(1)'s legacy way of invoking pgp. Thus I won't consider 3) the best option.

To summarize, here is the situation:

• Ideally, it would be good to modify GnuPG and Emacs EasyPG to implement status handling and input handling in better way.

Ah, I see https://dev.gnupg.org/rG2f872fa68c6576724b9dabee9fb0844266f55d0d applies cleanly. I guess can go with that, although would prefer it if on the 2.4 branch.

Is there a commit we could backport downstream to 2.4.x? We've had quite a few reports of this.

To align the default expiration time with the BSI approval and other related software we change this now to 3 years.

The problem of hang of tests/openpgp/multisig.scm is solved by rGef4f22b9d98b: gpg: Graceful exit for signature checking with --batch.
But the problem itself is not yet solved.

It is reproducible by testing tests/openpgp/multisig.scm with keyboxd enabled (it hangs), with the modification of following.

I pushed the change which keeps old status report behavior to master.
Let me test the change.

looks simpler to me.

Hmm, for the latter this:

Orthogonally, here is possible change for GnuPG, if we need to support the workaround of compress-level 0 in ~/.gnupg/gpg.conf.

OK, here is my changes which always use make-temp-file (to avoid confusion between data input and passphrase input).

I use epg.el with the change of removing the wait:

Was resolved, see T4457

GnuPG is and can't be FIPS-140-3 compliant due to the way it is implemented. We may eventually employ the new hash-and-sign API of Libgcrypt to move into this direction but that has not yet been done. However, this also requires the use of the new indicator API and the, well, a RedHat kernel.

Pushed to GnuPG master. Let us test. For my machine of Debian GNU/Linux, Wine emulation (Windows 32-bit, Windows 64-bit), make check goes all well.
After confirming the implementation, I'd like to put it into gpgrt.

Will be in 2.4.2

@werner We could make the wait conditional on (equal epg-gpg-program "gpg"), that is, only when user has GnuPG 1.x.

Well okay, then I have no workaround. However, I won't consider this a bug because BEGIN_ENCRYPTION marks the start of the actual encryption process but not when it starts to read input data.

The change rG60963d98cfd8: gpg: Detect already compressed data also when using a pipe. for T6332 introduce IOBUF_IOCTL_PEEK.

@werner I tested by switch back to GnuPG 2.4.1 (I downgraded to 2.4.0 before to temporary work around issue), adding compress-level 0 to gpg.conf file. It's not working. The problem still exist.

I have not yet experienced that although I am using Gnus with encrypted mail all the time. My guess is that this is due to the improved compressed input detection in gpg. You might be able to work around it by adding compress-level 0 to gpg.conf

Just checked 2.4.1 and looks like now everything is OK.

works, Gpg4win-4.1.1-beta295

Sorry, the comment above is my misunderstanding.

For importing key/subkey case, it doesn't matter if the smartcard is connected or not. The data in the file will be overwritten by import.