This bug is CVE-2022-47629

Fixed Gpg4win version: https://lists.wald.intevation.org/pipermail/gpg4win-announce/2022/000098.html

As usual see https://gnupg.org/download for links to the latest packages. For Gpg4win see https://gpg4win.org

As 2.3.7 was released on the 11th of July, see https://lists.gnupg.org/pipermail/gnupg-announce/2022q3/000474.html
I guess that this issue should be closed and some issues moved to one with 2.3.8.

Updated the copy on our mirror as welll as the gpg4win and swdb packages files.

The fix is from 2018 but was not picked up widely; see
https://github.com/madler/zlib/commit/5c44459c3b28a9bd3283aaceab7c615f8020c531

SWDB updated - thus the latest zlib will be part of the next Windows build.

All 4 CVEs are findings related to standard conforming compiler optimizations which OTOH break long standing assumptions on C coding. “Let us show that our compiler produces the fastes code ever and ignore any assumptions coders had made over the last 50 year”.

Thanks for the clarification!

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

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!

CVE-2021-33560

Let me rephrase from a viewpoint of mine (an implementer).

The paper describes another problem: interoperability (or interpretation) of "ElGamal encryption", and its impact.

Do we have CVE number assigned?

This would be difficult to set up for DSA. Remotely controlled
environment, asking signing same message, using deterministic
DSA... would be not that practical.

So, in my opinion, applying the patch for ElGamal exponent blinding is enough (for now).

For DSA, I had assumed similar attack could be effective.

Our tentative plan is:

Fix has been released. Keeping this in testing state for easier visibility of this task.

Gpg4win 3.113 has also been released. Thus closing this issue.

Small correction: The fixed byte I talked about may have the values 1, 2, 3, or 4.

This has CVE-2020-25125

2.2.23 has been released and announced.

The fix will be in the 2.2.23 release (T5045).

FWIW, the second listed commit is the right one. You should only look at the STABLE-STABLE-2-2 branch. master and that branch differ; in particular we do not have a cut-off date in master (to be 2.3).

I am currently investigating the issue known as CVE-2019-14855 for Debian's LTS version Debian 8 "Jessie" and even Debian 7 "Wheezy".

That is due to the mitigation for CVE-2019-14855. I need to see how to find a more specific mitigation.

See https://minerva.crocs.fi.muni.cz/ for a description of the timing attack.

Thanks.
So what I remembered was 1 year and 1 month off the real EOL date.

Here is our announcement: https://lists.gnupg.org/pipermail/gnupg-announce/2018q2/000426.html

https://www.nccgroup.trust/us/our-research/technical-advisory-return-of-the-hidden-number-problem/

Informed Debian security team about our change of libgcrypt.

A new installer for GnuPG with Libgcrypt 1.8.3 is now available.

Releases are now available. Next task is to build a new GnuPG Windows installer.

1.8.3 and 1.7.10 are now released. Announcement will follow later the day.

Pushed fixes to the repository at 16:00+0900 (09:00+0200). It's 0700Z.

In master, it's

commit 9010d1576e278a4274ad3f4aa15776c28f6ba965
Author: NIIBE Yutaka <gniibe@fsij.org>
Date:   Wed Jun 13 15:28:58 2018 +0900

1.8.3 has not yet been released and thus there is no NEWS entries and there can't be a 1.8.3 tag. You are right that the README still says 1.7. I'll fix that for 1.8.3. Why do you think maintenance of 1.7 stopped; the AUTHORS file and the new EOL statements on the download page say that we are going to maintain it until 2019-06-30.

Publication is planned for the 13th, 1500Z

I just noticed, that a tag for Libgcrypt 1.8.3 seems to be missing: https://dev.gnupg.org/source/libgcrypt/tags/LIBGCRYPT-1.8-BRANCH/

Unfortunately 2.2.8 does not build with older libgpg-error versions. Commit rG18274db32b5dea7fe8db67043a787578c975de4d should fix this.

2.2.8. with a fix has been released. Announcement

[Better use the gnupg tag. Specific versions end up on the workboard and there may only be one.]

@dkg can you please take this up with Debian and other distros? See the commit for a brief description.