Re: DEADBEEF vs SHA1 Fri, 18 February 2011 00:23 UTC

Received: from (localhost []) by (8.14.4/8.14.3) with ESMTP id p1I0NXfo039192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Feb 2011 17:23:33 -0700 (MST) (envelope-from
Received: (from majordom@localhost) by (8.14.4/8.13.5/Submit) id p1I0NXNB039191; Thu, 17 Feb 2011 17:23:33 -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 p1I0NWu9039185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <>; Thu, 17 Feb 2011 17:23:32 -0700 (MST) (envelope-from
Received: from (localhost.localdomain []) by (Postfix) with SMTP id DB2E7C011A for <>; Fri, 18 Feb 2011 00:23:31 +0000 (UTC)
Received: from ( []) by (Postfix) with ESMTP for <>; Fri, 18 Feb 2011 00:23:31 +0000 (UTC)
Received: by (Postfix, from userid 99) id 644C410E2B7; Fri, 18 Feb 2011 00:23:31 +0000 (UTC)
MIME-Version: 1.0
Date: Thu, 17 Feb 2011 19:23:31 -0500
Subject: Re: DEADBEEF vs SHA1
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="UTF-8"
Message-Id: <>
Precedence: bulk
List-Archive: <>
List-Unsubscribe: <>
List-ID: <>

On Thu, 17 Feb 2011 14:12:20 -0500 David Shaw 
<> wrote:

>The problem is that the issuer subpacket doesn't 
>differentiate between V3 and V4, so it's possible to make a 
>DEADBEEF V3 key and use it to do a version rollback / denial of 
>service attack against a V4 key.


>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).


>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. 

But if there is an effective solution that offers inclusion, and 
doesn't require any additional work,  (and probably needs to be 
implemented anyway independent of v3 keys), then why choose a path  
of exclusion of V3 keys?

(Even if only for Ian's point, that there are lots of v3 encrypted 
and signed material out there, that should be accessable.)

When Senderek described the ADK flaw, people could have argued 
similarly to exclude V4 keys, (but wisely chose to keep subkey 
capability and simple just fixed the ADK problem).