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 ; 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 ; 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 In-Reply-To: Date: Mon, 21 Feb 2011 21:00:13 -0500 Message-Id: <3206DB97-55EF-4617-918B-B0E12EE66F2B@jabberwocky.com> References: To: IETF OpenPGP Working Group 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: List-Unsubscribe: List-ID: 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 Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p1LCZAVF052226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Feb 2011 05:35:10 -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 p1LCZArr052225; Mon, 21 Feb 2011 05:35:10 -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 branwen.iks-jena.de (branwen.iks-jena.de [217.17.192.90]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p1LCZ87I052220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 21 Feb 2011 05:35:10 -0700 (MST) (envelope-from news@branwen.iks-jena.de) X-SMTP-Sender: 127.0.0.1 Received: from branwen.iks-jena.de (localhost [127.0.0.1]) by branwen.iks-jena.de (8.14.3/8.14.1) with ESMTP id p1LCZ5sx011166 for ; Mon, 21 Feb 2011 13:35:07 +0100 X-MSA-Host: branwen.iks-jena.de Received: (from news@localhost) by branwen.iks-jena.de (8.14.3/8.14.1/Submit) id p1LCZ4Dg011165 for ietf-openpgp@imc.org; Mon, 21 Feb 2011 13:35:04 +0100 To: ietf-openpgp@imc.org Path: not-for-mail From: Lutz Donnerhacke Newsgroups: iks.lists.ietf-open-pgp Subject: Re: DEADBEEF vs SHA1 Date: Mon, 21 Feb 2011 12:35:04 +0000 (UTC) Organization: IKS Jena, =?UTF-8?Q?Th=C3=BCringen?= Netz, Fitug Lines: 8 Message-ID: References: NNTP-Posting-Host: belenus.iks-jena.de Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: branwen.iks-jena.de 1298291704 10788 217.17.192.34 (21 Feb 2011 12:35:04 GMT) X-Complaints-To: usenet@iks-jena.de NNTP-Posting-Date: Mon, 21 Feb 2011 12:35:04 +0000 (UTC) User-Agent: slrn/pre0.9.9-77 (Linux) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: * 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. Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p1IL75Q9093059 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Feb 2011 14:07:05 -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 p1IL755J093058; Fri, 18 Feb 2011 14:07:05 -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 p1IL738g093046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 18 Feb 2011 14:07:04 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from dshaw.nasuni.net (gw-comcast1.nasuni.com [173.166.63.186]) (authenticated bits=0) by walrus.jabberwocky.com (8.14.4/8.14.4) with ESMTP id p1IL6xPN012947 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 18 Feb 2011 16:07:00 -0500 Subject: Re: DEADBEEF vs SHA1 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: David Shaw In-Reply-To: Date: Fri, 18 Feb 2011 16:06:59 -0500 Cc: IETF OpenPGP Working Group Message-Id: References: <4D5DB5A9.9040509@iang.org> <315DE4B7-F5C7-4FA6-9A0F-2CAD305D4DF2@jabberwocky.com> To: Jon Callas X-Mailer: Apple Mail (2.1081) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hoffman.proper.com id p1IL748f093054 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Feb 18, 2011, at 1:29 PM, Jon Callas wrote: > There are a number of ways to deal with this. For example, I could have a copy of PGP 2.6.3 lying around and use that to decrypt my old things. That's only a mild inconvenience. Similarly, PGP or GnuPG could keep v3 keys around *as* *software* for such archival purposes. It might even make sense from a user experience aspect to have them in historic keyrings that are not in one's face every day. Right, a historic keyring is the sort of thing I'm envisioning, along with some sort of application knob to use it ("click here to enable V3 keys" or "--enable-v3-keys") or not ("--disable-v3-keys"). David Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p1IITS90086386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Feb 2011 11:29:28 -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 p1IITS1D086382; Fri, 18 Feb 2011 11:29:28 -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 merrymeet.com (thing2.merrymeet.com [173.164.244.100] (may be forged)) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p1IITSWU086373 for ; Fri, 18 Feb 2011 11:29:28 -0700 (MST) (envelope-from jon@callas.org) Received: from localhost (localhost [127.0.0.1]) by merrymeet.com (Postfix) with ESMTP id 7CA9A2E060 for ; Fri, 18 Feb 2011 10:30:53 -0800 (PST) Received: from merrymeet.com ([127.0.0.1]) by localhost (host.domain.tld [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 41082-05 for ; Fri, 18 Feb 2011 10:30:51 -0800 (PST) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTPA id 342712E05F for ; Fri, 18 Feb 2011 10:30:51 -0800 (PST) Received: from [10.0.23.19] ([173.164.244.98]) by keys.merrymeet.com (PGP Universal service); Fri, 18 Feb 2011 10:29:25 -0800 X-PGP-Universal: processed; by keys.merrymeet.com on Fri, 18 Feb 2011 10:29:25 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Subject: Re: DEADBEEF vs SHA1 From: Jon Callas In-Reply-To: <315DE4B7-F5C7-4FA6-9A0F-2CAD305D4DF2@jabberwocky.com> Date: Fri, 18 Feb 2011 10:29:24 -0800 Message-Id: References: <4D5DB5A9.9040509@iang.org> <315DE4B7-F5C7-4FA6-9A0F-2CAD305D4DF2@jabberwocky.com> To: IETF OpenPGP Working Group X-Mailer: Apple Mail (2.1082) X-PGP-Encoding-Format: Partitioned X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: quoted-printable X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=us-ascii Content-Type: text/plain; charset="us-ascii" X-Virus-Scanned: Maia Mailguard Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by hoffman.proper.com id p1IITSWU086377 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I think it's very important to understand the distinction between the protocol(s) we have and machines that implement the protocols. Those machines can be APIs (e.g. OpenPGP SDK, Bouncy Castly, etc.) applications (e.g. GnuPG, PGP Desktop), appliances (e.g. PGP Universal), but they are not the same thing. It's perfectly fine for an application to do some right thing that is not supported by some protocol. For example, when I was at PGP Corporation, I used to say a lot that OpenPGP is a standard (and a protocol), but PGP is software. The PGP Software implements the OpenPGP protocol, but it also implements the S/MIME protocol, as well as SSL/TLS, X.509, SMTP, and so on. It's with that in mind, the difference between the protocol and software is an important part of this discussion. I agree with Ian completely that there are people who have old (v3 key) encrypted and signed data that they need to get to. Decrypting data is the most important thing. I'm sure that I have some things in old backups that maybe I'd like to decrypt some day without having to break the key they're encrypted to. There are a number of ways to deal with this. For example, I could have a copy of PGP 2.6.3 lying around and use that to decrypt my old things. That's only a mild inconvenience. Similarly, PGP or GnuPG could keep v3 keys around *as* *software* for such archival purposes. It might even make sense from a user experience aspect to have them in historic keyrings that are not in one's face every day. Or GnuPG could handle it despite it not being any longer standard, or .... 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. Yeah, it's derived with a function, but it's just a key. IETF RFCs are not programming manuals. They are also not requirements documents for applications. They are descriptions of how to properly interoperate, and that's all. Application designers still have to think. Jon -----BEGIN PGP SIGNATURE----- Version: PGP Universal 2.10.0 (Build 554) Charset: us-ascii wj8DBQFNXrqFsTedWZOD3gYRAj16AKCZ5TrOlbYAj6Zb0xyLCNkbA2NKPQCgriab hjgYuRyiS625/fIrFoaUqB4= =BuD3 -----END PGP SIGNATURE----- Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p1IHb4hl084128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Feb 2011 10:37:04 -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 p1IHb4G1084127; Fri, 18 Feb 2011 10:37:04 -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 che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p1IHb3F7084120 for ; Fri, 18 Feb 2011 10:37:03 -0700 (MST) (envelope-from dkg@fifthhorseman.net) Received: from [192.168.23.207] (dsl254-070-154.nyc1.dsl.speakeasy.net [216.254.70.154]) by che.mayfirst.org (Postfix) with ESMTPSA id 28E2CF970; Fri, 18 Feb 2011 12:37:01 -0500 (EST) Message-ID: <4D5EAE38.4050304@fifthhorseman.net> Date: Fri, 18 Feb 2011 12:36:56 -0500 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101213 Icedove/3.1.7 MIME-Version: 1.0 To: Werner Koch CC: David Shaw , IETF OpenPGP Working Group Subject: Re: DEADBEEF vs SHA1 References: <87aaht69bj.fsf@vigenere.g10code.de> In-Reply-To: <87aaht69bj.fsf@vigenere.g10code.de> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigB023DE46FC2756A1E5F3CDC0" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB023DE46FC2756A1E5F3CDC0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 02/18/2011 03:22 AM, Werner Koch wrote: > The part which requires more work is to change all code looking for a > keyid to iterate over all keyids in the database until it succeeds. We= > do this for example for wildcard keyids. It turned out that this is > sometimes pretty annoying because the user is forced to enter the > passphrases for all of his keys. For the case you describe we won't > have this problem but it is nevertheless a lot of work to try all > keyids. It would be more correct, though. while it might be more correct to import the new keys, it introduces dangerous ambiguity to the output of "gpg --check-sigs --with-colons", as that command identifies certifiers by key ID. Any tool that relies on the output of "gpg --check-sigs --with-colons" is currently implicitly expecting only a single key per keyID in the keyring; otherwise, the output would be ambiguous. > Disabling v3 import and an option to enable such imports seems to be > justified and is easy to implement. That's good to hear, thanks! --dkg --------------enigB023DE46FC2756A1E5F3CDC0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQJ8BAEBCgBmBQJNXq45XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwRUU1QkU5NzkyODJEODBCOUY3NTQwRjFD Q0QyRUQ5NEQyMTczOUU5AAoJEMzS7ZTSFznp1uIP/1e0ss6hZhq/CatIC0BRdA6e CH7nfWv5JSMC3wBBD9HSGR+94XzHO7VaInPg5d430f7htgQTWZzM7dcL9kHIxFQy aArko7/uTL+x+XXq0Asi9SSQhZ9v/v6uooSW1ZHoFL/X9hFN1N2sMVr7oAchofWy 0sUErSb6FPmW5DSh35/e5moYeNgMgyPIn8C31w7DIWzTn0hIBI2sB/m6423ZwxBD 7B68lDr38uGE0bWuondl2HcmnMiWxxw74O0IF/NQvDo9vbtR88I/X1idYCa2X/7F hD4Mry8lDTJLMBpwlTnJCKNZUqF4BgsVwNz66o8AAzJGR8/H7pEZlh0/Hd5uz3WN Tk20a8t1IKKgGUjoL6j8hDH8T3Wn47Eec5rpR+w8z0NRqE+63AGysgjS0yjiKHLT 2quzLXh1ZWoxJb5tohdIbWod4io1uD7ME5t7u4zgLobgvpGcJvD3dnjOrhGvp7Ui f7R6j4sRWOJGQkjLOEkxGdFha+iG1wJk8NLAkqIDHqxdKDBpGH/hLrMtxkROmpVa 4Z/LC/kaVo9/JoRtH4Ai1yWN+OeuAbSl8WvSjal0REkfP+4fpfp1WXfiuNF2Uhth bcjFwd7GkXn5IX1gzjucT/B8AdW9Pi9jLNjb/JFbX1IlL3cRy3c41LNxEAS9/8/j Sl1Eo2aIApQu0tatMg6M =Ky3e -----END PGP SIGNATURE----- --------------enigB023DE46FC2756A1E5F3CDC0-- Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p1I8PBnI059057 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Feb 2011 01:25:11 -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 p1I8PB7d059056; Fri, 18 Feb 2011 01:25:11 -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 kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p1I8P9WI059043 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 18 Feb 2011 01:25:11 -0700 (MST) (envelope-from wk@gnupg.org) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.69 #1 (Debian)) id 1PqLeH-0001Ho-7f for ; Fri, 18 Feb 2011 09:25:09 +0100 Received: from wk by vigenere.g10code.de with local (Exim 4.72 #1 (Debian)) id 1PqLbs-0000Yf-Us; Fri, 18 Feb 2011 09:22:40 +0100 From: Werner Koch To: David Shaw Cc: IETF OpenPGP Working Group Subject: Re: DEADBEEF vs SHA1 References: Organisation: g10 Code GmbH OpenPGP: id=5B0358A2; url=finger:wk@g10code.com Date: Fri, 18 Feb 2011 09:22:40 +0100 In-Reply-To: (David Shaw's message of "Thu, 17 Feb 2011 14:12:20 -0500") Message-ID: <87aaht69bj.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 17 Feb 2011 20:12, dshaw@jabberwocky.com said: > import the other one without explicitly deleting the first. When > trying to import the second key, GPG fails with "key 689E2211 doesn't > match our copy". PGP silently ignores the new key. Not allowing a > new key to replace an old one does make some sense (after all, how Actual this message is here due to my laziness. A proper implementation would fallen back to insert that key as a new key. That would be easy. The part which requires more work is to change all code looking for a keyid to iterate over all keyids in the database until it succeeds. We do this for example for wildcard keyids. It turned out that this is sometimes pretty annoying because the user is forced to enter the passphrases for all of his keys. For the case you describe we won't have this problem but it is nevertheless a lot of work to try all keyids. It would be more correct, though. Disabling v3 import and an option to enable such imports seems to be justified and is easy to implement. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p1I4gtNS049907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Feb 2011 21:42:55 -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 p1I4gtni049906; Thu, 17 Feb 2011 21:42:55 -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 p1I4gr34049900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 17 Feb 2011 21:42:54 -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 p1I4gqOr004551 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 17 Feb 2011 23:42:52 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) Subject: Re: DEADBEEF vs SHA1 From: David Shaw In-Reply-To: <4D5DBDF6.5020705@epointsystem.org> Date: Thu, 17 Feb 2011 23:42:52 -0500 Message-Id: <66543BB1-FCC6-49AE-9730-04BCD1F1E063@jabberwocky.com> References: <4D5DB5A9.9040509@iang.org> <4D5DBDF6.5020705@epointsystem.org> To: IETF OpenPGP Working Group X-Mailer: Apple Mail (2.1082) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hoffman.proper.com id p1I4gt33049902 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I think I wasn't as clear as I should have been, so let me try and clarify my thoughts a bit more. There are two issues here: I started looking at this in the context of the signing key collision issue that Daniel Gillmor had posted about. He was concerned about the chance of a SHA-1 V4-to-V4 64-bit collision, and I pointed out there is also a risk of a V3-to-V4 collision, which is vastly easier to accomplish. Now, Daniel's proposed fix handles both cases, so that would seem to be the end of it. We've already discussed his fix, and so here's just another reason why it's a useful idea. So, done. No problem. That's the standards part of the message. However, wearing my implementation hat, we do have a different problem now. In trying out the V3-to-V4 collision against current implementations in the field, it turns out to be a denial of service attack, as at least the implementations that I tried (PGP 9 and GPG 1.4) can't cope very well with two different keys with the same 64-bit key ID. The "fingerprint in each signature" is intended to disambiguate between two different keys with the same key ID in order to find the real signer. However, we don't even get to that point, as we can't import two different keys with the same key ID in the first place (the RFC even warns about this specifically). The end result is that if someone makes this sort of collision, they can upload them to keyservers (perhaps ironically, SKS can handle multiple keys with the same 64-bit key ID just fine), thus "poisoning" certain keys. Once a key is poisoned, requesting it from the keyserver will return both the good and bad keys in a (so far as I can tell) nondeterministic order, so anyone fetching that key risks importing the bad one, causing signature verifications from the real key to fail, blocking encryption to the real key, and generally making a nuisance. My proposed fix for this is not an OpenPGP standard issue, as I'm not proposing removing V3 support from the standard. Rather, I'm just taking advantage of the fact that many OpenPGP developers read this list to raise awareness of the issue, and point out that adding a knob to enable or disable V3 (as allowed for in the standard) is a fairly simple way to avoid this problem. David Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (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 owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id p1I2hCfD045525; Thu, 17 Feb 2011 19:43:12 -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 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 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 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: <4D5DB5A9.9040509@iang.org> Date: Thu, 17 Feb 2011 21:43:07 -0500 Cc: IETF OpenPGP Working Group Message-Id: <315DE4B7-F5C7-4FA6-9A0F-2CAD305D4DF2@jabberwocky.com> References: <4D5DB5A9.9040509@iang.org> To: Ian G X-Mailer: Apple Mail (2.1082) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hoffman.proper.com id p1I2hBlb045519 Sender: owner-ietf-openpgp@mail.imc.org 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. David Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p1I0W00U039408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Feb 2011 17:32:00 -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 p1I0W0lo039407; Thu, 17 Feb 2011 17:32:00 -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 mail-bw0-f43.google.com (mail-bw0-f43.google.com [209.85.214.43]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p1I0VwDX039399 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Thu, 17 Feb 2011 17:31:59 -0700 (MST) (envelope-from nagydani@epointsystem.org) Received: by bwz14 with SMTP id 14so3266621bwz.16 for ; Thu, 17 Feb 2011 16:31:57 -0800 (PST) Received: by 10.204.152.22 with SMTP id e22mr65938bkw.103.1297989117562; Thu, 17 Feb 2011 16:31:57 -0800 (PST) Received: from [192.168.55.151] ([213.163.35.18]) by mx.google.com with ESMTPS id rc9sm1097771bkb.2.2011.02.17.16.31.55 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 17 Feb 2011 16:31:55 -0800 (PST) Message-ID: <4D5DBDF6.5020705@epointsystem.org> Date: Fri, 18 Feb 2011 01:31:50 +0100 From: "Daniel A. Nagy" Organization: ePoint Systems Ltd. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Ian G CC: David Shaw , IETF OpenPGP Working Group Subject: Re: DEADBEEF vs SHA1 References: <4D5DB5A9.9040509@iang.org> In-Reply-To: <4D5DB5A9.9040509@iang.org> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7A69917390DBBC8CB3943136" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7A69917390DBBC8CB3943136 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 02/18/2011 12:56 AM, Ian G wrote: > * 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. Actually, these two can be addressed while still doing away with V3 key format. Since V3 signatures can be generated by V4 keys and the keyID in V3 signatures is not part of the hashed material, one can re-package the V3 key in V4 format and change the keyID part in the signature, while still keeping the whole thing valid, without access to the private key. The only thing missing would be the self-signature of the key, but that is a minor compromise in the face of things like keyserver poisoning. IMHO, of course. --=20 Daniel A. Nagy ePoint Systems Ltd. --------------enig7A69917390DBBC8CB3943136 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1dvfoACgkQ28D1wCI06YWUfgCfRRKon/suXIePaMboOFCcoQuA CqMAn2Eobz+S7ELVCYnr3x7yAzNCSp4u =wYAp -----END PGP SIGNATURE----- --------------enig7A69917390DBBC8CB3943136-- Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (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 owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id p1I0NXNB039191; Thu, 17 Feb 2011 17:23:33 -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 smtp12.hushmail.com (smtp12.hushmail.com [65.39.178.135]) by hoffman.proper.com (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 vedaal@nym.hush.com) Received: from smtp12.hushmail.com (localhost.localdomain [127.0.0.1]) by smtp12.hushmail.com (Postfix) with SMTP id DB2E7C011A for ; Fri, 18 Feb 2011 00:23:31 +0000 (UTC) X-Hush-Verified-Domain: nym.hush.com Received: from smtp.hushmail.com (w4.hushmail.com [65.39.178.50]) by smtp12.hushmail.com (Postfix) with ESMTP for ; Fri, 18 Feb 2011 00:23:31 +0000 (UTC) Received: by smtp.hushmail.com (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 To: ietf-openpgp@imc.org Subject: Re: DEADBEEF vs SHA1 From: vedaal@nym.hush.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20110218002331.644C410E2B7@smtp.hushmail.com> Sender: owner-ietf-openpgp@mail.imc.org 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). vedaal Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p1HNuTCM038182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Feb 2011 16:56:29 -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 p1HNuTKP038181; Thu, 17 Feb 2011 16:56:29 -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 fiddle.it (slice.reviewedpress.com [67.207.137.25] (may be forged)) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p1HNuSnx038173 for ; Thu, 17 Feb 2011 16:56:28 -0700 (MST) (envelope-from iang@iang.org) Received: from viento.local (localhost [127.0.0.1]) by fiddle.it (Postfix) with ESMTP id AF676406C2; Thu, 17 Feb 2011 23:56:26 +0000 (UTC) Message-ID: <4D5DB5A9.9040509@iang.org> Date: Fri, 18 Feb 2011 10:56:25 +1100 From: Ian G User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.14) Gecko/20110123 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: David Shaw CC: IETF OpenPGP Working Group Subject: Re: DEADBEEF vs SHA1 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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. Secondly, isn't the argument more about ditching the Key ID approach? If we set up the new way to use only full fingerprints, then any imported V3 keys can be indexed on that basis. iang PS: I agree with the "must not generate V3 keys" part. Is it possible to widen that with "must not sign or export or encrypt using V3 keys." And possibly offer an upgrade mode "implementations may re-package V3 keys in V5 format." Dunno, just whiteboarding here... Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p1HK8Ih2029543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Feb 2011 13:08: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 p1HK8IIr029542; Thu, 17 Feb 2011 13:08: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 che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p1HK8Iu8029537 for ; Thu, 17 Feb 2011 13:08:18 -0700 (MST) (envelope-from dkg@fifthhorseman.net) Received: from [192.168.23.207] (dsl254-070-154.nyc1.dsl.speakeasy.net [216.254.70.154]) by che.mayfirst.org (Postfix) with ESMTPSA id 740F6F970 for ; Thu, 17 Feb 2011 15:08:15 -0500 (EST) Message-ID: <4D5D8025.6080000@fifthhorseman.net> Date: Thu, 17 Feb 2011 15:08:05 -0500 From: Daniel Kahn Gillmor Reply-To: IETF OpenPGP Working Group User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101213 Icedove/3.1.7 MIME-Version: 1.0 To: IETF OpenPGP Working Group Subject: Re: DEADBEEF vs SHA1 References: In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigA597F855B6E5B26FE30070B4" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA597F855B6E5B26FE30070B4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 02/17/2011 02:12 PM, David Shaw wrote: > 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. I think this seems like a reasonable step to take. As a user, given the option between: a) losing communication with v3 users b) allowing anyone to lock me out of communications with v4 users i would prefer (a). --dkg --------------enigA597F855B6E5B26FE30070B4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQJ8BAEBCgBmBQJNXYAlXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwRUU1QkU5NzkyODJEODBCOUY3NTQwRjFD Q0QyRUQ5NEQyMTczOUU5AAoJEMzS7ZTSFznpjx0P/R80G3ni2jpBHhxPVnV3LbEy u08xCEUbPN96ZqmdmBowYvk1lOLlDkaImwYS6fIJOFeZsDd2sAY41bCD/EZKDvkp n8PfXRvxWOiN6Y8LEODk4bXKmNZ6Owl1U33ggKdmbZ1hwqL1J4JDC7nnUy+rRDi6 pmwbQDQm2xSoPTbXYi7q8vhoPThK+6a3/LGsO3zYv/xjC4u/l6EQewhLGEZ6/n0U vZB/25CHRIoFlt10EntcpiI7mUkWakg73hfd4NAA01X8JJqUjyjCmK8Mb7ZaGD6Q oGPHp2PD8BEvTuK0hMKFev/kNpZTulJ+VNxC9B2Jca2ocJoL/Gh+PuMt3IgPGpG2 P1JhktOs66ILUcRZL7E/2+SBg0yq2JjxuWtQsoWdFVapbgGUnliRepf0FpujEI3O NDZNf79+eNMwVpnmi08h5TL9YxPAf/5lSFXAuJGSkcEU4u7UziDFYaR/du9rDipe JCcbFm4Z5nT7t+5tG/lRv3IhV3PKgC53QRVcjaQ6V4ZJMQFxzRpUhUmlKTso4L67 +KqTv23GPA2TnNCaY01XhXexjnoGQ3v5mKSH70tEIVqtRnyQqD1laj86SwSikLsk 8PIp8d1p+yed7UMuxa/FozoQHfKuh89ud3XwkdunU0UBVOVZ5ePdUJSrFBZC5eF1 +9zjNGxpn6LeLJJ7cjfi =2TjW -----END PGP SIGNATURE----- --------------enigA597F855B6E5B26FE30070B4-- Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p1HJCPqk027523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Feb 2011 12:12:25 -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 p1HJCP6A027522; Thu, 17 Feb 2011 12:12:25 -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 p1HJCMla027516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 17 Feb 2011 12:12:23 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from dshaw.nasuni.net (gw-comcast1.nasuni.com [173.166.63.186]) (authenticated bits=0) by walrus.jabberwocky.com (8.14.4/8.14.4) with ESMTP id p1HJCKap000725 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 17 Feb 2011 14:12:21 -0500 From: David Shaw Content-Type: text/plain; charset=us-ascii Subject: DEADBEEF vs SHA1 Date: Thu, 17 Feb 2011 14:12:20 -0500 Message-Id: To: IETF OpenPGP Working Group Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hoffman.proper.com id p1HJCNlZ027517 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi everyone, I was thinking about Daniel Gillmor's proposal to include the complete fingerprint in signatures, and specifically this: > But a devious attacker could potentially create a colliding Key ID (i > believe collisions of the low 64 bits of SHA1 are within reach today, > i'd love to be corrected if this is not the case) and cause the > user-friendly MUA to assume it is in state B when it is actually in > state A. The attacker doesn't even need access to the message or > signature in question to do this. They'd only need to have been able to > supply a key to the user at some time in the past. (e.g. push a new > subkey to the keyservers which a user pulls during a keyring refresh) It occurred to me that it doesn't actually matter whether a 64-bit SHA-1 collision is feasible today or not. There is a much easier collision that makes this attack trivial without going up against SHA-1 at all. OpenPGP uses the 64-bit key ID to find the right key to verify a signature (via the issuer subpacket). However that key ID doesn't have to be the lower 64 bits of the fingerprint like it is in V4. In V3, it was the lower 64 bits of the modulus, which is trivial to set to whatever the attacker likes (i.e. the DEADBEEF key problem). 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. For example, Alice's key (either V3 or V4) has a key ID of E435AEDF689E2211. Mallory makes a V3 key, matches the key ID E435AEDF689E2211, and distributes it ahead of Alice. Now any signatures that Alice issues will result in a "bad signature" error, since they will be verified against the wrong key. To test, I made both Alice's and Mallory's key and tested with both PGP (9.10) and GPG (1.4 from git). Basically, the attack works as expected. Not surprisingly, once one key is imported, you can't import the other one without explicitly deleting the first. When trying to import the second key, GPG fails with "key 689E2211 doesn't match our copy". PGP silently ignores the new key. Not allowing a new key to replace an old one does make some sense (after all, how would the implementation know which is "real" and which is "fake"?), but I can see this being a frustration. Of course, this is a double-edged sword, since if Alice beats Mallory into the keyring, Mallory is locked out. 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). I've pasted the test keys below if anyone wants to play with them. David p.s. the PKESK packet doesn't differentiate between V3 and V4 either but the attack is less obvious there - the victim would have to encrypt to the wrong key, and we at least theoretically have the means to discourage this via the web of trust. It would still be an annoyance, though. Alice: -----BEGIN PGP PRIVATE KEY BLOCK----- lQOYBE1b9LkBCADgluafn3zba/PMOZqlfNgma16vJ0lpZO9535NgJQEQulSLHzQx vqoTRSF/KEGjzwWpPD1LLl0ZojeVAX6quGCM0n0wVncGU3TfurPpS9VB7/7R32gY 5eTgQqGx6pFY7KqReIYvIE5pkr5Dc8/eqZxOkQgzCFlH4h4itQqvo1TK35RpcUne i0lHUEDaYySVYpIdAmOoMLgus5vU/bocwBfpo+GxdTkWtxoWY/4h/vY+lyO3r/qH mDk9EddxAurR/TjtWe5INxuwXJIsGmmJDdFR7FJ1cAmsYLvF3QsH8qu/89zOZL9+ oV2vcVCPXoG+l0itmDrDY33rY9xP+rG2KL4XABEBAAEAB/0eVXisF0AnlBVnVbcZ IkXrgoBVC0BeF3+aKA62uKjD1/bdR4dRhLK3TD9cS6qknlc3EWd8ml7WvH3iBplT ePhewiXzJmqIad3qQ0RTfqY8yVZ92ufWHQ7kaft+6p4GXbN4AchV4HjWx4wifieV p7ZF4k7c3a7Oslq8Tf7gfstQDyaDDO4d1fBWuE5C3roQI002zOm7XhtFCsc2ANK3 a7Lo1MGJHezacM6D+pNgUfpJaZnhtF6osXmO3ZRrqO47lgzN1K1HsiexvghmLC9r GjupbOr5g9VFzuAey4SpQalXoL04Xm0rlmHRVdrCKQXeHVZ+MxkBw46GZ14UcjiD 6qSxBADvbwv2cx78Sb/BqS8anAICLcRDJ0rInVPoE/YIPs8GYaAwjXXlVQsFRWBc rrH+pUZFHvvayKoXYPYtNO0za+1ZsRnFk6/uccasEHDai5bBrQNBgZ0vb/aHoqvx i6LS3XVExKyb4220dyX7Azi6Q98SGKMQfnVbBLugCJqD66/laQQA8CDs2t+i10Ws z6fAUWJems5RMJq9MktQ3jJ/CAkAuXrpxxX1EhhUZM8N9upPdzxY8Iwz0chHCcI4 PYrRNJVNIBH+HBDGFpBLqfcqkXMgUHJtIykD3sl37InQeHgSCP3QHgRF54bucOsu SPdiO7CmyP5vZiZLza5oojPCLKFNl38D/jUuWOe676OJYZReR56jcq5wKGMGIkeE jyhO8510c295kbGMWi+voVANaiLalY6YxY4VH2U+xO6CntZjNTZ2U+zuDDH5iywW rhj+WrwreLewvosmGJ8nfBOIyjefM3DI5EC717L8PaIL730gFEGG5h65t6xbYYLB b1un9f8zB3PiPzq0GUFsaWNlIDxhbGljZUBleGFtcGxlLmNvbT6JATgEEwECACIF Ak1cKB8CGw8GCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEOQ1rt9oniIRWSEH /1bZWEjk/lQXElp81o7ERv/5RHo10bnbkoMl/QT0+5ROf9eaS1f3Vs5F2hMLSZoH tPSWK6KBywijfFndLUIn2PdiisgPHRqv6cBg1gvfvJiYGdJQUQfJzEwFGyTgNviX 0CKDo8SiGDtrSH5IalnlZ1L0vZR8iTESQisOX5AlLTc45sDUnfWUmAddd+aQSKRu 1ZtWvgl3K/D4bMhFSenBXj4Ul0JekLZXPXBZbmf4zFrNUtzGsayksGq2qG4Z8F+f BTcdozEV7V3k0sjlnS+s+uyaOPVT6Pui3n4oMV9XfEjCeJtjyg5j2xVqWFPSqvJA 6FZoXO7/Unul2mGfbY/Sg6M= =cS7P -----END PGP PRIVATE KEY BLOCK----- Mallory: -----BEGIN PGP PRIVATE KEY BLOCK----- lQOaA01cLasAAAEIAOCW5p+ffNtr88w5mqV82CZrXq8nSWlk73nfk2AlARC6VIsf NDG+qhNFIX8oQaPPBak8PUsuXRmiN5UBfqq4YIzSfTBWdwZTdN+6s+lL1UHv/tHf aBjl5OBCobHqkVjsqpF4hi8gTmmSvkNzz96pnE6RCDMIWUf2ZZRTbUmnJGlWMW5N 0j4Kw95dG2cQQKFhhHT3PsP62iHrYP0P62cGCv5f9RwwNXpLS/c3hSpBTW44fr1j qHtlDcOjdu4C2i/lqKOthQBjiW5scTl94Cn1HPr+xRwju8AJJ1e7jh5Y8k1SEYHG wgWFHEVWplwIiajFMRPwpNvWkifJ5DWu32ieIhEAEQEAAQAH/A2L7JM6Ony9sTHj U5mhwyPmHArykrIBvZQbUTdeZAcPRiQyGKLbfkS1ScTyt6raxNulX4kWXdU6/KFH Os2vW1uDIrv0qy89f3IzP8DVqyJUCIm+MPg3fautOTWTEXtMoyktHOLgzvn9OO62 oJYsotn2U4lIeqIlkZD1y0TDCSY1SM7hT7Hhb2VDiwC0sD64wj1/WRBgBujcgl57 TrY+Px/mWWicdRawb6qPOicps6WuZULs0cgdf+tZxAdSZ5S7DJPNUtIrrG4grT1A DIPDNUJy/ww5tp/E2wPDxji5JwVwEGXjn3cabHHa5fY8dslLfLNI736xEu8A//8A AP//AAEEAO9vC/ZzHvxJv8GpLxqcAgItxEMnSsidU+gT9gg+zwZhoDCNdeVVCwVF YFyusf6lRkUe+9rIqhdg9i007TNr7VmxGcWTr+5xxqwQcNqLlsGtA0GBnS9v9oei q/GLotLddUTErJvjbbR3JfsDOLpD3xIYoxB+dVsQ2eQ1rt9oniIRBADwIOza36LX RazPp8BRYl6azlEwmr0yS1DeMn8ICQC5eunHFfUSGFRkzw326k93PFjwjDPRyEcJ wjg9itE0lU0gEf4cEMYWkEup9yqRcyBQcm0jKQPeyXfsidB4eBII/dAeBEXnhu5w 6y5I92I7sKbI/m9mJkvNt/AAAAAAAAAAAQQAkmUeSX+lSSVA2pBdjGN3KjNi/EdB +bR9QJwFG8sRGAveAZ77FrqeLvKjEy8n7v87ahh1pLhgjH12VgR2h2giue9kY4t1 e1AeTBBk+SD8EDbOqFqMSoUtHA0MgOa97ErtOdA/yp05z1QfM+aCEufQSQLF1o/M ml4rQaRVkf+k5QgyRbQZQWxpY2UgPGFsaWNlQGV4YW1wbGUuY29tPokBFQMFE01c LavkNa7faJ4iEQECYS0H/1y57OK9C4iTvNl0KcSKvPfKMPikOMw8wCmY1sB0gYgg nuPgsEMw64Hg/cG30JRBfcXZsaBviQ+nxijagBqeNf0zRMNzla1XIrtTWhD7fy0R dYuAUZ8aIU4zwSYOHvgJraYG7rhRbKO3shlIQ+gfS6+toAz92OWC+IoYGGvEK1OL owa0dzAkLCWI3nnT/MMkXUICpr+VlSI3u+iYKbK9WSFE9P3zCqdGkt+3LENQjV9z c4VuyBUIqHuKU9krJxI7k6U3grYihq94oWYDEkTn8Q7KvGEygCnMdhFaeqtJZ3Ai OA3548H3mkG3FAYemsC43l/Okn/3uz+xVrMJ4LgfxFk= =ExMT -----END PGP PRIVATE KEY BLOCK-----