While evaluating the "Get Your Hands Off My Laptop"  paper I missed
to describe  a software combination which has not been fixed and is
thus vulnerable to the attack described by the paper. If you are using
a GnuPG version with a *Libgcrypt version < 1.6.0*, it is possible to
mount the described side-channel attack on Elgamal encryption subkeys.
To check whether you are using a vulnerable Libgcrypt version, enter
on the command line; the second line of the output gives the Libgcrypt
gpg (GnuPG) 2.0.25
In this example Libgcrypt is vulnerable. If you see 1.6.0 or 1.6.1 you
are fine. GnuPG versions since 1.4.16 are not affected because they do
not use Libgcrypt.
The recommendation is to update any Libgcrypt version below 1.6.0 to at
least the latest version from the 1.5 series which is 1.5.4. Updating
to 1.6.1 is also possible but that requires to rebuild GnuPG.
Libgcrypt 1.5.4 has been released yesterday ; for convenience I
include the download instructions below. A CVE-id has not yet been
Many thanks to Daniel Genkin for pointing out this problem.
To re-cap, this seems to be fixed in
1.5.4 which was added to the tree in bug 519350 but has not yet been stabilized and the 1.6 series.
Arches, please stabilize
Target stable keywords: alpha amd64 arm hppa ia64 ppc ppc64 sparc x86
Why does 1.5.4 have a different SLOT? It conflicts with 1.5.3 on /usr/lib/libgcrypt.so.11
(In reply to Jeroen Roovers from comment #2)
> Why does 1.5.4 have a different SLOT? It conflicts with 1.5.3 on
indeed... it was a copy of, added due to bug#513718
it probably a mistake.
Seems to be intentional:
Multilib, why do we use slots such as this? or I should revert bug#513718 changes?
ok, deferred multilib changes to later (libgcrypt-1.5.4-r100).
libgcrypt-1.5.4 is exact copy of libgcrypt-1.5.3 now.
The SLOT=11 contains just the library for pre-built software compatibility, i.e. that you can install 1.6* and 1.5* at the same time because you want to use 1.6* but some binary software was linked to .so.11.
(In reply to Michał Górny from comment #6)
> The SLOT=11 contains just the library for pre-built software compatibility,
> i.e. that you can install 1.6* and 1.5* at the same time because you want to
> use 1.6* but some binary software was linked to .so.11.
Do we need to keep this forever?
(In reply to Alon Bar-Lev from comment #7)
> (In reply to Michał Górny from comment #6)
> > The SLOT=11 contains just the library for pre-built software compatibility,
> > i.e. that you can install 1.6* and 1.5* at the same time because you want to
> > use 1.6* but some binary software was linked to .so.11.
> Do we need to keep this forever?
No, just as long as there are binary packages that require it :).
$ grep -R -l libgcrypt.*:11
Stable for HPPA.
Maintainer(s), please cleanup.
Security, please add it to the existing request, or file a new one.
New GLSA request filed.
+ 24 Aug 2014; Kristian Fiskerstrand <email@example.com> -libgcrypt-1.5.3.ebuild:
+ Cleanup vulnerable versions for security bug #519396
This issue was resolved and addressed in
GLSA 201408-10 at http://security.gentoo.org/glsa/glsa-201408-10.xml
by GLSA coordinator Kristian Fiskerstrand (K_F).