David Shaw <> Fri, 18 February 2011 02:43 UTC

Received: from (localhost []) by (8.14.4/8.14.3) with ESMTP id p1I2hCaI045526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Feb 2011 19:43:12 -0700 (MST) (envelope-from
Received: (from majordom@localhost) by (8.14.4/8.13.5/Submit) id p1I2hCfD045525; Thu, 17 Feb 2011 19:43:12 -0700 (MST) (envelope-from
X-Authentication-Warning: majordom set sender to using -f
Received: from ( []) by (8.14.4/8.14.3) with ESMTP id p1I2hAlc045518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <>; Thu, 17 Feb 2011 19:43:11 -0700 (MST) (envelope-from
Received: from ( []) (authenticated bits=0) by (8.14.4/8.14.4) with ESMTP id p1I2h7lS003818 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 17 Feb 2011 21:43:08 -0500
Subject: Re: DEADBEEF vs SHA1
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: David Shaw <>
In-Reply-To: <>
Date: Thu, 17 Feb 2011 21:43:07 -0500
Cc: IETF OpenPGP Working Group <>
Message-Id: <>
References: <> <>
To: Ian G <>
X-Mailer: Apple Mail (2.1082)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by id p1I2hBlb045519
Precedence: bulk
List-Archive: <>
List-Unsubscribe: <>
List-ID: <>

On Feb 17, 2011, at 6:56 PM, Ian G wrote:

> On 18/02/11 6:12 AM, David Shaw wrote:
> ...
>> In terms of the issue that originally started this thread, the proposal to include and compare the complete fingerprint resolves this attack as well (slightly better in this case, in fact, since a V3 fingerprint can't even accidentally collide with a V4 one).
> ...
>> That said, however, (and switching over to implementation thoughts here) given how easy it is to make a V3 DEADBEEF key that collides with a real V4 key, I wonder if it would also be useful for implementations to simply refuse (or at least give the option to refuse) to import any V3 keys.  That might not have been feasible 10 years ago, but nowadays, I suspect most people would not even notice.  Standards-wise, that is fine as 4880 does not require V3 (discourages it, in fact: MUST NOT create, and only MAY accept).
> Two thoughts.  One is that we're not only dealing with code, we're also dealing with data:
>  * People have stored files encrypted to V3 keys (this is to conflate storage security with transport security, but that was common thinking in PGP world).
>  * typically, people have expected things like digital signatures masquerading as human signatures to survive a long time.
>  * some standards require 30 years of technology lifetime.

So those (few, I suspect) people who actually need V3 capability can switch it back on again.  This isn't really a standards question, as 4880 doesn't mandate V3 support.  Any implementation that wants to add a knob to turn it on or off is free to do that.

In the meantime, we cut off a extremely easy denial of service attack.