Thanks for the clarification!

Right, as long as there is only one format in widespread use (based on a long existing 4880bis draft) only this format should go over the wire.
Thus, it is a matter how the key is exported. In cryptography you should never have several options - one clearly defined format is what you want. We have had enough trouble with PGP5 peculiarities but in that case their implementation had more users and thus GnuPG had to work around it. Not good, but there was no standard at all at this time.

@onickolay No sorry needed. It was me, who cannot answer promptly.

It is related in the following way:
The Gpg4win installer creates these context menu actions through the component GpgEX.
The Gpg4win installer does not support Windows XP anymore.

The problem of (2), is local side-channel attacks to ElGamal encryption.
We evaluated the impact, mainly for the use case of GnuPG; ElGamal keys are not that popular any more. When such an attack is possible, easier attacks would be possible.

The paper addresses two issues.
(1) https://ibm.github.io/system-security-research-updates/2021/07/20/insecurity-elgamal-pt1
(2) https://ibm.github.io/system-security-research-updates/2021/09/06/insecurity-elgamal-pt2

What I need is exactly ikloecker described on Linux. The point is NSIS installer gnupg-w32-2.2.27_20210111.exe (and versions above, I am sure) do not create context menu shortcut. Windows XP is not the point. Same on another Windows 7 machine. Do you need I find another windows 10 machine to test? I think it's easier to check whether the installer has that feature or not.

And well, the context area of the handle is also wiped at gcry_cipher_close time. Thus any standard use of aeswrap (open,encrypt/decrypt,close) is not affected.

Good catch. Thanks. This patch should fix the leak:

I looks like the "cipher: Hardening ElGamal by introducing exponent blinding too." commit [1] was never applied to 1.8.x. Is that intentional? If so, is there a specific reasoning that it's not needed in 1.8.x? Thanks!

@ikloecker
Thank you.
So it's a different issue.
Sorry, I was confused because after solving the gpg: can't connect to the agent I instantly got gpg: problem with the agent: End of file.

Symmetric decryption is broken in 2.3.2. See T5577: Null ptr dereference in gpg-agent (gnupg 2.3.2). Try 2.3.1.

@gniibe sorry for pinging, but this issue gets attention as TB users (with RNP OpenPGP backend) cannot import to GnuPG EdDSA secret key which was generated by RNP since it doesn't tweak bits when storing or exporting a secret key.
Should we update RNP to tweak those bits during storage to be more compatible (given that those bits doesn't make any difference)?

gpg: can't connect to the agent: IPC connect call failed

This problem with portable mode in Windows can be solved by creating additional gnupg folder near bin, home, share.
I don't know why, but gpg-agent v2.3.2/2.2.30 in Windows in portable mode creates files S.gpg-agent.* in gnupg, not in home folder. And it doesn't work without gnupg folder.

My suggestion for a combined function is a simple:

Yes, --no-keyring should enough for the subset of gpg commands which do not need keys.

Sorry, GnuPG proper has no context menu or any graphic user interface. You need to install Gpg4win for this. Regarding use of gpg by other programs: There has been no change - other programs need to use the status-fd/command-fd interface and that has always been defined as UTF-8 and not as any native codepage. Please ask the makers of The Bat what is going wrong there.

2021-09-13 Update:

• Signature operation tested: RSA-PSS, RSA-PKCS#1-v1.5, RSA-X9.31, ECDSA by NIST Curves, DSA (against CAVS test vectors in FIPS 186-4)
  • Newly added features (also useful for standard API of sexp):
    • Support of X9.31 signature scheme with RSA
    • Support of supplying random "k" for DSA/ECDSA
    • Digest mode ASN for SHA512-224 and SHA512-256 (required for RSA PKCS#1-v1.5)

I have one more patch set to improve FIPS testing in test/curves.c. In the past, it was basically skipped altogether in FIPS mode. This implements more fine-grained selection of what is being tested. This is the first part.

The breakaway job notices should definitely only be emitted in verbose mode. For the other things I need to check.

Few more logs from 2.3.2 and 2.2.29 (for comparison):

I'm not sure that the portable mode is a culprit here.
Something is very wrong with gpg-agent/pinentry.
Even symmetric decryption doesn't work in 2.3.2/2.2.30:

In T1621#149541, @werner wrote:

GnuPG stable (i.e. 2.3.2) has full support for several readers and tokens. This won't be backported to the LTS versions (2.2), though. Better switch.

GnuPG stable (i.e. 2.3.2) has full support for several readers and tokens. This won't be backported to the LTS versions (2.2), though. Better switch.

I've recently acquired two Yubikeys: one Yubikey 5 NFC from my workplace, and shortly after, I bought a Yubikey 5C for my own personal keys… both security tokens have _different_ keys on them. (There are some questions being asked regarding the use of the same GnuPG key duplicated on separate smartcards; this is a different case).

Woops, :-s I forgot to also add all these details from additional investigations I already did (obviously assuming it might be helpful ones for definitely fixing issue I reported (and my apologies in advance for whom might find lenght of all this really excessive, 8-) since I simply tried to comprehensively summarize results...)

The fix works for me (using bash on openSUSE Tumbleweed).

My apologies for further delay before also providing this screenshot bitmap of error found (because of initially not finding specific site info about best browser to use and not seeing 'cloud symbol' (many thanks werner :-D ) I obviously had to switch from IE11 to MSEdge and then also manually import proper cookies needed for this site :-(( )

Interesting idea.

Here is a possible fix:

No support for Windows XP anymore.

How difficult would it be to teach gpg-agent to fall back to another SSH agent if given an unsupported key?

Sorry, I should clarify that I am using the windows installer
gnupg-w32-2.2.27_20210111.exe on WindowsXpSp3. The installer do not create
any context menu since I use it. I use Gnupg with Enigmail in Thunderbird,
so Gpg4win is not preferred.

I verified that manually putting the DB in WAL mode also resolved this issue, since writers don't block readers in WAL mode.

This is a hard to solve problem in the NSIS installer: If you accidently started more than one installer they may both register files for update at the next restart. Now after the restart the file which is to be renamed does not anymore exist and thus a component or even library is not available. In this case it is GpgEX, the explorer plugin.

In the editor you find a cloud symbol with an arrow to upload a file. Use this and and the file id will be pasted at the cursos, like here

Apologies for my (newbie) comment on this bug reporting system. Since I have a screen shot bitmap better showing error I described, could anyone tell me how to attach to this bug ?

Finishing development for now.

Please talk to the KDE folks who develop Craft. We do not support building anything with Craft. Check out gpg4win (https://dev.gnupg.org/source/gpg4win/) to see how we build our products on Windows.

Which product do you refer to? Kleopatra? gpg4win? Something else?
Which operating system are you using? Windows? Linux? Something else?

The major problem I see is that an implementation needs to add more crypto primitives to support ths curve. And we can expect that 448 will eventually get in widespread use. We already have all primitives but would inhibit the creation of minimal implementations.