mailing list archives
CVE request: parcimonie (0.6 to 0.8, included) possible correlation between key fetches
From: intrigeri <intrigeri () boum org>
Date: Mon, 10 Feb 2014 16:52:34 +0100
Holger Levsen <holger () layer-acht org> discovered that parcimonie ,
a privacy-friendly helper to refresh a GnuPG keyring, before version
0.8.1, is affected by a design problem that undermines the usefulness
of this piece of software, in the intended threat model. I am upstream
for parcimonie, and I maintain it in Debian.
Type of the vulnerability: information disclosure.
Description: when using parcimonie with a large keyring (1000 public
keys or more), it would always sleep exactly 10 minutes between two
key fetches. This is likely to be fingerprintable by an adversary who
can watch enough key fetches, who can then correlate multiple key
fetches with each other, which is the exact situation that parcimonie
aims at protecting against. It happens that such an adversary is part
of the threat model parcimonie is meant to cope with. This problem is
slightly mitigated by the fact that most users likely use a HKP(s)
pool as their configured GnuPG keyserver (so their successive requests
have good chances to be sent to different keyservers), and the fact
that each key fetch is done using a different Tor circuit.
Upstream bugfix: commit 8931fdcf868c37e2e8d44324d5514d235a6d5c89 in
Versions affected: from parcimonie 0.6 to 0.8, included. Fixed in
This problem was made public in Debian bug #738134 , and was
described in details in the commit message for the upstream bugfix.
Could you please allocated a CVE id for this?
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
- CVE request: parcimonie (0.6 to 0.8, included) possible correlation between key fetches intrigeri (Feb 10)