Along with the publication of an interesting new side channel attack by Daniel Genkin, Adi Shamir, and Eran Tromer we announce the availability of a new stable GnuPG release to relieve this bug: Version 1.4.16. This is a *security fix* release and all users of GnuPG versions 1.x are advised to updated to this version. GnuPG versions 2.x are not affected. See below for the impact of the problem. See also http://lists.gnupg.org/pipermail/gnupg-users/2013-December/048500.html Reproducible: Always
Forgot to add link to the actual paper in the initial report: From the CHANGELOG: * Fixed the RSA Key Extraction via Low-Bandwidth Acoustic Cryptanalysis attack as described by Genkin, Shamir, and Tromer. See <http://www.cs.tau.ac.il/~tromer/acoustic/>. [CVE-2013-4576]
Added
(In reply to Alon Bar-Lev from comment #2) > Added ready for stabilization?
(In reply to Mikle Kolyada from comment #3) > (In reply to Alon Bar-Lev from comment #2) > > Added > > ready for stabilization? well... the diff between versions is not trivial. * Fixed the RSA Key Extraction via Low-Bandwidth Acoustic Cryptanalysis attack as described by Genkin, Shamir, and Tromer. See <http://www.cs.tau.ac.il/~tromer/acoustic/>. [CVE-2013-4576] * Put only the major version number by default into armored output. ^^^^ I am unsure about impact. * Do not create a trustdb file if --trust-model=always is used. * Print the keyid for key packets with --list-packets. * Changed modular exponentiation algorithm to recover from a small performance loss due to a change in 1.4.14. ^^^^ not trivial at all.
If you are more comfortable with a patchset it should be able to fix the issue in the CVE by the application of two patches from upstream: (i) http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=93a96e3c0c33370248f6570d8285c4e811d305d4 , and (ii) http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=d0d72d98f34579213230b3febfebd2fd8dff272b Note: I haven't tested that cherry-picking only these two actually compiles, but those are the ones that should be relevant for the CVE, and I know that a similar approach has been used by Debian ( you can e.g. see dsc diff at http://packages.debian.org/squeeze/gnupg for 1.4.10-4+squeeze4)
I think we should give some time for people to test.
added to existing glsa draft
It has been about a week. Do we need more time for testing? Or are we ready to stable the package.
CVE-2013-4576 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-4576): GnuPG 1.x before 1.4.16 generates RSA keys using sequences of introductions with certain patterns that introduce a side channel, which allows physically-proximate attackers to extract RSA keys via a chosen-ciphertext attack and acoustic cryptanalysis during decryption. NOTE: applications are not typically expected to protect themselves from acoustic side-channel attacks, since this is arguably the responsibility of the physical device. Accordingly, issues of this type would not normally receive a CVE identifier. However, for this issue, the developer has specified a security policy in which GnuPG should offer side-channel resistance, and developer-specified security-policy violations are within the scope of CVE.
Maintainer timeout. Arches, please test and stabilize: =app-crypt/gnupg-1.4.16 Target arches: alpha amd64 arm hppa ia64 ppc ppc64 sparc x86. Thanks!
(In reply to Chris Reffett from comment #10) > Maintainer timeout. Arches, please test and stabilize: > =app-crypt/gnupg-1.4.16 > Target arches: alpha amd64 arm hppa ia64 ppc ppc64 sparc x86. Thanks! I don't quite understand this one - gnupg isn't slotted - and at least on arm, 2.0+ is already stable. Is there really a reason to go back and install/stable 1.4.16, since it will just bump to 2.x on the next upgrade cycle?
As one of the crypto herd, yes, there is still a point to have stable releases in the 1.4.x series: it's used in some scripting cases where the 2.0 changes didn't quite work out. When 2.1 comes out, I'm hoping that's different.
I'd rather expect a 1.5 series based on libgcrypt but not the additional library dependencies (libassuan -> pinentry, gpg-agent, etc) as a replacement. Granted that is more of a question of whether gnupg should be slotted than related to this bug per se. Fwiw, Werner suggested a 2.1 release before summer this year during FOSDEM (but that wouldn't replace a 1.4/1.5, only the 2.0 series)
The only reason to use 1.4 series is for static and/or monolithic configurations. I am not aware of any functionality lose in 2.x.
@alon: 2.x does indeed add functionality (in particular related to gpgsm) but it also add dependency complexity. There are several users that want to stick to 1.4/1.5 to avoid gpg-agent and pinentry e.g. for server systems. Granted 2.1. offers pinentry-mode=loopback, but as this isn't isn't in the main branches yet, e.g. automatic scripts still prefer 1.4/1.5.
Stable for HPPA.
amd64 stable
x86 stable
ppc stable
ppc64 stable
sparc stable
arm stable
alpha stable
ia64 stable. Maintainer(s), please cleanup. Security, please vote.
Added to existing glsa deaft already.
Cleanup done by alonbl
This issue was resolved and addressed in GLSA 201402-24 at http://security.gentoo.org/glsa/glsa-201402-24.xml by GLSA coordinator Chris Reffett (creffett).