Re: DEADBEEF vs SHA1

David Shaw <dshaw@jabberwocky.com> Tue, 22 February 2011 02:00 UTC

Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p1M20IEs010563 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Feb 2011 19:00:18 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id p1M20IPV010562; Mon, 21 Feb 2011 19:00:18 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org)
X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from walrus.jabberwocky.com (walrus.jabberwocky.com [173.9.29.57]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p1M20Gkk010557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-openpgp@imc.org>; Mon, 21 Feb 2011 19:00:17 -0700 (MST) (envelope-from dshaw@jabberwocky.com)
Received: from grover.home.jabberwocky.com (grover.home.jabberwocky.com [172.24.84.28]) (authenticated bits=0) by walrus.jabberwocky.com (8.14.4/8.14.4) with ESMTP id p1M20Dq0006624 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <ietf-openpgp@imc.org>; Mon, 21 Feb 2011 21:00:14 -0500
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1082)
Subject: Re: DEADBEEF vs SHA1
From: David Shaw <dshaw@jabberwocky.com>
In-Reply-To: <slrnim4mvo.v2.lutz@belenus.iks-jena.de>
Date: Mon, 21 Feb 2011 21:00:13 -0500
Message-Id: <3206DB97-55EF-4617-918B-B0E12EE66F2B@jabberwocky.com>
References: <C997753D-9BB7-445C-A95C-260B3BE11F78@callas.org> <slrnim4mvo.v2.lutz@belenus.iks-jena.de>
To: IETF OpenPGP Working Group <ietf-openpgp@imc.org>
X-Mailer: Apple Mail (2.1082)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by hoffman.proper.com id p1M20Ikj010558
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Feb 21, 2011, at 7:35 AM, Lutz Donnerhacke wrote:

> 
> * Jon Callas wrote:
>> The bottom line is that a key id in that context is a 64-bit binary key
>> into a database. That's all that it is.
> 
> And it is *not unique*. Software has to deal with multiple keys having the
> same ID. Not importing v3, because it might generate such ambigious cases,
> is not an acceptable solution. V3 keys only enforce standard compliant
> behaviour.

I definitely agree.  Unfortunately, very widely deployed code does make the assumption that all keys have a unique ID.  A better fix for this problem is to fix that code, but that is complex and will likely not happen quickly.  A blockage of V3 keys is not the ideal fix for the problem, as V4-V4 collisions are still possible.  Given how easy it is to make a V3-V4 collision, and how hard it is to make a V4-V4 one, giving an option to block V3 goes a long way to avoid (though not eliminate) the problem, and buys time for the proper fix to be developed and released.

David