Re: [openpgp] Bug#931238: hot armor: please drop "Version: " header

ilf <> Mon, 08 July 2019 10:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6F06C120152 for <>; Mon, 8 Jul 2019 03:49:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id M2drck9h_rxF for <>; Mon, 8 Jul 2019 03:49:00 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 098DD12014F for <>; Mon, 8 Jul 2019 03:48:59 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5ACB57CAAA5; Mon, 8 Jul 2019 12:48:56 +0200 (CEST)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id a-AqMHU6r086; Mon, 8 Jul 2019 12:48:56 +0200 (CEST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 203CD7CA980; Mon, 8 Jul 2019 12:48:56 +0200 (CEST)
Received: from [] (localhost [])ng TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 676C1BFE19; Mon, 8 Jul 2019 12:48:55 +0200 (CEST)
Date: Mon, 08 Jul 2019 12:48:52 +0200
From: ilf <>
Message-ID: <>
References: <> <> <> <> <>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="jRdC2OsRnuV8iIl8"
Content-Disposition: inline
In-Reply-To: <>
Archived-At: <>
Subject: Re: [openpgp] Bug#931238: hot armor: please drop "Version: " header
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 08 Jul 2019 10:49:05 -0000

Peter Gutmann:
> "An attacker knowing that you're running out- of-date software" barely 
> qualifies as a threat - they can just try and attack you anyway - and 
> I can't see what other purpose it serves. 

We had this debate three years ago over on gnupg-devel.

dkg posted a patch - which was merged in upstream GnuPG:

> The version of GnuPG in use is not particularly helpful.  It is not
> cryptographically verifiable, and it doesn't distinguish between
> significant version differences like 2.0.x and 2.1.x.
> Additionally, it leaks metadata that can be used to distinguish users
> from one another, and can potentially be used to target specific
> attacks if there are known behaviors that differ between major
> versions.
> It's probably better to take the more parsimonious approach to
> metadata production by default.

These were the original arguments:

> Since "Pervasive Monitoring Is an Attack" [2], let's minimize metadata 
> as much as possible, especially if it's unencrypted *and* not 
> cryptographically verifiable.
> The "OpenPGP Best Practices" [3] refer to a gpg.conf [4] 
> which already implements "no-emit-version". I and many other people have 
> been using this with many implementations on many plattforms for a long 
> time, without any problems. So I see no technical reason against the 
> proposal.
> Even RFC 4880 lists no pressing reason for including this by default:
>> The Armor Headers are pairs of strings that can give the user or the 
>> receiving OpenPGP implementation some information about how to decode 
>> or use the message. [5]
> I can't see how "Version: GnuPG v2" tells me or an OpenPGP 
> implementation "how to decode or use the message".
> Let's just drop it.
> 2.
> 3.
> 4.
> 5.

After it was merged, a pratical attack was published:

> Werner Koch:
>> You are right, the "Version:" has no technical meaning.
>> I just pushed dkg's patch to master.
> Thanks again for this. Even after the decision, I want to add a 
> real-world example of why this change helps against de-anonymization:
>> Both "French Maid" and Force (operating as "Nob") used the exact same 
>> brand of PGP software, a free brand called GnuPG. There are different 
>> brands of PGP software so it is noteworthy that both Force (operating 
>> as "Nob") and "French Main" used the same brand. Not only did Force 
>> and "French Maid" both use the same brand of PGP software, they also 
>> both used the same outdated version of that software, 1.4.12. Version 
>> 1.4.12 was released on January 2012, and was replaced with a new 
>> version by December 2012, and was one of several versions of GnuPG 
>> software. As such, both "French Maid" and Force (as Nob) were using 
>> the specific, older version of the GnuPG software, and neither of them 
>> replaced it with the other (free) version of GnuPG that came out 
>> thereafter. […]
>> There are also additional similarities between Force's (Nob's) and 
>> "French Maid's" PGP patterns. Both "Nob" and "French Maid" left 
>> certain default settings on their PGP software. For one thing, both 
>> "French Maid" and Force (Nob) left a "tag" that appeared on every 
>> message authored from their PGP key revealing the brand and version of 
>> PGP software they were using. This is akin to, for example, leaving 
>> the phrase "sent from my iPhone" on the bottom of one's emails but 
>> with greater detail: it would be akin to leaving a phrase like "sent 
>> from my iPhone 6 iOS 8.0.1." Leaving this "tag" on typically reveals 
>> that one is dealing with a fairly inexperienced user of PGP, because 
>> someone that regularly uses PGP to communicate would normally have 
>> changed their settings to omit this tag.

After that, the OpenPGP "Version:" header was dropped across the 


To sum up:

- there is no valid technical reason for it
- there are active attacks which have put people in jail
- it's now ecosystem standard not to generate it

So please:

1. let's drop it by default in other implementations, like hOpenPGP
2. let's edit rfc4880bis to "SHOULD NOT emit a Version: header"


If you upload your address book to "the cloud", I don't want to be in it.