From openpgp@brainhub.org Wed Jan 2 23:18:48 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2BBB21F892F for ; Wed, 2 Jan 2013 23:18:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.103 X-Spam-Level: X-Spam-Status: No, score=-0.103 tagged_above=-999 required=5 tests=[AWL=0.334, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F6Z6m-SWJldq for ; Wed, 2 Jan 2013 23:18:48 -0800 (PST) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by ietfa.amsl.com (Postfix) with ESMTP id 518B221F88BC for ; Wed, 2 Jan 2013 23:18:48 -0800 (PST) Received: from omta19.emeryville.ca.mail.comcast.net ([76.96.30.76]) by qmta01.emeryville.ca.mail.comcast.net with comcast id jK161k0041eYJf8A1KJo6v; Thu, 03 Jan 2013 07:18:48 +0000 Received: from [192.168.1.8] ([69.181.162.123]) by omta19.emeryville.ca.mail.comcast.net with comcast id jKJm1k00S2g33ZR01KJnMH; Thu, 03 Jan 2013 07:18:47 +0000 Message-ID: <50E530D6.6020609@brainhub.org> Date: Wed, 02 Jan 2013 23:18:46 -0800 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120605 Thunderbird/13.0 MIME-Version: 1.0 To: openpgp@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1357197528; bh=1+VBAQOCioXCw5RoAMKYxdW8YsUjFA0fvZ2Kb61Mp1M=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=GDftD6Yk0E8XtV8UGkjCKJ/+RUfgqa2iMjQwyQhEKfUBBoc5GJpmGs/aUEuwnnIyu aaxZIEWOtI0rJ8j/2yM1FIXw91cb+trwGkj2kMp3b41h2viAitTt3FEx6uTmLTLzN7 ujr4dI44l3Ae0AA+WH5mBIxUXPAILaauAB3r+eBTsRyb83OoF379cm1epx/gxF+fmj hu66Rymd9CXaBnRPjfLl5kaJmfmD33LKxpaXaWtiwklR6wpHOK6WrQNfV4E4/h8Eu7 WtKh2GdrV/qoF0vbfGpGYNyFFOCynCAlSPMcr4Ki9mc36jXUKdrM7L9Sr4ilzgCK7T rJK+SVv3uPuhQ== Subject: [openpgp] Fingerprints and their collisions resistance X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 07:18:49 -0000 We exchanged a few emails on gnupg list about this this issue, which I think belongs here, the OpenPGP thread. The issue is that fingerprint calculation method in OpenPGP is hardwired to use SHA-1. Some scenarios in which fingerprints are used depend on hash function collision resistance. It's easy to see the collision resistance requirement of fingerprints by making the comparison with document signatures. Classical collision resistance requirement arises in a situation when the owner is free to create two documents that hash to the same hash value. The attacker then makes one document available for signing. As a result he has acquired an option to use the second document later and claim that it was the document that was originally signed. When viewed as document, the keys fit this pattern. One possible exploitation of the hash collision is when the attacker can repudiate signatures or repudiate his ability to decrypt messages (because he can offer a wrong key with the same fingerprint as a proof supporting his inability to perform the private key operation). Public keys offer a reasonable opportunity to place arbitrary bytes into fields that are hashed. For example, DSA P,Q,G, are primes. Every byte but the last one of a 2048 bit prime can be fixed, on average, due to the high density of primes. It suggests that the task of finding a collision with public keys is at least no more difficult than for ASCII documents. Not all scenarios involving fingerprint depend on collision resistance. For example, the ability to substitute a designated revoker, which fingerprint is stored in a subpacket of a public key, is not assisted by compromised collision resistance of SHA-1. As a remedy to the problem note that the collision resistance only arises when the original "document" is not available. Fortunately, keys are small, and therefore, the suggested enhancement to the RFC4880 to remedy the collision dependence of fingerprints on SHA-1 is to store the original key. Continuing the above example with non-repudiation, the non-repudiation claims will be made against the application logs (i.e. audit trails), thus it will be necessary to include complete keys in addition to fingerprints in logs that record protocol exchanges that are dependent on public key identification. This concern will need to be communicated somehow to developers that are relying on RFC4880. An alternative method is outlined next. We introduce a new hardwired fingerprint, for example, based on SHA-3. The above-mentioned application logs can simply state that "SHA-3 fingerprint is XXX" and not bother with storing the whole key (which is unfortunately allowed to change, for example, by acquiring new userIDs, making it hard to compare the revisions). Any subpacket that currently takes the fingerprint will be able to take the new SHA-3 fingerprint as well. Applications will be expected to calculate two fingeprints in parallel and perform a match with either of them. In addition, we might consider a features packet forcing or preferring SHA-3 fingeprint (similar to the MDC feature). KeyIDs in messages can also use 8 bytes of the new fingerprint. Regarding compatibility, note that the fingerprint in the subpackets are not affected by collision weakness, so that there is no downgrade attack. Fingerprints that are sensitive to collision resistance are external features. In addition to mentioned application logs, consider the UI implication. When a key is looked up by its fingerprint on a key server, the UI can offer to search by SHA-1 or the new style fingerprint and this will work with any current key. I will appreciate your comments on this feature. I don't expect this to be a task that needs an urgent resolution. In my mind this is something that we agree on, have a simple spec, and then take a few years to implement and deploy it in a least disruptive way. If there is a more elegant/simpler solution? I would like to hear about it. Thank you. From iang@iang.org Thu Jan 3 01:03:36 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27AAD21F84E0 for ; Thu, 3 Jan 2013 01:03:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.359 X-Spam-Level: X-Spam-Status: No, score=-1.359 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BNZ43PxpK+zA for ; Thu, 3 Jan 2013 01:03:35 -0800 (PST) Received: from pyyl.pair.com (pyyl.pair.com [209.68.1.203]) by ietfa.amsl.com (Postfix) with ESMTP id A370321F84D8 for ; Thu, 3 Jan 2013 01:03:35 -0800 (PST) Received: from [IPv6:::1] (www2.futureware.at [78.41.115.142]) by pyyl.pair.com (Postfix) with ESMTPSA id 62B07B24C8; Thu, 3 Jan 2013 04:03:13 -0500 (EST) Message-ID: <50E5494E.6090905@iang.org> Date: Thu, 03 Jan 2013 12:03:10 +0300 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <50E530D6.6020609@brainhub.org> In-Reply-To: <50E530D6.6020609@brainhub.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [openpgp] Fingerprints and their collisions resistance X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 09:03:36 -0000 On 3/01/13 10:18 AM, Andrey Jivsov wrote: > As a remedy to the problem note that the collision resistance only > arises when the original "document" is not available. Fortunately, keys > are small, and therefore, the suggested enhancement to the RFC4880 to > remedy the collision dependence of fingerprints on SHA-1 is to store the > original key. Continuing the above example with non-repudiation, the > non-repudiation claims will be made against the application logs (i.e. > audit trails), thus it will be necessary to include complete keys in > addition to fingerprints in logs that record protocol exchanges that are > dependent on public key identification. > > This concern will need to be communicated somehow to developers that are > relying on RFC4880. I agree with this approach. It means no change to the tech in the short term, just a note that is distributed (perhaps added in any next revision or additional ID): to insure against future key collision possibilities in high-security application, store the full key with any fingerprint. > An alternative method is outlined next. We introduce a new hardwired > fingerprint, for example, based on SHA-3. The above-mentioned > application logs can simply state that "SHA-3 fingerprint is XXX" and > not bother with storing the whole key (which is unfortunately allowed to > change, for example, by acquiring new userIDs, making it hard to compare > the revisions). Any subpacket that currently takes the fingerprint will > be able to take the new SHA-3 fingerprint as well. Applications will be > expected to calculate two fingeprints in parallel and perform a match > with either of them. In addition, we might consider a features packet > forcing or preferring SHA-3 fingeprint (similar to the MDC feature). > KeyIDs in messages can also use 8 bytes of the new fingerprint. Now that SHA-3 is settled, it seems reasonable to clean out all of the SHA-1s. It would be nice if this were to take place within an overall refurbishment of the entire suite, e.g., OpenPGP 5 or whatever one calls it. Any change is going to be disruptive, and confusion out in userland with different feature/time/brand sets leads to loss of users, which isn't really any good compensation for the illusory security advantage of replacing SHA1. ... > I will appreciate your comments on this feature. I don't expect this to > be a task that needs an urgent resolution. In my mind this is something > that we agree on, have a simple spec, and then take a few years to > implement and deploy it in a least disruptive way. +1 It would be ideal if we could select a single small fixed suite of everything that would last for the next 2 decades. > If there is a more elegant/simpler solution? I would like to hear about it. On another related point - have the MD numbers been allocated for SHA3 in its various guises? iang From nicholas.cole@gmail.com Thu Jan 3 01:33:29 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 880D321F8A6B for ; Thu, 3 Jan 2013 01:33:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KLtHjg7UiP7Q for ; Thu, 3 Jan 2013 01:33:28 -0800 (PST) Received: from mail-vb0-f41.google.com (mail-vb0-f41.google.com [209.85.212.41]) by ietfa.amsl.com (Postfix) with ESMTP id B47C121F8A52 for ; Thu, 3 Jan 2013 01:33:28 -0800 (PST) Received: by mail-vb0-f41.google.com with SMTP id l22so14954291vbn.14 for ; Thu, 03 Jan 2013 01:33:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RF+K7+aAs6qi5ANBchQMYbQykFC2VaNFzBDZ2eDz3e4=; b=H3JgSo5IUc8dwGXKHxztPlTw3FmYDyZRcX9VTvAbuRemELsNCgRMi7KEGjE3tzYB9N bbr+/Jn1Bs+mEkeR0YwTwNwm7jRpUEsntcgcdVlk+8Ax+Em3d/AbjCxq0Rg5Tp652ItA 3oHiiXj+di9EsWMQkd7g0WyOXirNRJQC/ZXyPRxaJNFbF24ehf9KxXTiP7puu9wWsEIr PRb5wLuIXAPqQiCEPr772IHb0aTFiEvqGjORf+UYmTVc0fL+YgkK1FefX/MItXE9kV/I CmOkP08G+FP+TNpWcTNQOL3E0KmB5Dd8G6t3xjPa8ZKfMjo89PiWkGzU5z3wzk8Usg17 pcow== MIME-Version: 1.0 Received: by 10.220.151.142 with SMTP id c14mr72484385vcw.16.1357205607728; Thu, 03 Jan 2013 01:33:27 -0800 (PST) Received: by 10.58.37.40 with HTTP; Thu, 3 Jan 2013 01:33:27 -0800 (PST) In-Reply-To: <50E530D6.6020609@brainhub.org> References: <50E530D6.6020609@brainhub.org> Date: Thu, 3 Jan 2013 09:33:27 +0000 Message-ID: From: Nicholas Cole To: Andrey Jivsov Content-Type: multipart/alternative; boundary=f46d043be06a22c47604d25f0e4a Cc: openpgp@ietf.org Subject: Re: [openpgp] Fingerprints and their collisions resistance X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 09:33:29 -0000 --f46d043be06a22c47604d25f0e4a Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jan 3, 2013 at 7:18 AM, Andrey Jivsov wrote: > We exchanged a few emails on gnupg list about this this issue, which I > think belongs here, the OpenPGP thread. > [snip] Public keys offer a reasonable opportunity to place arbitrary bytes into > fields that are hashed. For example, DSA P,Q,G, are primes. Every byte but > the last one of a 2048 bit prime can be fixed, on average, due to the high > density of primes. It suggests that the task of finding a collision with > public keys is at least no more difficult than for ASCII documents. > If anyone has already done this, they are keeping very quiet about it. I don't think I favour interim solutions - it would be better if the issue were tackled directly. From a user point of view, it would be good if new formats were decided that hard-wire a new formats. I think that these decisions should be made sooner rather than later, because it will take some years for end-user software to fully catch up. Is it impossible to think that new standards would be decided this year? One issue with SHA-3 is that the fingerprints are going to be very long. How should these be displayed to the user? Hex strings seem unsuitable for this task, and I think any new standard should recommend that fingerprints be displayed in some other way - probably using a different base. Best wishes, N. --f46d043be06a22c47604d25f0e4a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Jan 3, 2013 at 7:18 AM, Andrey Jivsov <= ;openpgp@brainhub= .org> wrote:
We exchanged a few emails on gnupg list abou= t this this issue, which I think belongs here, the OpenPGP thread.

[snip]=A0

Public keys offer a reasonable opportunity to place arbitrary bytes into fi= elds that are hashed. For example, DSA P,Q,G, are primes. Every byte but th= e last one of a 2048 bit prime can be fixed, on average, due to the high de= nsity of primes. It suggests that the task of finding a collision with publ= ic keys is at least no more difficult than for ASCII documents.

If anyone has already done this, the= y are keeping very quiet about it. =A0

I don't think I favour interim solutions - it would be better if the i= ssue were tackled directly. =A0From a user point of view, it would be good = if new formats were decided that hard-wire a new formats. =A0I think that t= hese decisions should be made sooner rather than later, because it will tak= e some years for end-user software to fully catch up. =A0Is it impossible t= o think that new standards would be decided this year?

One issue with SHA-3 is that the fingerprin= ts are going to be very long. =A0How should these be displayed to the user?= =A0Hex strings seem unsuitable for this task, and I think any new standard= should recommend that fingerprints be displayed in some other way - probab= ly using a different base.

Best wishes,

N.

=A0
--f46d043be06a22c47604d25f0e4a-- From jon@callas.org Thu Jan 3 08:18:27 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68EBD21F8CA0 for ; Thu, 3 Jan 2013 08:18:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eboR-IBEqPwc for ; Thu, 3 Jan 2013 08:18:27 -0800 (PST) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id EE56121F8C9E for ; Thu, 3 Jan 2013 08:18:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id 0B444183976A; Thu, 3 Jan 2013 08:18:26 -0800 (PST) X-Virus-Scanned: amavisd-new at merrymeet.com Received: from mail.merrymeet.com ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0G1Ey3P02rOp; Thu, 3 Jan 2013 08:18:25 -0800 (PST) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id D262E183975E; Thu, 3 Jan 2013 08:18:23 -0800 (PST) Received: from [192.168.0.130] ([67.6.15.121]) by keys.merrymeet.com (PGP Universal service); Thu, 03 Jan 2013 08:18:25 -0800 X-PGP-Universal: processed; by keys.merrymeet.com on Thu, 03 Jan 2013 08:18:25 -0800 Mime-Version: 1.0 (Apple Message framework v1283) From: Jon Callas In-Reply-To: <50E530D6.6020609@brainhub.org> Date: Thu, 3 Jan 2013 08:17:52 -0800 Message-Id: References: <50E530D6.6020609@brainhub.org> To: Andrey Jivsov X-Mailer: Apple Mail (2.1283) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: openpgp@ietf.org Subject: Re: [openpgp] Fingerprints and their collisions resistance X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 16:18:27 -0000 The proposal that we had a long time ago which was essentially prefix a = hash with an algorithm number was a good one. I remember everyone = thinking it was a good idea and no one belling the cat. I vaguely = remember someone writing up an I-D on it, too. That's the way I'd go, as it's future-proofed. Jon From buanzo@buanzo.com.ar Thu Jan 3 08:22:06 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97DEF21F8CCE for ; Thu, 3 Jan 2013 08:22:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id clx2wN-l25tt for ; Thu, 3 Jan 2013 08:22:05 -0800 (PST) Received: from mail-vb0-f50.google.com (mail-vb0-f50.google.com [209.85.212.50]) by ietfa.amsl.com (Postfix) with ESMTP id A660C21F8CCC for ; Thu, 3 Jan 2013 08:22:05 -0800 (PST) Received: by mail-vb0-f50.google.com with SMTP id ft2so3855948vbb.23 for ; Thu, 03 Jan 2013 08:22:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=+pIjLSpYnG9s9O0KPB3fWJAERGUrRrSIcxSJ1ieSsTs=; b=p2RdXdKBneGp5AAuqNrbSx6jYzoX+zhMfaSo3ciKjFQ2iTkZtITC89d2xpjdzN2TpM DQYmqchYWYlZH+mnbw8HXiFJcW4JjAw13cqSMRl3uMoH5doODKXZkEkry3gBc4JV11Rq JpMbH2px1YTt4xW0rvxeFeuNUvo0GaylkNwuHLcpNFZ6RhnUCNrog9vRejrzMhJjvUiS OBu1cBhkBPBBRMs3i09YwJMeyH3GtQGFBOrfdu3emTpCOx4BsLiMKkRNsCX4i6kyxwAs nF7qCa8FTlHGbTB6mz7hN+wls6drhnz+oSYI+GMHxtmG3mXzk8slfNZxVBfAZcQgA4EG eyaA== MIME-Version: 1.0 Received: by 10.52.36.100 with SMTP id p4mr67451680vdj.16.1357230124864; Thu, 03 Jan 2013 08:22:04 -0800 (PST) Received: by 10.58.253.137 with HTTP; Thu, 3 Jan 2013 08:22:04 -0800 (PST) Received: by 10.58.253.137 with HTTP; Thu, 3 Jan 2013 08:22:04 -0800 (PST) In-Reply-To: References: <50E530D6.6020609@brainhub.org> Date: Thu, 3 Jan 2013 13:22:04 -0300 Message-ID: From: "Arturo 'Buanzo' Busleiman" To: Jon Callas Content-Type: multipart/alternative; boundary=20cf307c9f1478948204d264c33c X-Gm-Message-State: ALoCoQlkWkUK6m67Fcj7D3uDhC0PmmrXmtMY57y8jBkrqmwwHkO9n4RQ25nn8N0bcVEF6P8PfM93 Cc: Andrey Jivsov , openpgp@ietf.org Subject: Re: [openpgp] Fingerprints and their collisions resistance X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 16:22:06 -0000 --20cf307c9f1478948204d264c33c Content-Type: text/plain; charset=ISO-8859-1 +1 Jon! On Jan 3, 2013 1:18 PM, "Jon Callas" wrote: > The proposal that we had a long time ago which was essentially prefix a > hash with an algorithm number was a good one. I remember everyone thinking > it was a good idea and no one belling the cat. I vaguely remember someone > writing up an I-D on it, too. > > That's the way I'd go, as it's future-proofed. > > Jon > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > --20cf307c9f1478948204d264c33c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

+1 Jon!

On Jan 3, 2013 1:18 PM, "Jon Callas" &= lt;jon@callas.org> wrote:
The proposal that we had a long time ago which was essentially prefix a has= h with an algorithm number was a good one. I remember everyone thinking it = was a good idea and no one belling the cat. I vaguely remember someone writ= ing up an I-D on it, too.

That's the way I'd go, as it's future-proofed.

=A0 =A0 =A0 =A0 Jon

_______________________________________________
openpgp mailing list
openpgp@ietf.org
https://www.ietf.org/mailman/listinfo/openpgp
--20cf307c9f1478948204d264c33c-- From singpolyma@singpolyma.net Thu Jan 3 08:54:48 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 753D621F8CEB for ; Thu, 3 Jan 2013 08:54:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kxnRGb7k7Xw0 for ; Thu, 3 Jan 2013 08:54:48 -0800 (PST) Received: from singpolyma.net (singpolyma.net [64.15.152.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7CDB921F8CEE for ; Thu, 3 Jan 2013 08:54:47 -0800 (PST) Received: by singpolyma.net (Postfix, from userid 1002) id B3202CC229C; Thu, 3 Jan 2013 16:54:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=singpolyma.net; s=iweb; t=1357232086; bh=+RrKvUwg2El4DODg9Zbzael92WxpKPS5+y70F5iDtWs=; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type; b=aisc2Z3pkBJTb61D4S6mPfaIJeRarG89ZS8PrhFMqS9/DPVx0KBXensYfEh1puc7z BMaSUTxWWd3FLJRQN8OfGD8NTqqKkDK91IInt5VtmoIOidnQ+1ynv1TZJQIWtMOp+1 fV6X9H1alxlh9AGsYH9ltf6qfXBViZrDYmQDqhMU= Date: Thu, 3 Jan 2013 11:54:45 -0500 From: Stephen Paul Weber To: openpgp@ietf.org Message-ID: <20130103165445.GC1808@singpolyma-svelti> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="azLHFNyN32YCQGCU" Content-Disposition: inline Jabber-ID: singpolyma@singpolyma.net OpenPGP: id=CE519CDE; url=https://singpolyma.net/public.asc X-URL: https://singpolyma.net User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [openpgp] Secret key checksum X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 16:54:48 -0000 --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Encrypted secret keys can be protected with SHA1 or with a two-octet=20 checksum. Unencrypted secret keys can only be protected with a two-octet= =20 checksum. What is the intended purpose of this integrity protection? What are the=20 security issues with using the weaker checksum over SHA1? Are these=20 security issues not present on an unencrypted secret key? --=20 Stephen Paul Weber, @singpolyma See for how I prefer to be contacted edition right joseph --azLHFNyN32YCQGCU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJQ5bfUAAoJENEcKRHOUZze4CsQANAeQy5mLeV4MW1BhH28eSAl CM4q0haCP4ves3BI5hKlu9WtZZPlFoEKp+PZ6VcoX2q8fSUF2/maD2sdsc5FFCki pew2uc/jdwdhrqMH3gV06b3WFykdxdrXrlKyIcFGqiCy3GRHo5jLtNNzTHE+0To2 Vi4x37DvI8zU6IlhanhuttNZAOjhl/zWepB7ZJ+8nKLf6aqVlfb/PUv//Gw9MOVb ntOr2F2kQBDCgeQZDFwXlapu9SJU3XWmZY0NyZLQsng0aJFlAGmxNSPz4o1QXsHS 5UZ2DyQqveR4TM3kjxpbOfd8zpsf3zFsZrk0MEHqpobyXmnWvGLafOBfgiFkeT6G QyNe4reAhqc9+CkAiZrupXICjyQmBeE1Qc3G5PJcX+abIZjsyu8SMTc4gyNCl8Sr JKxiqUZaemB4uUjUnYCG0EhfEK7WvysqoeJTegK1Gni9A0XxU5R+RKUrThyhfLzF uMnOPP86gD//ABEz6UHW7Ls/rZKQJRZrmyU2eYNbd1hsGue9BWN/um4Yph/4/OSW zbvc/hHtfkRq2g7NzxLSHzrx/ZEnohxy9bFlHgwfVicXAKxBShoSYKLOaQuZIyDI Z6VHFpb3US/FYuLGxyryk7CO0mH45mlbRy1SPDmopKF11y2AARWWFGIjpJr7gA9R LiR+JTCREvzCDcd+6Vo2 =lORe -----END PGP SIGNATURE----- --azLHFNyN32YCQGCU-- From openpgp@brainhub.org Thu Jan 3 11:06:23 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE3121F8A9B for ; Thu, 3 Jan 2013 11:06:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uSKwEJxWtrH2 for ; Thu, 3 Jan 2013 11:06:22 -0800 (PST) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by ietfa.amsl.com (Postfix) with ESMTP id D720821F86C8 for ; Thu, 3 Jan 2013 11:06:19 -0800 (PST) Received: from omta04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by qmta01.emeryville.ca.mail.comcast.net with comcast id jTCh1k0050lTkoCA1X6KGs; Thu, 03 Jan 2013 19:06:19 +0000 Received: from [192.168.1.8] ([69.181.162.123]) by omta04.emeryville.ca.mail.comcast.net with comcast id jX6J1k00B2g33ZR8QX6Jau; Thu, 03 Jan 2013 19:06:19 +0000 Message-ID: <50E5D6AA.6060200@brainhub.org> Date: Thu, 03 Jan 2013 11:06:18 -0800 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120605 Thunderbird/13.0 MIME-Version: 1.0 To: Jon Callas References: <50E530D6.6020609@brainhub.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1357239979; bh=xwEzLH63Yq1BBN6wvI5cJI+OzvCAb5pqSXNPSkwbLbo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=UREB7lrjB7X9EJm2vb3nEq2VKIKqQgmvrSwAJi3O+b0+SqTqM3O7L4V4JmX6a/nBE 5idDy21ni/iIStFKuQv82ygmMMhKzmFuXUPX+I3Tj6saTdQTYMkxbwM77rdFX31mfA RrJztSnu8E8FmA1X/Q9SIlDsvbeD/XNy80e89qrqW3EQ4t9iQa1/LKlMYZW50Vdv2R 9EUGWLAvbCAva1UaU+0r1b4Iq1cumYVhjvxGIaouMSRvlcsk7fXmnDZamqaJ0AaEbj Cwfx9PKksTJQMvyetZ1YUXUHCP8fzvkYaBA/u+m5sxakJA/5i3n9xRvciYHRzpDNUB bvrReSBqsKDWA== Cc: openpgp@ietf.org Subject: Re: [openpgp] Fingerprints and their collisions resistance X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 19:06:23 -0000 On 01/03/2013 08:17 AM, Jon Callas wrote: > The proposal that we had a long time ago which was essentially prefix a hash with an algorithm number was a good one. I remember everyone thinking it was a good idea and no one belling the cat. I vaguely remember someone writing up an I-D on it, too. > > That's the way I'd go, as it's future-proofed. > > Jon > I am a big fan of algorithm agility myself, but I have a difficult time justifying the additional complexity that the new *suite* of the fingerprints would bring v.s. just one new fingerprint algorithm. Compare the situation with the AES. There are 3 AES sizes and other ciphers in use. Other ciphers exist as legacy ciphers that preceded AES or for regulatory reasons. 3 AES sizes exist for performance reasons. None of these concerns apply for the new algorithm we are introducing ( we have clarity of future strength, small input for hashing, no export/import control of encryption). Fingerptins are special data structures because they are sometimes input by humans. We now have SHA-3, which is good for a few decades ( and also SHA-2s are not so bad ). Here is a more technical description, to be specific: Let's say we choose SHA-3-384, which is no more difficult to implement than SHA-2. We then simply use the current fingerprint algorithm but instead of SHA-1 use SHA-3-384. Then allow truncation of the output (it's already implied by the 8 byte keyIDs). 20 byte fingerprint on a business card may be reasonable, but we also would like to have full strength for regulatory compliance. Consider not hashing the key creation date. Fixing all the variables in this paragraph, we have the new single fingerprint algorithm. To put it differently, users may care about the hash associated with a signed message, but I don't think they materially care about the flavour of the fingerprint (as long as it's a "strong" one). From tony@att.com Thu Jan 3 11:26:49 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E679521F86C0 for ; Thu, 3 Jan 2013 11:26:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rCK+m-DA8jKt for ; Thu, 3 Jan 2013 11:26:49 -0800 (PST) Received: from nbfkord-smmo08.seg.att.com (nbfkord-smmo08.seg.att.com [209.65.160.95]) by ietfa.amsl.com (Postfix) with ESMTP id 4829721F86A2 for ; Thu, 3 Jan 2013 11:26:49 -0800 (PST) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.11.0-12) over TLS secured channel with ESMTP id 87bd5e05.0.1260417.00-426.3473883.nbfkord-smmo08.seg.att.com (envelope-from ); Thu, 03 Jan 2013 19:26:49 +0000 (UTC) X-MXL-Hash: 50e5db794988ea42-7795238488dabaaee51789477a2e125a863c61d6 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r03JQm9C018756 for ; Thu, 3 Jan 2013 14:26:48 -0500 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r03JQgTB018602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 3 Jan 2013 14:26:45 -0500 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by sflint01.pst.cso.att.com (RSA Interceptor) for ; Thu, 3 Jan 2013 14:26:24 -0500 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id r03JQMPQ003402 for ; Thu, 3 Jan 2013 14:26:22 -0500 Received: from dns.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id r03JQI1Q003278 for ; Thu, 3 Jan 2013 14:26:18 -0500 Received: from [135.91.110.142] (dn135-91-110-142.dhcpn.ugn.att.com[135.91.110.142]) by maillennium.att.com (mailgw1) with ESMTP id <20130103192550gw100632g9e> (Authid: tony); Thu, 3 Jan 2013 19:25:51 +0000 X-Originating-IP: [135.91.110.142] Message-ID: <50E5DB59.9090109@att.com> Date: Thu, 03 Jan 2013 14:26:17 -0500 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <50E530D6.6020609@brainhub.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=D4rw3Itj c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=kKemRe_CjxUA:10 a=PJtIR_1cTkwA:10 a=3DrfuPucC9MA:10 a=ofM] X-AnalysisOut: [gfj31e3cA:10 a=BLceEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zQP7CpK] X-AnalysisOut: [OAAAA:8 a=6qorCaAYhBoA:10 a=Dzt918kYCTuIse52W7wA:9 a=wPNLv] X-AnalysisOut: [fGTeEIA:10 a=Hz7IrDYlS0cA:10] Subject: Re: [openpgp] Fingerprints and their collisions resistance X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 19:26:50 -0000 On 1/3/2013 4:33 AM, Nicholas Cole wrote: > One issue with SHA-3 is that the fingerprints are going to be very > long. How should these be displayed to the user? Hex strings seem > unsuitable for this task, and I think any new standard should > recommend that fingerprints be displayed in some other way - probably > using a different base. SHA3 is defined for a variety of hash sizes. Using SHA3 does not imply a long fingerprint. Tony Hansen tony@att.com From jcea@jcea.es Thu Jan 3 12:14:42 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC6EC21F8D57 for ; Thu, 3 Jan 2013 12:14:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXG08eEBRi5T for ; Thu, 3 Jan 2013 12:14:41 -0800 (PST) Received: from smtp.jcea.es (babylon5.jcea.es [94.23.84.75]) by ietfa.amsl.com (Postfix) with ESMTP id 9D3F221F8D49 for ; Thu, 3 Jan 2013 12:14:41 -0800 (PST) Received: from [10.8.0.6] (ks27448.kimsufi.com [91.121.85.130]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.jcea.es (Postfix) with ESMTPSA id 3YcgMg5dv6zYX for ; Thu, 3 Jan 2013 21:14:39 +0100 (CET) Message-ID: <50E5E6AE.5050201@jcea.es> Date: Thu, 03 Jan 2013 21:14:38 +0100 From: Jesus Cea User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: openpgp@ietf.org X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit X-Spam-Probability-jcea: Ham (0.0%) rz: False [5a3e2b7b38e9409744bbabcbf4c1b512] (None) Subject: [openpgp] keyserver protocol X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 20:14:43 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, everybody. I have been following SKS mailing lists for years and I wonder how can OpenPGP rely on an undocumented protocol, with only a single codebase written in a unusual language for something so paramount as keyservers and key distribution :-). http://minsky-primus.homeip.net/sks/ I don't have a bad eye for SKS. I think it covers a badly needed need and it is not its fault if there is no competition. I read the master thesis that was seminal writing for this project, but the exact protocol is not documented and must be digged from the sourcecode... written in Ocaml :-). I am really uncomfy with this situation, and I wonder if I am overreacting, or people are not actually aware of this "monoculture" and lack of interoperativity... Please, consider this *NOT* an attack to SKS (thanks god we have it!) but a heads up to think about it. - -- Jesús Cea Avión _/_/ _/_/_/ _/_/_/ jcea@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQCVAwUBUOXmrplgi5GaxT1NAQJE/gQApktUxJ2pMJmlNKADeOUdEIQqDcklW3LG lA52an7QuSFZ4JijFYMMXB+IOkQ0CQU9sghYZw63ZciLr3Y6bYKYCRgEFUGyF4hH /FiTmlUaQYEgrFPYSmQ0/ZHxiiFs9tVjmid1khBJTvsHNmhIvxbD0n4qZbp5p70g gfYrgLr0MPQ= =HCAJ -----END PGP SIGNATURE----- From openpgp@brainhub.org Thu Jan 3 14:33:56 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BE7221F8DD4 for ; Thu, 3 Jan 2013 14:33:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sd1DKhXoCr6L for ; Thu, 3 Jan 2013 14:33:56 -0800 (PST) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:227]) by ietfa.amsl.com (Postfix) with ESMTP id DEC5521F8DCB for ; Thu, 3 Jan 2013 14:33:55 -0800 (PST) Received: from omta17.emeryville.ca.mail.comcast.net ([76.96.30.73]) by qmta12.emeryville.ca.mail.comcast.net with comcast id jYow1k0071afHeLACaZvRo; Thu, 03 Jan 2013 22:33:55 +0000 Received: from [192.168.1.8] ([69.181.162.123]) by omta17.emeryville.ca.mail.comcast.net with comcast id jaZk1k00A2g33ZR8daZuP3; Thu, 03 Jan 2013 22:33:55 +0000 Message-ID: <50E60748.3040103@brainhub.org> Date: Thu, 03 Jan 2013 14:33:44 -0800 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120605 Thunderbird/13.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <50E530D6.6020609@brainhub.org> <50E5494E.6090905@iang.org> In-Reply-To: <50E5494E.6090905@iang.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1357252435; bh=ddLeS+KzB2k9VU1sTv4oixy6ePHJOBb/61IDzPMFoWA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=UaSNv5QJabsE0qmyFCnQpWFM3R0Ljjs6Q0Mhw53H9WjY96cmUjyHGZfvc+Q/vx0Zm /Q4+rmezKQqhHBjt+Lmz3wJcAL/8tG5j3g66iGQN7rT1Ip+v8G+FZbw7kxZna7uOTU sF417lu4kycDtdzZkyJcn9a18KuYG12EYMaBshFkIUgyxDYXALBBCPET5kW4kpfSYq f7A0AhQJmC/A28LF7jM7uEr75ycXP0obALkgSpFqWFH4Ob261tTfTLC0K1Woit9s4b GkEhQAol31DDn+/tK2TR03KwUaZWuTo+pAyX5kiBm9+v98QpHJi7sH/pPMwnmd8dE0 93r7xYMqQxLWQ== Subject: Re: [openpgp] Fingerprints and their collisions resistance X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 22:33:56 -0000 On 01/03/2013 01:03 AM, ianG wrote: ... > Now that SHA-3 is settled, it seems reasonable to clean out all of the > SHA-1s. > ... > > On another related point - have the MD numbers been allocated for SHA3 > in its various guises? In the process of writing such a draft I noticed that the only place in OpenPGP where SHA1 is used in collision resistance sensitive way without the possibility to change it is fingerprints. For this reason OpenPGP fingerprints stand out because these are the data structures that technically make (or soon will make) RFC 4880 non-compliant with recognized standards. I would separate the issue of fingerprints depending on known SHA1 weaknesses from any other task that can be categorized as "OpenPGP V5". Speaking of the Keccak in OpenPGP draft, I thought that it would be important to gather the feeling about the path of fixing the fingerprints. These issues are more dependent as seems. For example, if you have to use SHA-3-384 for fingerprints, it affects the decisions about SHOULDs for hashes elsewhere. I have this Keccak in OpenPGP darft written, waiting to for the NIST to publish SHA-3 and the OIDs assigned. From openpgp@brainhub.org Thu Jan 3 14:38:39 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08C7B21F8DA6 for ; Thu, 3 Jan 2013 14:38:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sMGPdkrdN9MS for ; Thu, 3 Jan 2013 14:38:38 -0800 (PST) Received: from qmta11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:211]) by ietfa.amsl.com (Postfix) with ESMTP id 8813621F8D7F for ; Thu, 3 Jan 2013 14:38:38 -0800 (PST) Received: from omta21.emeryville.ca.mail.comcast.net ([76.96.30.88]) by qmta11.emeryville.ca.mail.comcast.net with comcast id jTPy1k0041u4NiLABaeeaR; Thu, 03 Jan 2013 22:38:38 +0000 Received: from [192.168.1.8] ([69.181.162.123]) by omta21.emeryville.ca.mail.comcast.net with comcast id jaec1k00X2g33ZR8haedDo; Thu, 03 Jan 2013 22:38:37 +0000 Message-ID: <50E6086C.2080108@brainhub.org> Date: Thu, 03 Jan 2013 14:38:36 -0800 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120605 Thunderbird/13.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <50E530D6.6020609@brainhub.org> <50E5DB59.9090109@att.com> In-Reply-To: <50E5DB59.9090109@att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1357252718; bh=GMysEjnD/iEe3weUKiaLcdTKvOmv73G2FcwqolrU4Gk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=M47bHg87sMZeLqS5ZQgH6/isX389cMkYLH5wdK1X9NgmOfNWKasJWJ6BL2bNHDbKM EnbJRdL9VULaffmP2fDPjSgSyQWGR2LZzJjEI1H4FlWwXcqJW3Rxbe1n207geji9RA +V/NBXPGiP30p4JYO0RFGa7INJC+pSAkdzsRoFgzvgSK23P46Z88esRlW+RY8YQnoa 1ub3+/aeePrm8ddKKix8WG9j1rkjmqIH4/hhBYRHi84/tuAxV1qwXI/90tEon9/1io HCP9NeHpAvH8/rKHPF4OFGheUInfC6vAcXAaPrg/GU1RpvK4rxNIEB3GF6dKZFdGAn SMr5MWZEB0GLg== Subject: Re: [openpgp] Fingerprints and their collisions resistance X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 22:38:39 -0000 On 01/03/2013 11:26 AM, Tony Hansen wrote: > On 1/3/2013 4:33 AM, Nicholas Cole wrote: >> One issue with SHA-3 is that the fingerprints are going to be very >> long. How should these be displayed to the user? Hex strings seem >> unsuitable for this task, and I think any new standard should >> recommend that fingerprints be displayed in some other way - probably >> using a different base. > > SHA3 is defined for a variety of hash sizes. Using SHA3 does not imply a > long fingerprint. I would argue for SHA-3-384 and then possible truncation. Keccak of different sizes is pretty much implemented as internal truncation anyway (of a large sponge structure), plus there is no different initialization vectors as for SHA-2 for different hash sizes. The KeyIDs are the truncation of the fingerprint already. From dshaw@jabberwocky.com Thu Jan 3 14:53:18 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5EB021F8DC1 for ; Thu, 3 Jan 2013 14:53:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hOMtcmVJQDWu for ; Thu, 3 Jan 2013 14:53:18 -0800 (PST) Received: from walrus.jabberwocky.com (walrus.jabberwocky.com [173.9.29.57]) by ietfa.amsl.com (Postfix) with ESMTP id 0B49E21F8DBF for ; Thu, 3 Jan 2013 14:53:17 -0800 (PST) Received: from dshaw.nasuni.net (vpn.nasuni.com [173.166.63.186]) (authenticated bits=0) by walrus.jabberwocky.com (8.14.4/8.14.4) with ESMTP id r03MrFfO031067 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 3 Jan 2013 17:53:15 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: David Shaw In-Reply-To: <50E5E6AE.5050201@jcea.es> Date: Thu, 3 Jan 2013 17:53:15 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3C32E4F1-6B48-4561-94FF-7489D44E36CC@jabberwocky.com> References: <50E5E6AE.5050201@jcea.es> To: Jesus Cea X-Mailer: Apple Mail (2.1499) Cc: openpgp@ietf.org Subject: Re: [openpgp] keyserver protocol X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 22:53:18 -0000 On Jan 3, 2013, at 3:14 PM, Jesus Cea wrote: > Hi, everybody. >=20 > I have been following SKS mailing lists for years and I wonder how can > OpenPGP rely on an undocumented protocol, with only a single codebase > written in a unusual language for something so paramount as keyservers > and key distribution :-). >=20 > http://minsky-primus.homeip.net/sks/ I actually wrote this up at one point as an informational draft, but for = one reason or another didn't finish submitting it. If there is = interest, I can clean it up and submit: http://tools.ietf.org/id/draft-shaw-openpgp-hkp-00.txt David From wk@gnupg.org Thu Jan 3 14:57:24 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C034421F8DD5 for ; Thu, 3 Jan 2013 14:57:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ooza8q55QvfP for ; Thu, 3 Jan 2013 14:57:23 -0800 (PST) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by ietfa.amsl.com (Postfix) with ESMTP id 3F02521F8AA6 for ; Thu, 3 Jan 2013 14:57:20 -0800 (PST) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.72 #1 (Debian)) id 1Tqtix-0000Kc-Ml for ; Thu, 03 Jan 2013 23:57:19 +0100 Received: from wk by vigenere.g10code.de with local (Exim 4.77 #3 (Debian)) id 1TqtgH-0008SR-6r; Thu, 03 Jan 2013 23:54:33 +0100 From: Werner Koch To: Andrey Jivsov References: <50E530D6.6020609@brainhub.org> <50E5D6AA.6060200@brainhub.org> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=1E42B367; url=finger:wk@g10code.com Date: Thu, 03 Jan 2013 23:54:33 +0100 In-Reply-To: <50E5D6AA.6060200@brainhub.org> (Andrey Jivsov's message of "Thu, 03 Jan 2013 11:06:18 -0800") Message-ID: <874nixev2u.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: openpgp@ietf.org, Jon Callas Subject: Re: [openpgp] Fingerprints and their collisions resistance X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 22:57:24 -0000 On Thu, 3 Jan 2013 20:06, openpgp@brainhub.org said: > AES or for regulatory reasons. 3 AES sizes exist for performance > reasons. I'd say for marketing reasons. > export/import control of encryption). Fingerptins are special data > structures because they are sometimes input by humans. Well, humans compare fingerprints but don't enter them. I doubt that I ever did this in the last 20 years. > Let's say we choose SHA-3-384, which is no more difficult to implement > than SHA-2. We then simply use the current fingerprint algorithm but Except that SHA-2 is already in use and has hardware support. > instead of SHA-1 use SHA-3-384. Then allow truncation of the output > (it's already implied by the 8 byte keyIDs). 20 byte fingerprint on a > business card may be reasonable, but we also would like to have full So why should we truncate the fingerprint? Is there a reason to believe that truncation to 160 bit of SHA-2 or SHA-3 is seriously more secure than SHA-1? I don't know. > strength for regulatory compliance. Consider not hashing the key > creation date. Fixing all the variables in this paragraph, we have the What would be the advantage of this except for yet another code path. > signed message, but I don't think they materially care about the > flavour of the fingerprint (as long as it's a "strong" one). They will care if a key suddenly comes with two different fingerprints. We never had this situation in OpenPGP. Recall how long it took to get rid of v3 keys. Thus if we want a new fingerprint algorithm we need to change more than just this. BTW, what about re-establishing the OpenPGP WG? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg@fifthhorseman.net Thu Jan 3 15:08:51 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C03BC21F8D29 for ; Thu, 3 Jan 2013 15:08:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JoMHm9ZtDOfk for ; Thu, 3 Jan 2013 15:08:50 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 89DA321F8D12 for ; Thu, 3 Jan 2013 15:08:50 -0800 (PST) Received: from [192.168.13.194] (lair.fifthhorseman.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id A4742F970; Thu, 3 Jan 2013 18:08:45 -0500 (EST) Message-ID: <50E60F7A.8000001@fifthhorseman.net> Date: Thu, 03 Jan 2013 18:08:42 -0500 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Icedove/17.0 MIME-Version: 1.0 To: Andrey Jivsov References: <50E530D6.6020609@brainhub.org> <50E5494E.6090905@iang.org> <50E60748.3040103@brainhub.org> In-Reply-To: <50E60748.3040103@brainhub.org> X-Enigmail-Version: 1.5 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="----enig2IHEMGHKCJARCUKLRONKF" Cc: openpgp@ietf.org Subject: Re: [openpgp] Fingerprints and their collisions resistance X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 23:08:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2IHEMGHKCJARCUKLRONKF Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 01/03/2013 05:33 PM, Andrey Jivsov wrote: > In the process of writing such a draft I noticed that the only place in= > OpenPGP where SHA1 is used in collision resistance sensitive way withou= t > the possibility to change it is fingerprints. As i mentioned on the discussion on the GnuPG discussion list, i remain unconvinced that OpenPGP fingerprints need to be collision-resistant. They certainly need to be able to resist preimage attacks, but i haven't seen any convincing attacks that make me think collision resistance is an issue. Here's the recent GnuPG discussion: http://thread.gmane.org/gmane.comp.encryption.gpg.devel/17366/focus=3D17= 389 And here's earlier discussion from Daniel Nagy and myself on this list suggesting that collision-resistance is an issue for fingerprints: http://thread.gmane.org/gmane.ietf.openpgp/6012/focus=3D6013 http://thread.gmane.org/gmane.ietf.openpgp/7115/focus=3D7126 If anyone disagrees with this analysis, i would be interested in hearing how failed collision-resistance of the fingerprint mechanism could lead to practical attacks in OpenPGP. > I have this Keccak in OpenPGP darft written, waiting to for the NIST to= > publish SHA-3 and the OIDs assigned. thanks for doing this, i think this will be a useful contribution. Regards, --dkg ------enig2IHEMGHKCJARCUKLRONKF 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.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJQ5g96XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwRUU1QkU5NzkyODJEODBCOUY3NTQwRjFD Q0QyRUQ5NEQyMTczOUU5AAoJEMzS7ZTSFznpt5QP/0PlyigaLMDHmxXRL960fRbo ynOG9PNU5/nxQP++ZfGrLvE3m/1F3k/+O2UdDTdgTzZDXujIbbxR/EDJRD3AKVo6 fGVwRQYy3dm1aluOZ/uDJKslaTnVCRoBTbMaOlXfSmwZPwoNK7I0YzgLUHaB8gee xairbHthubOHQW2EK2OtDSBng7uY7RXZUex654jhEUw4rKhwFF3CkMujEegp0kN9 /5iJyRGGv1vyLGj0wH0gWqwK9wa8337hWLRYJY0SrIEDHJ/I0plCruN5FiG49AX+ dhzHuxi3QP097Za0F9egb6iufeRhDdHMuf+oESIf+d6XOv5e3/OT0ugFK7PukxEe bNFrwVuVpKidTZicwC+yKT7U3IXZ/f9iuKac5uEOrqgXjjDQ5W15JrQBrWaWa4rg yXYZrznnzclH2b990xW36pF3twubZRm3bA3/qzLucPd8BiDRZVUtymJd6Wv1Z9AL GdseETHhHzmIJgAoe/AHtBvg2mo40/3gM2zf25QoEIzSFHgguXK+AgQV3ETbvWh2 EjtpMwL+sEyo463wYEFOMXbNGSe8pvQTEBvsMhlzWX8rLOChg/ZRDwEliU1/7L/A Y1r+zHsdt22sGE5NjWB7/BYvPzUW3szWd8i4vOCI5kJ1PwaGf+JlVdQwK+RhTp6m RBE4NJJUVPhjfjzTDDIN =EkZe -----END PGP SIGNATURE----- ------enig2IHEMGHKCJARCUKLRONKF-- From dkg@fifthhorseman.net Thu Jan 3 15:29:19 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7802321F8D26 for ; Thu, 3 Jan 2013 15:29:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id of4mGiLdfWlc for ; Thu, 3 Jan 2013 15:29:18 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id CB1D721F8CF1 for ; Thu, 3 Jan 2013 15:29:18 -0800 (PST) Received: from [192.168.13.194] (lair.fifthhorseman.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 1726FF970; Thu, 3 Jan 2013 18:29:04 -0500 (EST) Message-ID: <50E6143D.2040800@fifthhorseman.net> Date: Thu, 03 Jan 2013 18:29:01 -0500 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Icedove/17.0 MIME-Version: 1.0 To: David Shaw References: <50E5E6AE.5050201@jcea.es> <3C32E4F1-6B48-4561-94FF-7489D44E36CC@jabberwocky.com> In-Reply-To: <3C32E4F1-6B48-4561-94FF-7489D44E36CC@jabberwocky.com> X-Enigmail-Version: 1.5 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="----enig2CBXVMHRNJVAFKAJOJWQJ" Cc: Jesus Cea , openpgp@ietf.org Subject: Re: [openpgp] keyserver protocol X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 23:29:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2CBXVMHRNJVAFKAJOJWQJ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 01/03/2013 05:53 PM, David Shaw wrote: > On Jan 3, 2013, at 3:14 PM, Jesus Cea wrote: >=20 >> I have been following SKS mailing lists for years and I wonder how can= >> OpenPGP rely on an undocumented protocol, with only a single codebase >> written in a unusual language for something so paramount as keyservers= >> and key distribution :-). >> >> http://minsky-primus.homeip.net/sks/ >=20 > I actually wrote this up at one point as an informational draft, but fo= r one reason or another didn't finish submitting it. If there is interes= t, I can clean it up and submit: >=20 > http://tools.ietf.org/id/draft-shaw-openpgp-hkp-00.txt I'd be interested in seeing the HKP draft revised, especially since modern use seems to have diverged from that draft a bit. It seems like Jesus might be more concerned about the SKS gossip protocol, which is even more poorly-documented than HKP. Jesus, i suspect that sks-devel@nongnu.org is the best place to discuss the gossip protocol. It's a known issue that it is poorly-documented (no one is happy about it, including Yaron Minsky, the lead author of SKS), and there is at least one other project that has been discussed on that list that is trying to make a compatible/interoperable implementation in go: https://launchpad.net/hockeypuck It's a work in progress, and i'm sure any help would be appreciated. Regards, --dkg ------enig2CBXVMHRNJVAFKAJOJWQJ 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.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJQ5hQ9XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwRUU1QkU5NzkyODJEODBCOUY3NTQwRjFD Q0QyRUQ5NEQyMTczOUU5AAoJEMzS7ZTSFznp4Z4P/3Z1mRmIKqM6sSJ4TnGjsNJa wQEKHEIxp7by/fCw1oQq16KMIBc0qOViOuju4k4b06odEgs6H2kFEpQPtEiGjGLc klN4NyTiZuBhvYDIDJIpG8srJwe45OKbtc+ojS4adroqn1isyLplI0J1HIzis2y8 Ng/nrXW7qty0PO+3YdqFuy1RBGXkKlGnv6XXo6X4opGTCtn1b+0CkZLCCjh6NQKd mQ9/+zB4Ffxd2kSi45sC2pmBIRAtvJePISsOpoJE0FO7Bl/1GETytWbwBQmJ4NKF b4NmNpU93oXNaCla5LlsQZqqs4hZp9J6wblw6KpzWqDKUKqgzgFp9BQjDnbw4YuG xU4uKUbQo6WRwrPEGLOHxTVhVAWinoKgJEAhvpsM/3NeZCqVCPcCOMYFFMYsu4MR iuS7hBad0JK86DjWx4s7dr4wuyKKan2zPhyxVKEtPphBG3/cM/V9cvAqxnbJRXtb yP5Av3ji1uzStJ3MclaMPTEQiC7Q7/zMtdJQxyu8EK62GpfDoaUk59k6Czm/W6HZ YFk0WM3Fr1CeHhMHSStSlOXvzhRTI59bNQtt7WdOsaPQcGg5KlEBDlYUzxcUmd1n VxAClACLQnuTopDp37ZIy9lFsGGju6xkUmBSS1CJnPo8umb0X1Nt+q9NcRBkMt7E v53dwRHcExpY3k8oG/J2 =YM4z -----END PGP SIGNATURE----- ------enig2CBXVMHRNJVAFKAJOJWQJ-- From openpgp@brainhub.org Thu Jan 3 15:30:16 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8133921F8D41 for ; Thu, 3 Jan 2013 15:30:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yd3FB4VPSGVx for ; Thu, 3 Jan 2013 15:30:15 -0800 (PST) Received: from qmta04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:40]) by ietfa.amsl.com (Postfix) with ESMTP id D0A2921F8D29 for ; Thu, 3 Jan 2013 15:30:15 -0800 (PST) Received: from omta09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by qmta04.emeryville.ca.mail.comcast.net with comcast id jbEv1k0020S2fkCA4bWFGk; Thu, 03 Jan 2013 23:30:15 +0000 Received: from [192.168.1.8] ([69.181.162.123]) by omta09.emeryville.ca.mail.comcast.net with comcast id jbWE1k0092g33ZR8VbWETb; Thu, 03 Jan 2013 23:30:15 +0000 Message-ID: <50E61486.9010209@brainhub.org> Date: Thu, 03 Jan 2013 15:30:14 -0800 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120605 Thunderbird/13.0 MIME-Version: 1.0 To: Werner Koch References: <50E530D6.6020609@brainhub.org> <50E5D6AA.6060200@brainhub.org> <874nixev2u.fsf@vigenere.g10code.de> In-Reply-To: <874nixev2u.fsf@vigenere.g10code.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1357255815; bh=Lm/AHP1yXgyuBm/lDz11YbPNRpgmIAxPH/Bl+W5NC54=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=mswPboFt/tlK8I2EtMjYnJYDPDRFS4QuzxqTWZeHi8Gn+dZIXdO/USV7l5GLldubX oqD7eBhGMFYXATZDy1MFeFVl6Gnxwdm/QtXnl0ye5hXL9ikJ/MZqiAT6hzEP4L4xFo 8gE+/okgY0t9Sub5uxnWXHXeROJ//tI3FEUIyZxmO7Ns6MI/BhRLlcncIvNG1uXqrN SBhKbXigyiIC40lRYSi9PG15OZGIm8b92vTKLw5rl/V/dPVkVdBtTI+/tvBCiYw4lQ sDL5O1WPLQ+FGlQXecfQ7/S80dqqq/oYV3h8f5HVMs+AwImRdDSsr7qvjYGxlTOGcB RJ/EWCXlsF54Q== Cc: Andrey Jivsov , openpgp@ietf.org, Jon Callas Subject: Re: [openpgp] Fingerprints and their collisions resistance X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 23:30:16 -0000 On 01/03/2013 02:54 PM, Werner Koch wrote: > On Thu, 3 Jan 2013 20:06, openpgp@brainhub.org said: > > ... >> Let's say we choose SHA-3-384, which is no more difficult to implement >> than SHA-2. We then simply use the current fingerprint algorithm but > Except that SHA-2 is already in use and has hardware support. ... but there is no reason why SHA-3 will not optimized in the future. BTW, which SHA-2 friendly CPU feature we are talking about? ( other than Intel's plans to add cycle shift ) In any case, please note that we are talking about hashing the key material and thus the performance of the hash algorithm doesn't matter. My preference for SHA-3 is to satisfy the concerns of algorithm agility. I argue for a hardcoded algorithm, and thus the natural choice is the strongest of SHA that will be future-proof for regulatory compliance. I would also be OK to do SHA-2 + SHA-3, TLS style, to be future proof, but this seems too paranoid. >> instead of SHA-1 use SHA-3-384. Then allow truncation of the output >> (it's already implied by the 8 byte keyIDs). 20 byte fingerprint on a >> business card may be reasonable, but we also would like to have full > So why should we truncate the fingerprint? Is there a reason to believe > that truncation to 160 bit of SHA-2 or SHA-3 is seriously more secure > than SHA-1? I don't know. The current attacks tell us so. Instead of 80 bit is security (birthday bounds) SHA-1 is listed as 51 bits on http://en.wikipedia.org/wiki/Message_digest. The number can continue to go lower. But I also think that it makes sense to standardise on larger than 160 bits of the fingerprint as a UI feature (somewhere between 160 and 384 bits). > >> strength for regulatory compliance. Consider not hashing the key >> creation date. Fixing all the variables in this paragraph, we have the > What would be the advantage of this except for yet another code path. > >> signed message, but I don't think they materially care about the >> flavour of the fingerprint (as long as it's a "strong" one). > They will care if a key suddenly comes with two different fingerprints. > We never had this situation in OpenPGP. Recall how long it took to get > rid of v3 keys. Thus if we want a new fingerprint algorithm we need to > change more than just this. While every key inherently will have two fingerprints -- old and new (and I was saying don't make it worse with hash variations) -- the software should probably select to display only one of them with an option to change it. We might let users enter the fingerprint as before but then use it for dual purpose as SHA-1 or new one (as opposed to using an explicit type). At some point in the future one might start flagging links achieved with the old fingerprint. Features flags will be helpful for this (i.e. I generate a key that I want to be known only by its new fingerprint; I put this fact into Features; don't match this key by the old fingerprint) > > BTW, what about re-establishing the OpenPGP WG? I suppose it's a matter of how much work there is in the OpenPGP. From openpgp@brainhub.org Thu Jan 3 16:02:05 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2782221F8D34 for ; Thu, 3 Jan 2013 16:02:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QubAkW2bhX7r for ; Thu, 3 Jan 2013 16:02:04 -0800 (PST) Received: from qmta02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:24]) by ietfa.amsl.com (Postfix) with ESMTP id ABF4021F8CFB for ; Thu, 3 Jan 2013 16:02:04 -0800 (PST) Received: from omta10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by qmta02.emeryville.ca.mail.comcast.net with comcast id jahB1k0020cQ2SLA2c20al; Fri, 04 Jan 2013 00:02:00 +0000 Received: from [192.168.1.8] ([69.181.162.123]) by omta10.emeryville.ca.mail.comcast.net with comcast id jc1z1k0092g33ZR8Wc20Zl; Fri, 04 Jan 2013 00:02:00 +0000 Message-ID: <50E61BF7.4020905@brainhub.org> Date: Thu, 03 Jan 2013 16:01:59 -0800 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120605 Thunderbird/13.0 MIME-Version: 1.0 To: Daniel Kahn Gillmor X-Priority: 5 (Lowest) References: <50E530D6.6020609@brainhub.org> <50E5494E.6090905@iang.org> <50E60748.3040103@brainhub.org> <50E60F7A.8000001@fifthhorseman.net> In-Reply-To: <50E60F7A.8000001@fifthhorseman.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1357257720; bh=XPIDKPz8wOUztMNcj3gEUydxtvPQD2QkP/me8lA/QPY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=VSmAHRyaJUL0dn1bO9WEPeLz5AddjDQ9p7UotuPbmThuPMAzopah0pY4YCtwyRcK8 Wq5ayqykvTjvGSfcMjQtjmPVTuWbFW0ErcuOmrN88JVdWnF7HdlNIMAeGk9jcABuSt fsGdSx0+zMjZrrUsAkSNGz43dKyJfH8q0yFrgDwyVS7c14gElporGuNqFVXxUPwsIA uN0zqwUBf+jwJ/ZkjGh1qODG9GLwUK1P/PG1fy+n23b0Bf+Ar74wmyy7sFziC4JLXr 31ajE+MUku1mJ8Pa7EpPU5mfjh423H25fQXmNgffnUU5ZS3jM+JTRA8ARyaQIRwCUu qeicTaDLPw4WQ== Cc: openpgp@ietf.org Subject: Re: [openpgp] Fingerprints and their collisions resistance X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 00:02:05 -0000 On 01/03/2013 03:08 PM, Daniel Kahn Gillmor wrote: ... > As i mentioned on the discussion on the GnuPG discussion list, i remain > unconvinced that OpenPGP fingerprints need to be collision-resistant. > They certainly need to be able to resist preimage attacks, but i haven't > seen any convincing attacks that make me think collision resistance is > an issue. ... > If anyone disagrees with this analysis, i would be interested in hearing > how failed collision-resistance of the fingerprint mechanism could lead > to practical attacks in OpenPGP. > >> I have this Keccak in OpenPGP darft written, waiting to for the NIST to ... Key fingerprints can be designed to be cryptographically strong, so that it is infeasible to forge them / find collisions for anybody. The overall system is stronger if we can rely on this stronger assertion. OpenPGP is a format on the wire. I need to show only one vulnerable hypothetical OpenPGP system to prove that Daniel is wrong. Let's say I have a server that manages a domain of user, each have their own key, one at a time. Users can update their keys. They cannot remove keys (other than updating them). The server logs protocol actions and it uses key fingerprints to log changed to keys. The server decide to log the whole key on the key material change event, which it identifies by the change in the key fingerprint. Seems like a reasonable and secure system at first sight. I am a malicious member of that domain. I create two keys with the same fingerprint. Now I can repudiate my document signatures. Document signatures will refer to either of my keys with the same 8 byte KeyID. Server logs will have the same 160 bit fingerprints. I can replace my first key on the server with another and no logs will tell that I have updated the key. This will invalidate documents signed with my first key. There is an easy remedy to this problem, but it will essentially mean that we don't trust the key fingerprint and diligently log whole keys. This means that we moved away from relying on collision resistance of the fingerprint. From dkg@fifthhorseman.net Thu Jan 3 20:27:27 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6337921F8D44 for ; Thu, 3 Jan 2013 20:27:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HbQXAhdXPH9K for ; Thu, 3 Jan 2013 20:27:26 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id A142721F8D3F for ; Thu, 3 Jan 2013 20:27:26 -0800 (PST) Received: from [192.168.13.194] (lair.fifthhorseman.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id F2C4CF970; Thu, 3 Jan 2013 23:27:23 -0500 (EST) Message-ID: <50E65A28.1070501@fifthhorseman.net> Date: Thu, 03 Jan 2013 23:27:20 -0500 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Icedove/17.0 MIME-Version: 1.0 To: Andrey Jivsov References: <50E530D6.6020609@brainhub.org> <50E5494E.6090905@iang.org> <50E60748.3040103@brainhub.org> <50E60F7A.8000001@fifthhorseman.net> <50E61BF7.4020905@brainhub.org> In-Reply-To: <50E61BF7.4020905@brainhub.org> X-Enigmail-Version: 1.5 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="----enig2RHSTXMNCJRNNBKMWDHDA" Cc: openpgp@ietf.org Subject: Re: [openpgp] Fingerprints and their collisions resistance X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 04:27:27 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2RHSTXMNCJRNNBKMWDHDA Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 01/03/2013 07:01 PM, Andrey Jivsov wrote: > Let's say I have a server that manages a domain of user, each have thei= r > own key, one at a time. Users can update their keys. They cannot remove= > keys (other than updating them). The server logs protocol actions and i= t > uses key fingerprints to log changed to keys. The server decide to log > the whole key on the key material change event, which it identifies by > the change in the key fingerprint. Seems like a reasonable and secure > system at first sight. This sounds like a system that explicitly ignores the warning in RFC 4880= : >> Note that there is a much >> smaller, but still non-zero, probability that two different keys ha= ve >> the same fingerprint. https://tools.ietf.org/html/rfc4880#page-72 The purpose of a fingerprint is for one human to be able to securely verify the key of another peer. This means that they must be short enough for humans to understand them, and they must resist preimage attacks (no one should be able to come up with a new key that matches an arbitrary fingerprint). If your argument is "existing tools misuse fingerprints (and even keyids) and treat them as unique identifiers when they should not" then i'd have to agree with you. We need to fix those tools. If the argument is "fingerprints need to be resistant to collision attacks, not just preimage attacks because we want to be able to use them as unique identifiers in cases like this that would allow for repudiation of previously-signed messages where the earlier key was not properly stored", then you're effectively doubling the length of the required fingerprint for the sake of some problem better solved another way. i think that would defeat (or at least severely damage) the ability for human beings to actually cognitively process the fingerprint. It's arguably too difficult already for humans to accurately compare or transcribe 160 bits of high-entropy data. Asking them to compare or transcribe larger fingerprints seems likely to result in operator error. --dkg ------enig2RHSTXMNCJRNNBKMWDHDA 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.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJQ5looXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwRUU1QkU5NzkyODJEODBCOUY3NTQwRjFD Q0QyRUQ5NEQyMTczOUU5AAoJEMzS7ZTSFznpIxsQAIfboXc8WutNjo+KjhkO8z76 L4l9CMNYZSVeRS8cGuWENtmTK5xorhxujd89krOtCQw5BSPr6c7zF5iWz6ElZQSM ssmErrWEL499+yHpwtjB28RaqQzgsv48GQKyacqGACUX0H91ErtzT6C+lY7L3D5i Uwg4bINmHes9k/STIND0oxPu3SokXGpaC4aRsT9ZjTqJEdv+T4kUOxKMaHaT0jke 57R8KBaMtYuai47GtVDsSB0ZPc3/UlBXtYhnhl+CatsHIldqA8QsGNdPHkFPRLgd bmjsvA8RXGomIMkCBSyRn5wuIDBKG92ehCLIjckJi8UF2cUx0M1aAA7poYv9bIVI Lwt95YC8JbG5JPmiLBlMgeQyT45fw6XDM7IdARPalgl3AULO87W8bSr9V1AwcEdB cSCNKcz34CgClxZXAKGmoQTG6y6KxnHL5OMTGYSf8j8Z6Oyj3rI6HI8ZcVnr7ZZK OYakYMCpLWe7d8gMrE59QTyfjwuin0YXqhqRA0qRX4rzJhg4KMs6SjNs8GrmqoRs BwwF4OOvUPT7gPwJC7FRpX+UGcVQY9FrRY7LCmErgHGt5k4RgxVkQl+eqbZQL0bT /KXfIfiyPTFYqosQqC8tWvUBhTC37/uTA5om/kUVEmtDC10fGgYfIdQwAc384TfF 1ZV0uc2YWxFpElo0oeXu =nLyC -----END PGP SIGNATURE----- ------enig2RHSTXMNCJRNNBKMWDHDA-- From openpgp@brainhub.org Thu Jan 3 21:35:51 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00FB621F8E42 for ; Thu, 3 Jan 2013 21:35:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9GdCV8o9-M9v for ; Thu, 3 Jan 2013 21:35:50 -0800 (PST) Received: from qmta13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:243]) by ietfa.amsl.com (Postfix) with ESMTP id 4BDBE21F8DF2 for ; Thu, 3 Jan 2013 21:35:50 -0800 (PST) Received: from omta15.emeryville.ca.mail.comcast.net ([76.96.30.71]) by qmta13.emeryville.ca.mail.comcast.net with comcast id jhQk1k0061Y3wxoADhbqtB; Fri, 04 Jan 2013 05:35:50 +0000 Received: from [192.168.1.8] ([69.181.162.123]) by omta15.emeryville.ca.mail.comcast.net with comcast id jhbo1k0072g33ZR8bhbpt8; Fri, 04 Jan 2013 05:35:49 +0000 Message-ID: <50E66A34.8080702@brainhub.org> Date: Thu, 03 Jan 2013 21:35:48 -0800 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120605 Thunderbird/13.0 MIME-Version: 1.0 To: Daniel Kahn Gillmor References: <50E530D6.6020609@brainhub.org> <50E5494E.6090905@iang.org> <50E60748.3040103@brainhub.org> <50E60F7A.8000001@fifthhorseman.net> <50E61BF7.4020905@brainhub.org> <50E65A28.1070501@fifthhorseman.net> In-Reply-To: <50E65A28.1070501@fifthhorseman.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1357277750; bh=SBWXdM9m7T3nwl+f+81RbzJABaCGHjJFX5OsYeMabsk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=GU9fCMq+gMODbHKkSiP6almaIVqTu8UAMsyU+jym6YPpJuMLu2ukMpb2OJMUD4Fa7 N3d5/xKziJprh2jdcDH/eJmMBfiyb999lGzzkrG4aan8vfd6fNXNbnKq/2+gl7DBbN nzk56obGWcuS2ubcJEB1rVwJOx79FgDPAYNu94c+wIC11E7Nl1xUPBsifa/+q2QmUw PSyUrEXClPgUwJvfpn5jnqIzBWG8EAv8UOmGHhCMPJ42gNLIf9a+SVC3Rsi5DBFbuW agK3mixp8pA1PMN/Msg1qS9I7XkHXyh9ZhlOQ3j9mBE/sJ3V6P2lt4v4J2D0A76uxF /w8gsMKCTFq3g== Cc: openpgp@ietf.org Subject: Re: [openpgp] Fingerprints and their collisions resistance X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 05:35:51 -0000 On 01/03/2013 08:27 PM, Daniel Kahn Gillmor wrote: > On 01/03/2013 07:01 PM, Andrey Jivsov wrote: > >> Let's say I have a server that manages a domain of user, each have their >> own key, one at a time. Users can update their keys. They cannot remove >> keys (other than updating them). The server logs protocol actions and it >> uses key fingerprints to log changed to keys. The server decide to log >> the whole key on the key material change event, which it identifies by >> the change in the key fingerprint. Seems like a reasonable and secure >> system at first sight. > > This sounds like a system that explicitly ignores the warning in RFC 4880: > >>> Note that there is a much >>> smaller, but still non-zero, probability that two different keys have >>> the same fingerprint. > > https://tools.ietf.org/html/rfc4880#page-72 Sure, shorter fingerprints are good for humans... On the other hand, my reading of the above quote is that this is a general warning about the 1/2^80 probability of a collision. SHA-1 collision at 1/2^51 probability is a different story. I wouldn't assume that real-world OpenPGP systems today are written to handle collisions in 20 byte OpenPGP fingerprints. That would "never" happen in practice. Furthermore, I think there are probably no systems that deal with KeyID collisions either. KeyID collisions have a chance to happen at a rate of 1/2^32 -- readily observable. I am guessing that the problem is currently avoided by application design, which eliminates scenarios of large number of messages signed/encrypted by different users, all in one pile. Usually a metadata like UserIDs, SMTP headers, etc, is used first to filter messages/locate keys. It seems to me that instead of fixing the software to handle fingerprint collisions, I would consider diverting this effort to introduce the new fingerprint instead. > > The purpose of a fingerprint is for one human to be able to securely > verify the key of another peer. This means that they must be short > enough for humans to understand them, and they must resist preimage > attacks (no one should be able to come up with a new key that matches an > arbitrary fingerprint). RFC4880 also specifies how fingerprints are stored to identify revokers, and they are a truncated to produce keyIDs. The point is that it's nice to have a single general-purpose method without flaws. > > If your argument is "existing tools misuse fingerprints (and even > keyids) and treat them as unique identifiers when they should not" then > i'd have to agree with you. We need to fix those tools. If the > argument is "fingerprints need to be resistant to collision attacks, not > just preimage attacks because we want to be able to use them as unique > identifiers in cases like this that would allow for repudiation of > previously-signed messages where the earlier key was not properly > stored", then you're effectively doubling the length of the required > fingerprint for the sake of some problem better solved another way. i > think that would defeat (or at least severely damage) the ability for > human beings to actually cognitively process the fingerprint. I am saying that let's pack as much security bits into fingerprints as the current state of the art allows. 256 bit fingerprint should mean at least 128 bit security under any scenario, regardless of higher-level protocols. This adds clarity to security properties of the system and gets rid of (almost) non-compliant use of SHA-1. > It's arguably too difficult already for humans to accurately compare or > transcribe 160 bits of high-entropy data. Asking them to compare or > transcribe larger fingerprints seems likely to result in operator error. I will guess that humans are unlikely to compares full fingerprints anyway. They start from (hopefully :-)) the same end of hex digits and stop somewhere along the way. If fingerprints to become 256 bit long, this may turn out to be unnoticeable. > > --dkg > From iang@iang.org Thu Jan 3 21:57:01 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A413C21F85FC for ; Thu, 3 Jan 2013 21:57:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o5obAfRxc3qp for ; Thu, 3 Jan 2013 21:57:00 -0800 (PST) Received: from pyyl.pair.com (pyyl.pair.com [209.68.1.203]) by ietfa.amsl.com (Postfix) with ESMTP id 86D7F21F84DC for ; Thu, 3 Jan 2013 21:57:00 -0800 (PST) Received: from [IPv6:::1] (www2.futureware.at [78.41.115.142]) by pyyl.pair.com (Postfix) with ESMTPSA id E9034B24E7; Fri, 4 Jan 2013 00:56:52 -0500 (EST) Message-ID: <50E66F22.3070208@iang.org> Date: Fri, 04 Jan 2013 08:56:50 +0300 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <50E530D6.6020609@brainhub.org> <50E5D6AA.6060200@brainhub.org> <874nixev2u.fsf@vigenere.g10code.de> <50E61486.9010209@brainhub.org> In-Reply-To: <50E61486.9010209@brainhub.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [openpgp] Fingerprints and their collisions resistance X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 05:57:01 -0000 Some comments... On 4/01/13 02:30 AM, Andrey Jivsov wrote: > On 01/03/2013 02:54 PM, Werner Koch wrote: >> On Thu, 3 Jan 2013 20:06, openpgp@brainhub.org said: >> >> ... >>> Let's say we choose SHA-3-384, which is no more difficult to implement >>> than SHA-2. We then simply use the current fingerprint algorithm but >> Except that SHA-2 is already in use and has hardware support. > ... but there is no reason why SHA-3 will not optimized in the future. > BTW, which SHA-2 friendly CPU feature we are talking about? ( other than > Intel's plans to add cycle shift ) > > In any case, please note that we are talking about hashing the key > material and thus the performance of the hash algorithm doesn't matter. > > My preference for SHA-3 is to satisfy the concerns of algorithm agility. > I argue for a hardcoded algorithm, and thus the natural choice is the > strongest of SHA that will be future-proof for regulatory compliance. > > I would also be OK to do SHA-2 + SHA-3, TLS style, to be future proof, > but this seems too paranoid. It also seems non-sensical, the notion that anyone is likely to trash SHA-2 or SHA-3 over the next decade has been well and truly trounced. I don't think we really have to worry about the hardness of this particular application overly muchly. Meanwhile, spending time on that means they weren't spending time on other more important things. Maybe a warning to us! >>> instead of SHA-1 use SHA-3-384. Then allow truncation of the output >>> (it's already implied by the 8 byte keyIDs). 20 byte fingerprint on a >>> business card may be reasonable, but we also would like to have full >> So why should we truncate the fingerprint? Is there a reason to believe >> that truncation to 160 bit of SHA-2 or SHA-3 is seriously more secure >> than SHA-1? I don't know. > > The current attacks tell us so. Instead of 80 bit is security (birthday > bounds) SHA-1 is listed as 51 bits on > http://en.wikipedia.org/wiki/Message_digest. The number can continue to > go lower. > > But I also think that it makes sense to standardise on larger than 160 > bits of the fingerprint as a UI feature (somewhere between 160 and 384 > bits). If the purpose of the fingerprint is *only* for human comparisons, then it would seem that this is a marginal improvement. But if it falls out of other decisions, oh well, maybe. >>> strength for regulatory compliance. Consider not hashing the key >>> creation date. Fixing all the variables in this paragraph, we have the >> What would be the advantage of this except for yet another code path. >> >>> signed message, but I don't think they materially care about the >>> flavour of the fingerprint (as long as it's a "strong" one). >> They will care if a key suddenly comes with two different fingerprints. >> We never had this situation in OpenPGP. Recall how long it took to get >> rid of v3 keys. Thus if we want a new fingerprint algorithm we need to >> change more than just this. > > While every key inherently will have two fingerprints -- old and new > (and I was saying don't make it worse with hash variations) -- the > software should probably select to display only one of them with an > option to change it. It doesn't need to be so. If the switch to some other algorithm is organised in alignment with a new key type, then it can roll over with the new key type. (Whether this is overall better or worse depends...) > We might let users enter the fingerprint as before but then use it for > dual purpose as SHA-1 or new one (as opposed to using an explicit type). > At some point in the future one might start flagging links achieved with > the old fingerprint. Features flags will be helpful for this (i.e. I > generate a key that I want to be known only by its new fingerprint; I > put this fact into Features; don't match this key by the old fingerprint) those Features seem like User and Code Confusion :) iang From iang@iang.org Thu Jan 3 22:25:53 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 321EA21F8D8C for ; Thu, 3 Jan 2013 22:25:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LHDZKKmif+4M for ; Thu, 3 Jan 2013 22:25:52 -0800 (PST) Received: from pyyl.pair.com (pyyl.pair.com [209.68.1.203]) by ietfa.amsl.com (Postfix) with ESMTP id A1D4421F8DD0 for ; Thu, 3 Jan 2013 22:25:52 -0800 (PST) Received: from [IPv6:::1] (www2.futureware.at [78.41.115.142]) by pyyl.pair.com (Postfix) with ESMTPSA id CA450B2417; Fri, 4 Jan 2013 01:25:50 -0500 (EST) Message-ID: <50E675EC.60400@iang.org> Date: Fri, 04 Jan 2013 09:25:48 +0300 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <50E530D6.6020609@brainhub.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [openpgp] Fingerprints and their collisions resistance X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 06:25:53 -0000 On 3/01/13 19:17 PM, Jon Callas wrote: > The proposal that we had a long time ago which was essentially prefix a hash with an algorithm number was a good one. I remember everyone thinking it was a good idea and no one belling the cat. I vaguely remember someone writing up an I-D on it, too. > > That's the way I'd go, as it's future-proofed. If we have to have hash agility, I agree that's a good way to do it. Alternatively we can do OIDs in which case we will generate arguments, external dependencies and work for ourselves for generations -- over on another list some were arguing recently about whether Taiwan was allowed to use this OID or that OID for their root key, Taiwan being one of those not-a-countries, and everyone arguing being not-those-authorities. Hence my earlier question - has anyone allocated the OpenPGP numbers for Keccak as yet? The reason I asked is because I stumbled on the code last week and thought what a fine idea it would be to at least prepare the way.... Strawman? SHA3-224 4 12 SHA3-256 5 13 SHA3-384 6 14 SHA3-512 7 15 Strawman? I'm not sure why there is a gap 4-7 in rfc4880. Are there any spots already allocated? Another question, back on the fingerprints. If we end up doing a hash-agile fingerprint, how does the algorithm number get laid out by the users on their business cards? E.g., can we agree on a one byte number, values 0 to 7F, with leading bit reserved for future escape valve? Then, if it is to be written out, this would mean a "new-style fingerprint" is always an odd number of bytes. Could we agree on a stylistic convention? Something like: 7F-- AB01 CD23 EF45 ... Just thinking aloud. Are there any other practical ramifications of going to an agile fingerprint? iang From iang@iang.org Thu Jan 3 22:40:36 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FBCD21F8DFD for ; Thu, 3 Jan 2013 22:40:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l9Rb9wN7khTJ for ; Thu, 3 Jan 2013 22:40:35 -0800 (PST) Received: from pyyl.pair.com (pyyl.pair.com [209.68.1.203]) by ietfa.amsl.com (Postfix) with ESMTP id B8DCB21F8586 for ; Thu, 3 Jan 2013 22:40:35 -0800 (PST) Received: from [IPv6:::1] (www2.futureware.at [78.41.115.142]) by pyyl.pair.com (Postfix) with ESMTPSA id 97511B2417; Fri, 4 Jan 2013 01:40:29 -0500 (EST) Message-ID: <50E6795B.6000200@iang.org> Date: Fri, 04 Jan 2013 09:40:27 +0300 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <50E530D6.6020609@brainhub.org> <50E5494E.6090905@iang.org> <50E60748.3040103@brainhub.org> In-Reply-To: <50E60748.3040103@brainhub.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [openpgp] Fingerprints and their collisions resistance X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 06:40:36 -0000 On 4/01/13 01:33 AM, Andrey Jivsov wrote: > I have this Keccak in OpenPGP darft written, waiting to for the NIST to > publish SHA-3 and the OIDs assigned. Post? I'm extra happy if the OIDs are missing ;) iang From christian@quelltextlich.at Fri Jan 4 02:53:32 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7A2D21F8EF4 for ; Fri, 4 Jan 2013 02:53:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.43 X-Spam-Level: X-Spam-Status: No, score=-1.43 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lHwJD4BabITG for ; Fri, 4 Jan 2013 02:53:32 -0800 (PST) Received: from mail.lirum.at (mail.lirum.at [85.10.202.101]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8FC21F8AB0 for ; Fri, 4 Jan 2013 02:53:31 -0800 (PST) Received: from step ([192.168.129.2] helo=localhost) by mail.lirum.at with esmtp (Exim 4.77) (envelope-from ) id 1Tr4uf-0002sV-KF; Fri, 04 Jan 2013 11:54:09 +0100 Date: Fri, 4 Jan 2013 11:53:29 +0100 From: Christian Aistleitner To: Andrey Jivsov Message-ID: <20130104105328.GA5156@quelltextlich.at> References: <50E530D6.6020609@brainhub.org> <50E5D6AA.6060200@brainhub.org> <874nixev2u.fsf@vigenere.g10code.de> <50E61486.9010209@brainhub.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="3V7upXqbjpZ4EhLz" Content-Disposition: inline In-Reply-To: <50E61486.9010209@brainhub.org> Cc: openpgp@ietf.org Subject: Re: [openpgp] Fingerprints and their collisions resistance X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 10:53:33 -0000 --3V7upXqbjpZ4EhLz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Andrey, On Thu, Jan 03, 2013 at 03:30:14PM -0800, Andrey Jivsov wrote: > Instead of 80 bit is security (birthday=20 > bounds) SHA-1 is listed as 51 bits on=20 > http://en.wikipedia.org/wiki/Message_digest. Since you mention the 51 bits part again and again ... Do you have any data / research underpinning this 51 (Besides Wikipedia)? After all, the cited Wikipedia page links to the retracted variant of an article :-( Otherwise, the best /theoretical/ result that I know of is just above 60. Best regards, Christian --=20 ---- quelltextlich e.U. ---- \\ ---- Christian Aistleitner ---- Companies' registry: 360296y in Linz Christian Aistleitner Gruendbergstrasze 65a Email: christian@quelltextlich.at 4040 Linz, Austria Phone: +43 732 / 26 95 63 Fax: +43 732 / 26 95 63 Homepage: http://quelltextlich.at/ --------------------------------------------------------------- --3V7upXqbjpZ4EhLz Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQEcBAEBCgAGBQJQ5rSoAAoJEGtvSl7veMzeYcQIAMJ/rgbFXnWHWTvmjPoOUFt6 z9Tem15CWFz1F3zb4Q1RThxE9UhmEIeh8zudmGXPdwfyHQZ90kiiPcsHtdAnIpVX mK5yKWJfjIeJf5E4a230Z+OyqWZdzKq3qcujtmwRXbvwGIdzPfWg0jlS0+9j7LOv 2iNFFnShR7+vdE4JLG4kiJMA/IrSSXuICX0tP/61QUswIKj8UInPYglpo+TlnTj4 nR8q5l+bK6UsC1GNmrvOu/ZpC/boiruZBNfR82kQZSNFyGGaAmqsE8gp9D04yOEN TWl3/Jc1FaSyfMxBH2PZ0HnB5GVfeUiR3KWoCU8VmeBzCMR8WcAWvickBJN5AdU= =Chih -----END PGP SIGNATURE----- --3V7upXqbjpZ4EhLz-- From openpgp@brainhub.org Fri Jan 4 11:56:43 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA7921F8419 for ; Fri, 4 Jan 2013 11:56:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lOrB01subF7l for ; Fri, 4 Jan 2013 11:56:38 -0800 (PST) Received: from qmta10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:17]) by ietfa.amsl.com (Postfix) with ESMTP id BD09621F86C0 for ; Fri, 4 Jan 2013 11:56:38 -0800 (PST) Received: from omta24.emeryville.ca.mail.comcast.net ([76.96.30.92]) by qmta10.emeryville.ca.mail.comcast.net with comcast id juih1k0011zF43QAAvweb6; Fri, 04 Jan 2013 19:56:38 +0000 Received: from [192.168.1.8] ([69.181.162.123]) by omta24.emeryville.ca.mail.comcast.net with comcast id jvwc1k00R2g33ZR8kvwdxW; Fri, 04 Jan 2013 19:56:38 +0000 Message-ID: <50E733F4.90400@brainhub.org> Date: Fri, 04 Jan 2013 11:56:36 -0800 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120605 Thunderbird/13.0 MIME-Version: 1.0 To: Christian Aistleitner X-Priority: 5 (Lowest) References: <50E530D6.6020609@brainhub.org> <50E5D6AA.6060200@brainhub.org> <874nixev2u.fsf@vigenere.g10code.de> <50E61486.9010209@brainhub.org> <20130104105328.GA5156@quelltextlich.at> In-Reply-To: <20130104105328.GA5156@quelltextlich.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1357329398; bh=Pdu0r4JkrD60u53cX6h8KARSM6zi+sLp4eviRe+blD0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=mdLMLyJ6IXnFZ4NnEoonVVgZfwuQkaHCHuIpwEMRtZLhECRceQwb7sGYwLyVaRaFb Xa0/g2hkTCttUGhb5v1UczgUkkm8oBg0W/DixigWeM59y/A8PDz2e+xvIqrqcIWnWO A+K0792xJ8Z6L5EqkdMHfUNi1Dk1bt3Cy0Lupmu4shhlsrbPkDj8VnrNyIoSVYTXuO PA73CseZYrd16QHnpOBjQ1u8Ru47AvhzSOSt9nggBewYBMz1Cl2T2+YqX1jt081RMY MEtS6i25zg5wxxNkLjz5kodYcl9CxQOTLs59tlZHq8piBcS7BbEVObNCdky7FuyfHw zBCDKe/tSYI1A== Cc: openpgp@ietf.org Subject: Re: [openpgp] Fingerprints and their collisions resistance X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 19:56:43 -0000 On 01/04/2013 02:53 AM, Christian Aistleitner wrote: > Hi Andrey, > > On Thu, Jan 03, 2013 at 03:30:14PM -0800, Andrey Jivsov wrote: >> Instead of 80 bit is security (birthday >> bounds) SHA-1 is listed as 51 bits on >> http://en.wikipedia.org/wiki/Message_digest. > > Since you mention the 51 bits part again and again ... > > Do you have any data / research underpinning this 51 (Besides > Wikipedia)? > > After all, the cited Wikipedia page links to the retracted variant of > an article :-( > > Otherwise, the best /theoretical/ result that I know of is just > above 60. It looks like this is from the paper "Classification and Generation of Disturbance Vectors for Collision Attacks against SHA-1" published in 2011 in Designs, Codes and Cryptography http://link.springer.com/article/10.1007%2Fs10623-010-9458-9?LI=true with 27 citations in Google scholar. There you can find a dozen of different copies (or minor revisions?) of the paper and Wikipedia links one of them. Should we rather say that the _practical_ value is about 60 (it's not to say that 2^60 is that practical, but that there is an expensive but an actionable attack plan). The following post leads the reader to the algorithm : http://www.schneier.com/blog/archives/2012/10/when_will_we_se.html From openpgp@brainhub.org Fri Jan 4 12:55:11 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF77C21F8A0C for ; Fri, 4 Jan 2013 12:55:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZsIJpEdHmmPM for ; Fri, 4 Jan 2013 12:55:11 -0800 (PST) Received: from qmta15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:228]) by ietfa.amsl.com (Postfix) with ESMTP id 8588621F8A09 for ; Fri, 4 Jan 2013 12:55:11 -0800 (PST) Received: from omta04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by qmta15.emeryville.ca.mail.comcast.net with comcast id jtHR1k0060lTkoCAFwvBMH; Fri, 04 Jan 2013 20:55:11 +0000 Received: from [192.168.1.8] ([69.181.162.123]) by omta04.emeryville.ca.mail.comcast.net with comcast id jwvA1k00E2g33ZR8QwvAYi; Fri, 04 Jan 2013 20:55:11 +0000 Message-ID: <50E741AE.7060601@brainhub.org> Date: Fri, 04 Jan 2013 12:55:10 -0800 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120605 Thunderbird/13.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <50E530D6.6020609@brainhub.org> <50E675EC.60400@iang.org> In-Reply-To: <50E675EC.60400@iang.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1357332911; bh=82slYOrkrPJEdtjcDtzVedTjWUSdgW1MUdOoCi0mDmY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=eedq1nhlB2/c8KSCGmklyQWYGdG4Btnr2JLbpYpW5c8LoVreBnMqLFmeEvZaT39on 1YQTHcqSs2+Awe+5AiSYMEzOHeOXVQmpi7vVkYfgCHydlhy25MCoy+PaFDbeihTuSN P3BOK43uG+j0UtYKiPknGL1PNJ0j7RJuSmPtS9Uzmk/N1pnSl0Z4uRbF6owuHmUs7E LZfgMiUni0ua66AjpCQd1sAhPD5Adwje8NyxP5fppn9kH8PhE2eu6PHpLuPFX5aIwW XtxFvxtPPcTvlMAgtQ6x6jGivaBwvng3shcS8S8Uq8XtNYwQGqacNumIzQJ7fGDKeS jN25cSZv89eDw== Subject: Re: [openpgp] Fingerprints and their collisions resistance X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 20:55:12 -0000 On 01/03/2013 10:25 PM, ianG wrote: ... > Hence my earlier question - has anyone allocated the OpenPGP numbers for > Keccak as yet? The reason I asked is because I stumbled on the code > last week and thought what a fine idea it would be to at least prepare > the way.... Strawman? > > SHA3-224 4 12 > SHA3-256 5 13 > SHA3-384 6 14 > SHA3-512 7 15 > > Strawman? I'm not sure why there is a gap 4-7 in rfc4880. Are there > any spots already allocated? > One point I wanted bring up here based on the draft that I wrote last year is that let's think for a moment about the usefulness of the SHA3-224. I would like to see an argument for it. Algorithms like DSA/ECDSA are capable to deal with hash truncation or padding. RSA mod has sufficient space to always use SHA3-512. The question is especially relevant if you familiarize yourself with the Keccak. Keccak is basically a single hash algorithm which output is truncated to 256, 384, 512, etc bits. The only difference between SHA3-256 and SHA3-512, for example, is one integer used in the internal loop. You can always go with stronger security. Who are those people who would not be OK with SHA3-256 but are happy with SHA3-224 ? Why can't they use shorter public keys (to solve space concerns?) ? From jeanjacquesbrucker@gmail.com Fri Jan 4 13:00:43 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A12921F8A48 for ; Fri, 4 Jan 2013 13:00:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJBPIYKUIl5w for ; Fri, 4 Jan 2013 13:00:38 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8A57B21F8A43 for ; Fri, 4 Jan 2013 13:00:38 -0800 (PST) Received: by mail-bk0-f44.google.com with SMTP id w11so7558333bku.31 for ; Fri, 04 Jan 2013 13:00:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:cc:subject:message-id:in-reply-to :references:x-mailer:mime-version:content-type; bh=qCdyrgBCMGKUCgQHnIZx7l0GFqY7sVZAsx5DmYM9AlM=; b=A6ARz6Tr1cBS/Tv+tSm1fccs+W5ZDRUSxVKl5H6xRxXZZCjlAQn9vy2N6OVquxgQqW xz5UhKEEP9nLXQHO8MvUlshoR8ywg7aPsnyHscGN56UrkhjIPdU2zyWK2LACRpT43e73 mGxarGkJej+S4N8Nu0OFmhVI5ZHjpvc8H3TGKOnCVEp2fbgt5AfzPaaGu0yuqPN9n2Wn yk0GmagblhhpAHpht0Sy72jT1sP4r3eznmDXe1PpC4rWjLlhqCFtKUkp8CkGISeGHSw4 PEE/0EoEVRbaAC7UZBbBUhvgJDzgXwaJaBP+xxwycTgD00Vq0hFGoi8Ql2QwWVp2iUX6 RR7Q== X-Received: by 10.204.129.68 with SMTP id n4mr26013647bks.102.1357333237514; Fri, 04 Jan 2013 13:00:37 -0800 (PST) Received: from localhost.localdomain (5400ECB3.dsl.pool.telekom.hu. [84.0.236.179]) by mx.google.com with ESMTPS id m20sm37766357bkw.4.2013.01.04.13.00.34 (version=SSLv3 cipher=OTHER); Fri, 04 Jan 2013 13:00:35 -0800 (PST) Date: Fri, 4 Jan 2013 22:00:26 +0100 From: jbar To: Andrey Jivsov Message-Id: <20130104220026.2b1ccf24.jeanjacquesbrucker@gmail.com> In-Reply-To: <50E733F4.90400@brainhub.org> References: <50E530D6.6020609@brainhub.org> <50E5D6AA.6060200@brainhub.org> <874nixev2u.fsf@vigenere.g10code.de> <50E61486.9010209@brainhub.org> <20130104105328.GA5156@quelltextlich.at> <50E733F4.90400@brainhub.org> X-Mailer: Sylpheed 3.1.3 (GTK+ 2.24.10; i586-mageia-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA256"; boundary="Signature=_Fri__4_Jan_2013_22_00_26_+0100_Y=zpdq_pLSoif0TL" Cc: Christian Aistleitner , openpgp@ietf.org Subject: Re: [openpgp] Fingerprints and their collisions resistance X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 21:00:43 -0000 --Signature=_Fri__4_Jan_2013_22_00_26_+0100_Y=zpdq_pLSoif0TL Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, 04 Jan 2013 11:56:36 -0800 Andrey Jivsov wrote: > On 01/04/2013 02:53 AM, Christian Aistleitner wrote: > > Hi Andrey, > > > > On Thu, Jan 03, 2013 at 03:30:14PM -0800, Andrey Jivsov wrote: > >> Instead of 80 bit is security (birthday > >> bounds) SHA-1 is listed as 51 bits on > >> http://en.wikipedia.org/wiki/Message_digest. > > > > Since you mention the 51 bits part again and again ... > > > > Do you have any data / research underpinning this 51 (Besides > > Wikipedia)? > > > > After all, the cited Wikipedia page links to the retracted variant of > > an article :-( > > > > Otherwise, the best /theoretical/ result that I know of is just > > above 60. >=20 > It looks like this is from the paper "Classification and Generation of=20 > Disturbance Vectors for Collision Attacks against SHA-1" > published in 2011 in Designs, Codes and Cryptography > http://link.springer.com/article/10.1007%2Fs10623-010-9458-9?LI=3Dtrue > with 27 citations in Google scholar. There you can find a dozen of=20 > different copies (or minor revisions?) of the paper and Wikipedia links=20 > one of them. >=20 > Should we rather say that the _practical_ value is about 60 (it's not to= =20 > say that 2^60 is that practical, but that there is an expensive but an=20 > actionable attack plan). The following post leads the reader to the=20 > algorithm :=20 > http://www.schneier.com/blog/archives/2012/10/when_will_we_se.html In either case, humans are less than 2^33 todays and this number should not= increase so much in the next decades. Even if each living human use OpenPG= P and more than a dozen of keys, we are far from 2^60 or 2^51... (even if we consider also the life expectancy) regards, --=20 jbar --Signature=_Fri__4_Jan_2013_22_00_26_+0100_Y=zpdq_pLSoif0TL Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBCAAGBQJQ50LqAAoJEICx309/5mldwVkH/2zZ7Rq4LHBpwqyFtz8XVdrK QW39elaF8pr/zAruCwBj5ORE8lVCluIFSv0z30q3tzLXWSY+YvU+Z3OTobbvchOd zZ+1S5q2muSlqlAaa7dNBTwZoqN889SEbiGfe0OF5B15Ea7On0m+vujZOL35pLVu VtttyS6wa7+2ICnN29pE3P8MSLfE6rkI27RL+gBQn3rEjDqf3D59g8Tmi2iWCv+0 jFdUiaNvvp6ZZ/5HGq4sv3gGBFWatDU1vpI3rdEhLajkpjECNWS5P9ow7FM/c6DN M24HW8+ltbeH/Tb5s4zCTi9ccFRBser4R67KCi6FYcYSFY0ML2f/QkbLdm51OaA= =WVrv -----END PGP SIGNATURE----- --Signature=_Fri__4_Jan_2013_22_00_26_+0100_Y=zpdq_pLSoif0TL-- From christian@quelltextlich.at Fri Jan 4 14:21:28 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4BCB21F8AB7 for ; Fri, 4 Jan 2013 14:21:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.43 X-Spam-Level: X-Spam-Status: No, score=-1.43 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pIJ1r7dyqQVN for ; Fri, 4 Jan 2013 14:21:28 -0800 (PST) Received: from mail.lirum.at (mail.lirum.at [85.10.202.101]) by ietfa.amsl.com (Postfix) with ESMTP id 14C2321F8A8F for ; Fri, 4 Jan 2013 14:21:28 -0800 (PST) Received: from step ([192.168.129.2] helo=localhost) by mail.lirum.at with esmtp (Exim 4.77) (envelope-from ) id 1TrFeQ-0003UI-CF; Fri, 04 Jan 2013 23:22:06 +0100 Date: Fri, 4 Jan 2013 23:21:25 +0100 From: Christian Aistleitner To: Andrey Jivsov Message-ID: <20130104222125.GA26665@quelltextlich.at> References: <50E530D6.6020609@brainhub.org> <50E5D6AA.6060200@brainhub.org> <874nixev2u.fsf@vigenere.g10code.de> <50E61486.9010209@brainhub.org> <20130104105328.GA5156@quelltextlich.at> <50E733F4.90400@brainhub.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="OXfL5xGRrasGEqWY" Content-Disposition: inline In-Reply-To: <50E733F4.90400@brainhub.org> Cc: openpgp@ietf.org Subject: Re: [openpgp] Fingerprints and their collisions resistance X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 22:21:28 -0000 --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Andrey, On Fri, Jan 04, 2013 at 11:56:36AM -0800, Andrey Jivsov wrote: > On 01/04/2013 02:53 AM, Christian Aistleitner wrote: > > Do you have any data / research underpinning this 51 (Besides > > Wikipedia)? > > > > After all, the cited Wikipedia page links to the retracted variant of > > an article :-( > > > > Otherwise, the best /theoretical/ result that I know of is just > > above 60. >=20 > It looks like this is from the paper "Classification and Generation of=20 > Disturbance Vectors for Collision Attacks against SHA-1" > published in 2011 in Designs, Codes and Cryptography > [...] I guess you are aware of the fact that in recent variants of the article, the 51 is gone and that there is a reason why I wrote =E2=80=9Cretracted variant=E2=80=9D in my original mail :-) > Should we rather say that the _practical_ value is about 60 [...] > http://www.schneier.com/blog/archives/2012/10/when_will_we_se.html Practical has more than just one meaning, just as theoretical :-) As the post you reference only says If Stevens' attack of $2^{60}$ SHA-1 operations serves as the baseline [...] and does not say that =E2=80=9CStevens' attack=E2=80=9D is practical (or = =E2=80=9Cpractical=E2=80=9D in what sense), I am convinced you have read in Stevens' research to underpin your claim. For example you might have come across Stevens' 2012 PhD thesis and have read passages as [...] and this chosen-prefix collision attack against SHA-1 remains a theoretical attack. in section 7.7.3 (but that's somewhat out of context), or more general statements as [...] even though no practical collision attacks against SHA-1 or actual colliding messages are known yet. =66rom section 8.4. But be things as they may, if you know better than Stevens himself and can make his results even more practical, please step up and share your work. All the best, Christian --=20 ---- quelltextlich e.U. ---- \\ ---- Christian Aistleitner ---- Companies' registry: 360296y in Linz Christian Aistleitner Gruendbergstrasze 65a Email: christian@quelltextlich.at 4040 Linz, Austria Phone: +43 732 / 26 95 63 Fax: +43 732 / 26 95 63 Homepage: http://quelltextlich.at/ --------------------------------------------------------------- --OXfL5xGRrasGEqWY Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQEcBAEBCgAGBQJQ51XlAAoJEGtvSl7veMze2NQIAKRX73ZmhCNQ4dRx/nPZqmwP +GxPeMz+89iwltHaGtZcFQFzzewfJSiA7ULW4a6VWl2proRrLf8p6BRfoS7yxBOB bLsHRvOYjLJlLg1WqVzYRx0th5ZL5Xhc1zfvqhIxIi0dXDf9lZHe/dDpqJXO1+RO 2P1KWWshbsiMPgH7SBWdi7EtalZJkpbG8uHX7Nego7hGDQITryW39z1vn8q2/JQ0 WbCeV+IIarp5FHTmzJ+H5c578wwFnOLRbtB1lqPCZvDc1drIlh37QVSYWGL4driQ ShZqIPecNjtHhvufcuEBeSqeUGnEf86IsPrGugLvbcWWbKAqxPDG2q2yH9GE7ag= =L0Om -----END PGP SIGNATURE----- --OXfL5xGRrasGEqWY-- From dkg@fifthhorseman.net Fri Jan 4 14:25:24 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54EBC21F8786 for ; Fri, 4 Jan 2013 14:25:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.284 X-Spam-Level: X-Spam-Status: No, score=-2.284 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lE5UJZ1ywiWA for ; Fri, 4 Jan 2013 14:25:23 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id A757021F8749 for ; Fri, 4 Jan 2013 14:25:23 -0800 (PST) Received: from [192.168.23.229] (dsl254-070-154.nyc1.dsl.speakeasy.net [216.254.70.154]) by che.mayfirst.org (Postfix) with ESMTPSA id 2202CF970; Fri, 4 Jan 2013 17:25:20 -0500 (EST) Message-ID: <50E756CC.9020104@fifthhorseman.net> Date: Fri, 04 Jan 2013 17:25:16 -0500 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Icedove/17.0 MIME-Version: 1.0 To: jbar References: <50E530D6.6020609@brainhub.org> <50E5D6AA.6060200@brainhub.org> <874nixev2u.fsf@vigenere.g10code.de> <50E61486.9010209@brainhub.org> <20130104105328.GA5156@quelltextlich.at> <50E733F4.90400@brainhub.org> <20130104220026.2b1ccf24.jeanjacquesbrucker@gmail.com> In-Reply-To: <20130104220026.2b1ccf24.jeanjacquesbrucker@gmail.com> X-Enigmail-Version: 1.5 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="----enig2MLXPBKAOWQCTTUMOWARM" Cc: openpgp@ietf.org Subject: Re: [openpgp] Fingerprints and their collisions resistance X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 22:25:24 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2MLXPBKAOWQCTTUMOWARM Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 01/04/2013 04:00 PM, jbar wrote: > On Fri, 04 Jan 2013 11:56:36 -0800 Andrey Jivsov wrote: >> Should we rather say that the _practical_ value is about 60 (it's not = to=20 >> say that 2^60 is that practical, but that there is an expensive but an= =20 >> actionable attack plan). The following post leads the reader to the=20 >> algorithm :=20 >> http://www.schneier.com/blog/archives/2012/10/when_will_we_se.html >=20 > In either case, humans are less than 2^33 todays and this number should= not increase so much in the next decades. Even if each living human use = OpenPGP and more than a dozen of keys, we are far from 2^60 or 2^51... I think you're trying to analyze this in a scenario where you want to establish equitable sharing of limited resources among cooperating peers.= This is not the scenario the OpenPGP specification needs to concern itself with. Rather, the OpenPGP specification needs to be concerned with providing cryptographically strong guarantees in the face of malicious and well-funded adversaries. That is, it's not enough to say that we have enough to go around. We need to show that the search space is large enough (and the digest strong enough) that someone can't come up with a new key that matches the fingerprint of your key, even if they have millions of dollars and powerful computers at their disposal. Regards, --dkg ------enig2MLXPBKAOWQCTTUMOWARM 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.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJQ51bMXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwRUU1QkU5NzkyODJEODBCOUY3NTQwRjFD Q0QyRUQ5NEQyMTczOUU5AAoJEMzS7ZTSFznpEl8P/1fggll4tuuIFHjTBSkyiRcz TQJrjitYZmDi3GnNTs0vkDqHF+qJBEgjmvdYdAuXOefPHiJpqiGgj6Qvd8wMH2+V KwctQQUlSoxSMUqHoLxjo44CYjBnan1idAqEAantApS/lAUXUzH55THIJiAnwQbN M82NjbRlB/vBEUDZU2ri8D2roLsAJHhdUilZvoDqQdcwUmZrQW+gKRKv1t0yiAFr wjbVTqZDZMwQOB70pSAdJaME1zgyDqMjgz457DlDZ+Q95TKqaXnDbYTBgJJr8/Gf L1shWafNyxcq+0VN2q9LV/jS78F0in7FkMec+1FdqpOhEqpSRX/4/DjA5+1i8qUc w+dRuHAptIMXHF1rIuNGfl+ypPYNPv4ndwEYnKLExeyrgnMo9v8JGQZ2A7X4Df8G sCBYQA2BA9e9Fwpwi95cw/RlrCWk9l7t7++PdudseoHEkW03U37YBXwPTv9xDhy/ 2y+KC9W90Pnk+kTAqlBuatLAK37KIuI6He2/YPo+BnSis1/VjoJskemLQaohGABU rwcZFFu7oXrER2dNofpkPnWo7n+V3pkgzkqawGoolQ/1RHaVqkTHYjEtbdwGcu4R sJsXodUE1/bbv/QYWKvoLSaP7MiLIXj6oVTCHMfXGyA79uEAKqoB7KmQv7vo3WKY +T98NiOfV3Qbzld/rfDo =Tub2 -----END PGP SIGNATURE----- ------enig2MLXPBKAOWQCTTUMOWARM-- From openpgp@brainhub.org Fri Jan 4 16:06:14 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50AAC21F8B54 for ; Fri, 4 Jan 2013 16:06:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TOZWfKFll5gw for ; Fri, 4 Jan 2013 16:06:13 -0800 (PST) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:32]) by ietfa.amsl.com (Postfix) with ESMTP id 7B33D21F8B4C for ; Fri, 4 Jan 2013 16:06:05 -0800 (PST) Received: from omta17.emeryville.ca.mail.comcast.net ([76.96.30.73]) by qmta03.emeryville.ca.mail.comcast.net with comcast id ju361k0041afHeLA30655K; Sat, 05 Jan 2013 00:06:05 +0000 Received: from [192.168.1.8] ([69.181.162.123]) by omta17.emeryville.ca.mail.comcast.net with comcast id k0631k00N2g33ZR8d064DR; Sat, 05 Jan 2013 00:06:04 +0000 Message-ID: <50E76E6B.1040008@brainhub.org> Date: Fri, 04 Jan 2013 16:06:03 -0800 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120605 Thunderbird/13.0 MIME-Version: 1.0 To: Christian Aistleitner References: <50E530D6.6020609@brainhub.org> <50E5D6AA.6060200@brainhub.org> <874nixev2u.fsf@vigenere.g10code.de> <50E61486.9010209@brainhub.org> <20130104105328.GA5156@quelltextlich.at> <50E733F4.90400@brainhub.org> <20130104222125.GA26665@quelltextlich.at> In-Reply-To: <20130104222125.GA26665@quelltextlich.at> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1357344365; bh=+42NZ3gIjwgsFeMD+GcNcteYvXLqZID2h9OQgc8Wfnw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=NC1B44x60C08svzcjMeHDrnLfeBVMRPPx4c0TWMGeMqAsPDzEEsMKF9zkYe2VJ8FT 6WLwVRv6et4ssa1tGXo8btMtimVHUcliHfCDkkDa5aTJcITZHu5D+ELCklttkEVkhn 2KgaNJcS5OVJVZAgph4kAwuq2L65xcuY574nlLLRLhrH+AbnGtGyxyfcV9IwDoNAiI xZnU33ip5C77iFp4g0OZp9tvLU3sMbbXUjTbRedWKajsX3pGmyH+SwhGX8w+hlRVKQ IMC3xZZlPDSzU0jH9QqESZ18v8WQ1lRUtSla6W1CEfzCmmCN66GjtXbgwm2Uav5NA5 CwTz3boF5pIWA== Cc: openpgp@ietf.org Subject: Re: [openpgp] Fingerprints and their collisions resistance X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2013 00:06:14 -0000 We are talking about the realm of (single) DES security here (i.e. ~ DES-X variant) and one will need all the additional bits. The question of how much can we actually get beyond DES may not be so important in the context of this thread. Recall that my initial post doesn't claim any immediate attack on SHA-1 or a specific weakness of OpenPGP. I am looking for a solution that we can implement in a few years to move to the full 128 bit security (or closer to it). This means that we need to have a method now so that we can begin to slowly integrate it. IMO the upgrade can be done "cheaply", without disruption, so my thought is why not do it anyway? On 01/04/2013 02:21 PM, Christian Aistleitner wrote: > Hi Andrey, > > On Fri, Jan 04, 2013 at 11:56:36AM -0800, Andrey Jivsov wrote: >> On 01/04/2013 02:53 AM, Christian Aistleitner wrote: >>> Do you have any data / research underpinning this 51 (Besides >>> Wikipedia)? >>> >>> After all, the cited Wikipedia page links to the retracted variant of >>> an article :-( >>> >>> Otherwise, the best /theoretical/ result that I know of is just >>> above 60. >> >> It looks like this is from the paper "Classification and Generation of >> Disturbance Vectors for Collision Attacks against SHA-1" >> published in 2011 in Designs, Codes and Cryptography >> [...] > > I guess you are aware of the fact that in recent variants of the > article, the 51 is gone and that there is a reason why I wrote > “retracted variant†in my original mail :-) > >> Should we rather say that the _practical_ value is about 60 [...] >> http://www.schneier.com/blog/archives/2012/10/when_will_we_se.html > > Practical has more than just one meaning, just as theoretical :-) > As the post you reference only says > > If Stevens' attack of $2^{60}$ SHA-1 operations serves as the > baseline [...] > > and does not say that “Stevens' attack†is practical (or “practical†> in what sense), I am convinced you have read in Stevens' research to > underpin your claim. For example you might have come across Stevens' > 2012 PhD thesis and have read passages as > > [...] and this chosen-prefix collision attack against SHA-1 remains a > theoretical attack. > > in section 7.7.3 (but that's somewhat out of context), or more > general statements as > > [...] even though no practical collision attacks against SHA-1 or > actual colliding messages are known yet. > > from section 8.4. > > > But be things as they may, if you know better than Stevens himself and > can make his results even more practical, please step up and share > your work. > > > All the best, > Christian > > > From iang@iang.org Sat Jan 5 11:38:53 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE4DF21F842A for ; Sat, 5 Jan 2013 11:38:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1fno6cc-Kw5n for ; Sat, 5 Jan 2013 11:38:52 -0800 (PST) Received: from pyyl.pair.com (pyyl.pair.com [209.68.1.203]) by ietfa.amsl.com (Postfix) with ESMTP id 58B2E21F8433 for ; Sat, 5 Jan 2013 11:38:50 -0800 (PST) Received: from [IPv6:::1] (www2.futureware.at [78.41.115.142]) by pyyl.pair.com (Postfix) with ESMTPSA id D7C79B242D; Sat, 5 Jan 2013 14:38:43 -0500 (EST) Message-ID: <50E88141.1030907@iang.org> Date: Sat, 05 Jan 2013 22:38:41 +0300 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <50E530D6.6020609@brainhub.org> <50E5494E.6090905@iang.org> <50E60748.3040103@brainhub.org> <50E60F7A.8000001@fifthhorseman.net> <50E61BF7.4020905@brainhub.org> In-Reply-To: <50E61BF7.4020905@brainhub.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [openpgp] Fingerprints and their collisions resistance X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2013 19:38:54 -0000 On 4/01/13 03:01 AM, Andrey Jivsov wrote: > On 01/03/2013 03:08 PM, Daniel Kahn Gillmor wrote: > ... >> As i mentioned on the discussion on the GnuPG discussion list, i remain >> unconvinced that OpenPGP fingerprints need to be collision-resistant. >> They certainly need to be able to resist preimage attacks, but i haven't >> seen any convincing attacks that make me think collision resistance is >> an issue. > ... >> If anyone disagrees with this analysis, i would be interested in hearing >> how failed collision-resistance of the fingerprint mechanism could lead >> to practical attacks in OpenPGP. >> >>> I have this Keccak in OpenPGP darft written, waiting to for the NIST to > ... > > Key fingerprints can be designed to be cryptographically strong, so that > it is infeasible to forge them / find collisions for anybody. The > overall system is stronger if we can rely on this stronger assertion. My understanding is that Key Fingerprints are purposed for humans. RFC4880 says: Note that it is possible for there to be collisions of Key IDs -- two different keys with the same Key ID. Note that there is a much smaller, but still non-zero, probability that two different keys have the same fingerprint. Although see 5.2.3.15 & 5.5.2 for interesting comments. Let's ask for consensus on this point: Are fingerprints cryptographically secure? Or are they convenient human introduction handles? > OpenPGP is a format on the wire. I need to show only one vulnerable > hypothetical OpenPGP system to prove that Daniel is wrong. Fingerprints aren't really for the wire, and if you use them for the wire, you're exercising your right to develop your own security model and threat model. For my money - don't do that. > Let's say I have a server that manages a domain of user, each have their > own key, one at a time. Note, a key can have multiple fingerprints. > Users can update their keys. They cannot remove > keys (other than updating them). The server logs protocol actions and it > uses key fingerprints to log changed to keys. The server decide to log > the whole key on the key material change event, which it identifies by > the change in the key fingerprint. Seems like a reasonable and secure > system at first sight. > > I am a malicious member of that domain. I create two keys with the same > fingerprint. Now I can repudiate my document signatures. Document > signatures will refer to either of my keys with the same 8 byte KeyID. > Server logs will have the same 160 bit fingerprints. I can replace my > first key on the server with another and no logs will tell that I have > updated the key. This will invalidate documents signed with my first key. > > > There is an easy remedy to this problem, but it will essentially mean > that we don't trust the key fingerprint and diligently log whole keys. Right. That's what you should do anyway. If you are to rely on the digsig for any length of time, you should escrow the full public key. > This means that we moved away from relying on collision resistance of > the fingerprint. OpenPGP is primarily a wire format, a communication tool, and has steered clear of how you might store the data, leaving this up to the designer. The fingerprint is clearly a useful index, but is not really purposed to be a cryptographically secure index - that's more left for the designer. E.g., you can have the same key with 2 fingerprints: Also note that if V3 and V4 format keys share the same RSA key material, they will have different Key IDs as well as different fingerprints. In more particularity, a document signing system should store the keys in or near the document [0]. Otherwise you have the problem of lost keys, being a serious risk for any long-lived system. And, if you've got the keys, you don't care what indexing technique you use. iang [0] ok, so I may be biased. This is what I recommend and do: http://iang.org/papers/ricardian_contract.html From jon@callas.org Sat Jan 5 12:00:20 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5662F21F84BC for ; Sat, 5 Jan 2013 12:00:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jEAz-yAz+MRm for ; Sat, 5 Jan 2013 12:00:19 -0800 (PST) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id D380821F84DA for ; Sat, 5 Jan 2013 12:00:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id 349CD1894BFB for ; Sat, 5 Jan 2013 12:00:17 -0800 (PST) X-Virus-Scanned: amavisd-new at merrymeet.com Received: from mail.merrymeet.com ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKCFliU7zscS for ; Sat, 5 Jan 2013 12:00:16 -0800 (PST) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id C5E541894BEF for ; Sat, 5 Jan 2013 12:00:15 -0800 (PST) Received: from [10.0.23.28] ([173.164.244.98]) by keys.merrymeet.com (PGP Universal service); Sat, 05 Jan 2013 12:00:16 -0800 X-PGP-Universal: processed; by keys.merrymeet.com on Sat, 05 Jan 2013 12:00:16 -0800 Mime-Version: 1.0 (Apple Message framework v1283) From: Jon Callas In-Reply-To: <50E66A34.8080702@brainhub.org> Date: Sat, 5 Jan 2013 12:00:16 -0800 Message-Id: <479BF7E1-2EC3-483D-B999-40E7C14E5AA9@callas.org> References: <50E530D6.6020609@brainhub.org> <50E5494E.6090905@iang.org> <50E60748.3040103@brainhub.org> <50E60F7A.8000001@fifthhorseman.net> <50E61BF7.4020905@brainhub.org> <50E65A28.1070501@fifthhorseman.net> <50E66A34.8080702@brainhub.org> To: openpgp@ietf.org X-Mailer: Apple Mail (2.1283) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: [openpgp] Fingerprints and their collisions resistance X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2013 20:00:20 -0000 I think that along with just parameterizing a fingerprint, it's best not = to assume that they are unique. Obviously, there are a few places where = we assume they are, and those are the flies in that particular ointment = (for example, designated revokers). But that's not hard to deal with. = It's not (in general) exposed to humans, so you can make it be a hash as = long as you want. For human use, any reasonable hash function will do, and that even = includes SHA-1. (While it has been estimated that one can construct a = collision with 2^51 work, that's not the same as constructing a = second-preimage collision.) For any crypto operation, a fingerprint = collision isn't going to lead to crypto interoperability -- and this is = why the 64-bit key id isn't a problem. Jon From wk@gnupg.org Sat Jan 5 15:07:21 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD67821F8506 for ; Sat, 5 Jan 2013 15:07:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pYvBIzjox0tL for ; Sat, 5 Jan 2013 15:07:21 -0800 (PST) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by ietfa.amsl.com (Postfix) with ESMTP id 2594721F8510 for ; Sat, 5 Jan 2013 15:07:20 -0800 (PST) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.72 #1 (Debian)) id 1Trcpk-00005m-0o for ; Sun, 06 Jan 2013 00:07:20 +0100 Received: from wk by vigenere.g10code.de with local (Exim 4.77 #3 (Debian)) id 1Trcmz-00049g-Lg; Sun, 06 Jan 2013 00:04:29 +0100 From: Werner Koch To: ianG References: <50E530D6.6020609@brainhub.org> <50E5494E.6090905@iang.org> <50E60748.3040103@brainhub.org> <50E60F7A.8000001@fifthhorseman.net> <50E61BF7.4020905@brainhub.org> <50E88141.1030907@iang.org> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=1E42B367; url=finger:wk@g10code.com Date: Sun, 06 Jan 2013 00:04:29 +0100 In-Reply-To: <50E88141.1030907@iang.org> (iang@iang.org's message of "Sat, 05 Jan 2013 22:38:41 +0300") Message-ID: <87vcbb9qpu.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: openpgp@ietf.org Subject: Re: [openpgp] Fingerprints and their collisions resistance X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2013 23:07:22 -0000 On Sat, 5 Jan 2013 20:38, iang@iang.org said: > Fingerprints aren't really for the wire, and if you use them for the > wire, you're exercising your right to develop your own security model > and threat model. For my money - don't do that. The fingerprint is used for an revocation key (5.2.3.15). However, your policy may simply disallow the use of a revocation key if this is a threat to you. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg@fifthhorseman.net Sat Jan 5 15:22:13 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC3921F8445 for ; Sat, 5 Jan 2013 15:22:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vsrmJzAht+W9 for ; Sat, 5 Jan 2013 15:22:12 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1BE21F8444 for ; Sat, 5 Jan 2013 15:22:12 -0800 (PST) Received: from [192.168.42.104] (h-67-101-156-50.nycmny83.dynamic.covad.net [67.101.156.50]) by che.mayfirst.org (Postfix) with ESMTPSA id 3169FF970; Sat, 5 Jan 2013 18:22:09 -0500 (EST) Message-ID: <50E8B59C.4010807@fifthhorseman.net> Date: Sat, 05 Jan 2013 18:22:04 -0500 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Icedove/17.0 MIME-Version: 1.0 To: Werner Koch References: <50E530D6.6020609@brainhub.org> <50E5494E.6090905@iang.org> <50E60748.3040103@brainhub.org> <50E60F7A.8000001@fifthhorseman.net> <50E61BF7.4020905@brainhub.org> <50E88141.1030907@iang.org> <87vcbb9qpu.fsf@vigenere.g10code.de> In-Reply-To: <87vcbb9qpu.fsf@vigenere.g10code.de> X-Enigmail-Version: 1.5 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="----enig2OBKWOHLBFKMLBHWAKMSN" Cc: openpgp@ietf.org, ianG Subject: Re: [openpgp] Fingerprints and their collisions resistance X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2013 23:22:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2OBKWOHLBFKMLBHWAKMSN Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 01/05/2013 06:04 PM, Werner Koch wrote: > On Sat, 5 Jan 2013 20:38, iang@iang.org said: >=20 >> Fingerprints aren't really for the wire, and if you use them for the >> wire, you're exercising your right to develop your own security model >> and threat model. For my money - don't do that. >=20 > The fingerprint is used for an revocation key (5.2.3.15). However, you= r > policy may simply disallow the use of a revocation key if this is a > threat to you. iirc, there was a rough consensus within this working group that this was probably a mistake in RFC 4880, and any future revision of the draft should place the full key material into the revocation key subpacket instead of the key's fingerprint. --dkg ------enig2OBKWOHLBFKMLBHWAKMSN 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.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJQ6LWcXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwRUU1QkU5NzkyODJEODBCOUY3NTQwRjFD Q0QyRUQ5NEQyMTczOUU5AAoJEMzS7ZTSFznp0qkP/RO2v4tzdXw0QgEsIhpJ8aiX kSCs/boHzlrD1TraZ8mg1wTYRiym1d2yydtelu0yrheSY0CNg7yOQUtj0/PHAf5N TXsgyiT4sbRK2EJ6DFCN589Mg39+I+OLhT6FEnWPjJxiWEtm7fanLgUELKWjBSPH slfZQaYG8gQfqXdyEH1IDgEuhLaFA1psasU8IZDWjQagHHa8nh00lTWWVC7CFWKP JwccRKpfWnOxm56YHsRMUi6oAv+TybI8l4fzdN4JFLl68c2TGdmqt4UcDEBojQeL oa2hXjhPRkNaYiozMpNOwmz1V/ZZBmg2Qruo2yIbd/+ipLoa96V0rthr5NjTZkC3 U0Vf/X6LLU/hHOIVc4nl+Y9BonDNxb0vNdJtLIF//SHVt5LOpwoRWv+1koH73PEj A3ZQ7P/S8sVPi+W6Rx3YxivUQ9CPen+KR06xCbsYQ9Ppo0/l98RyDsdTUtlS1m8V 7lbmwOUUOb0iJDwdW+EDI5JRoJ+gcB5H23unnn6ZoZXedlZQAAs5ZgEBCxaKmkNP 58qbfhJ7tBNKtDyQ/BszHuhgZ5XqefwUjsuc8r95axi3JmRQKSmmJ+bdiQbO/+ez mveHVjMJ5h/X5KF63CgplyjpoJEGK8WfwifvvukkioPOA2IruKv/R3XAJRxBa1iH HD+rQciTc7WDHr1Ig5iB =gKaK -----END PGP SIGNATURE----- ------enig2OBKWOHLBFKMLBHWAKMSN-- From jon@callas.org Sat Jan 5 19:19:48 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE0E21F8444 for ; Sat, 5 Jan 2013 19:19:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5U2tC6Tx7mh for ; Sat, 5 Jan 2013 19:19:48 -0800 (PST) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id 223AA21F8443 for ; Sat, 5 Jan 2013 19:19:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id 6EC9618A222C; Sat, 5 Jan 2013 19:19:47 -0800 (PST) X-Virus-Scanned: amavisd-new at merrymeet.com Received: from mail.merrymeet.com ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnRkG04zM3Mr; Sat, 5 Jan 2013 19:19:46 -0800 (PST) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id 5BE4218A221D; Sat, 5 Jan 2013 19:19:44 -0800 (PST) Received: from [10.0.23.28] ([173.164.244.98]) by keys.merrymeet.com (PGP Universal service); Sat, 05 Jan 2013 19:19:46 -0800 X-PGP-Universal: processed; by keys.merrymeet.com on Sat, 05 Jan 2013 19:19:46 -0800 Mime-Version: 1.0 (Apple Message framework v1283) From: Jon Callas In-Reply-To: <50E8B59C.4010807@fifthhorseman.net> Date: Sat, 5 Jan 2013 19:19:43 -0800 Message-Id: References: <50E530D6.6020609@brainhub.org> <50E5494E.6090905@iang.org> <50E60748.3040103@brainhub.org> <50E60F7A.8000001@fifthhorseman.net> <50E61BF7.4020905@brainhub.org> <50E88141.1030907@iang.org> <87vcbb9qpu.fsf@vigenere.g10code.de> <50E8B59C.4010807@fifthhorseman.net> To: Daniel Kahn Gillmor X-Mailer: Apple Mail (2.1283) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Werner Koch , openpgp@ietf.org, Jon Callas , ianG Subject: Re: [openpgp] Fingerprints and their collisions resistance X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2013 03:19:48 -0000 On Jan 5, 2013, at 3:22 PM, Daniel Kahn Gillmor wrote: > iirc, there was a rough consensus within this working group that this > was probably a mistake in RFC 4880, and any future revision of the = draft > should place the full key material into the revocation key subpacket > instead of the key's fingerprint. I was about to comment that if we move on shifting to ECC keys as per = Andrey's work on them, we could just about eliminate fingerprints and = just use the keys. Also, the point compression patent expired last year. Jon From openpgp@brainhub.org Sat Jan 5 22:19:31 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1D5521F8804 for ; Sat, 5 Jan 2013 22:19:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XzpFjYVx9a2r for ; Sat, 5 Jan 2013 22:19:31 -0800 (PST) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:227]) by ietfa.amsl.com (Postfix) with ESMTP id 6A94A21F87FB for ; Sat, 5 Jan 2013 22:19:31 -0800 (PST) Received: from omta01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by qmta12.emeryville.ca.mail.comcast.net with comcast id kW331k0010EPchoACWKWUm; Sun, 06 Jan 2013 06:19:30 +0000 Received: from [192.168.1.8] ([69.181.162.123]) by omta01.emeryville.ca.mail.comcast.net with comcast id kWKU1k00X2g33ZR8MWKVv9; Sun, 06 Jan 2013 06:19:30 +0000 Message-ID: <50E91770.3050203@brainhub.org> Date: Sat, 05 Jan 2013 22:19:28 -0800 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120605 Thunderbird/13.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <50E530D6.6020609@brainhub.org> <50E5494E.6090905@iang.org> <50E60748.3040103@brainhub.org> <50E60F7A.8000001@fifthhorseman.net> <50E61BF7.4020905@brainhub.org> <50E88141.1030907@iang.org> In-Reply-To: <50E88141.1030907@iang.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1357453170; bh=J5Z9hy5CTkn9HLPdHAMwCjn0vrzOoNzHMftB3wNGk8A=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=k8QZ5D0O+CwjgXurnvA54Qg1V2FjcZiRcjQoY6nIZD5SPg+Uo7tcZnOPahYC+MZ3z yedtnT4u0XF+SANur9ApxdTVO1oxw9A6Jugih5ffBRX/Ml58JFn6/pMRqKGRHXWtPy gVwEDJyaqHFOxsZsL32zszNZphkiv/Ux7g4SZMXRvGVkaPxTv5jdqE2NV0IkgXPJPt lWsY1ZvqOO072pfQuuwlqMNY572E/BdoUop2a70AAwJFxHEyUNNcxAo0KggZ56D0pW 7gcQw0KLMzy4cZbd46aucx99l8cBvqXdgJXYEC0PWQk2S+oUCOomkyMwgD8HnmFOHG rixBBdaaBa7Mg== Subject: Re: [openpgp] Fingerprints and their collisions resistance X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2013 06:19:32 -0000 On 01/05/2013 11:38 AM, ianG wrote: ... > Although see 5.2.3.15 & 5.5.2 for interesting comments. Let's ask for > consensus on this point: > > Are fingerprints cryptographically secure? > > Or are they convenient human introduction handles? I can live with the interpretation of RFC 4880 that implies that fingerprints are not cryptographically secure. IMO, however, it would be beneficial if they were secure at the birthday boundary size. I know that there were suggestions by multiple people to store complete keys. The problems are: * keys are volatile; as a developer I want, at least internally in my software, a method to ID the key material; key material is often reused and traverses X.509 and OpenPGP world * it's a convenience when the ID is of fixed size (think about database tables, software memory allocations, etc) There is an objective need to ID the key material with a hash. I think at the very least we should spec the algorithm in an e-mail on this list. It would even be better if this algorithm was supported across applications, so that the IDs are portable. From openpgp@brainhub.org Sat Jan 5 22:28:51 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF94B21F880B for ; Sat, 5 Jan 2013 22:28:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7C1Fv+U8HEDA for ; Sat, 5 Jan 2013 22:28:51 -0800 (PST) Received: from qmta05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:48]) by ietfa.amsl.com (Postfix) with ESMTP id 096E421F87E5 for ; Sat, 5 Jan 2013 22:28:44 -0800 (PST) Received: from omta19.emeryville.ca.mail.comcast.net ([76.96.30.76]) by qmta05.emeryville.ca.mail.comcast.net with comcast id kWUk1k0011eYJf8A5WUkpW; Sun, 06 Jan 2013 06:28:44 +0000 Received: from [192.168.1.8] ([69.181.162.123]) by omta19.emeryville.ca.mail.comcast.net with comcast id kWUj1k00D2g33ZR01WUjZ5; Sun, 06 Jan 2013 06:28:44 +0000 Message-ID: <50E9199B.1090509@brainhub.org> Date: Sat, 05 Jan 2013 22:28:43 -0800 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120605 Thunderbird/13.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <50E530D6.6020609@brainhub.org> <50E5494E.6090905@iang.org> <50E60748.3040103@brainhub.org> <50E60F7A.8000001@fifthhorseman.net> <50E61BF7.4020905@brainhub.org> <50E88141.1030907@iang.org> <87vcbb9qpu.fsf@vigenere.g10code.de> <50E8B59C.4010807@fifthhorseman.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1357453724; bh=lHA1Dk8fCvbjEuJDOKKR5s9xBf/zhDHIZ1YnzVAp7A4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=s42gdQ4uO2ihhFbrduoyquJoK8DxT7E4fM1I0DF9GiNhm5PF1NT+HPJCx+1KE46bE 9nrptI88sDfSsWh4BQE9b+7m6XhEAbyt3KaqcUzxGaY6ffn/eZfCHg795xQsH6bm1V RsIL6/LLVKSW1m2Ib3i1TFVFvt/Z08iRuzPT108DMAjl8XR1aZX3uPaI3uUGTAid6f o9UPJMIkKI3qVoZ5f0Squ7Hp/roDeoIaATEvuMtSlAf6dSYD5pCXCGIC2qFP8t/Epr SO3/OzhNSUQHSQ70NyOh4mqqqBxwKBAO+MyrzAIp+gbcF1h90V691bf9q2z+x6Om9N UQpoCX3YiWNRw== Subject: Re: [openpgp] Fingerprints and their collisions resistance X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2013 06:28:52 -0000 On 01/05/2013 07:19 PM, Jon Callas wrote: > > On Jan 5, 2013, at 3:22 PM, Daniel Kahn Gillmor wrote: > >> iirc, there was a rough consensus within this working group that this >> was probably a mistake in RFC 4880, and any future revision of the draft >> should place the full key material into the revocation key subpacket >> instead of the key's fingerprint. > > I was about to comment that if we move on shifting to ECC keys as per Andrey's work on them, we could just about eliminate fingerprints and just use the keys. > > Also, the point compression patent expired last year. > > Jon BTW, here is my current contribution to the process of making OpenPGP data structures most compact: http://tools.ietf.org/html/draft-jivsov-ecc-compact-00 . It's a generic format that can be used anywhere: X.509, DNS, etc. Realistically, I hope that designers of new protocols at IETF will consider this (more superior to SEC1 :-)) proposal... Back to OpenPGP, there is certainly a need to have most compact keys and messages, and this is one of the advantages of the ECC keys. It's remarkable that one can have a 32 byte public key of AES-128 strength and my proposal lays the groundwork to make this happen in OpenPGP (v.s. the current 65 bytes). Given that OpenPGP messages are very compact by design, everything fits nicely together. From openpgp@brainhub.org Sat Jan 5 22:50:45 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6B3921F881A for ; Sat, 5 Jan 2013 22:50:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7uTDBXnE3bQ for ; Sat, 5 Jan 2013 22:50:44 -0800 (PST) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:227]) by ietfa.amsl.com (Postfix) with ESMTP id E9C8121F879E for ; Sat, 5 Jan 2013 22:50:44 -0800 (PST) Received: from omta15.emeryville.ca.mail.comcast.net ([76.96.30.71]) by qmta12.emeryville.ca.mail.comcast.net with comcast id kWbL1k0021Y3wxoACWqj10; Sun, 06 Jan 2013 06:50:43 +0000 Received: from [192.168.1.8] ([69.181.162.123]) by omta15.emeryville.ca.mail.comcast.net with comcast id kWqi1k00E2g33ZR8bWqibU; Sun, 06 Jan 2013 06:50:43 +0000 Message-ID: <50E91EC2.7050008@brainhub.org> Date: Sat, 05 Jan 2013 22:50:42 -0800 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120605 Thunderbird/13.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <50E530D6.6020609@brainhub.org> <50E675EC.60400@iang.org> <50E741AE.7060601@brainhub.org> In-Reply-To: <50E741AE.7060601@brainhub.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1357455043; bh=5J+fvTSPdbcy3WbxNT2UH/OWOnCOn72XpbUklB8Fe7Q=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=bhfFWXNByeeFLStqFECN97oqhwQR/GcJjI4sctgQs895xQHEZxKUTBleR55/CdQGw /1LaEcguvFK1KlIa0VGAEm6OJ6WQqAdT7RLGlv+IxflffS+jx5KehqcpB4y6JrZZHC +d9UDHXhJsUTAzuqcrzxd7krIvfGPzBt5TX8LWW8Gg44U9wAGSVDtYeGWasNlE6xHG WPyjrAlhEuIRrJXlbsUktcMyHUvNmgzz+v5AMlu67xDI2+odajIPTTmPFaI7XKEIPc xuqsBtpM3mhRCOvsig//ttP51XAZmHbg2fHOG0dwphc9C/d8AKT8LjHpacJ3RzCaoQ Eb3EXBh4Z2hyQ== Subject: Re: [openpgp] Fingerprints and their collisions resistance X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2013 06:50:45 -0000 On 01/04/2013 12:55 PM, Andrey Jivsov wrote: > On 01/03/2013 10:25 PM, ianG wrote: > ... >> Hence my earlier question - has anyone allocated the OpenPGP numbers for >> Keccak as yet? The reason I asked is because I stumbled on the code >> last week and thought what a fine idea it would be to at least prepare >> the way.... Strawman? >> >> SHA3-224 4 12 >> SHA3-256 5 13 >> SHA3-384 6 14 >> SHA3-512 7 15 >> >> Strawman? I'm not sure why there is a gap 4-7 in rfc4880. Are there >> any spots already allocated? >> > > One point I wanted bring up here based on the draft that I wrote last > year is that let's think for a moment about the usefulness of the SHA3-224. > > I would like to see an argument for it. Algorithms like DSA/ECDSA are > capable to deal with hash truncation or padding. RSA mod has sufficient > space to always use SHA3-512. > > The question is especially relevant if you familiarize yourself with the > Keccak. Keccak is basically a single hash algorithm which output is > truncated to 256, 384, 512, etc bits. The only difference between > SHA3-256 and SHA3-512, for example, is one integer used in the internal > loop. > > You can always go with stronger security. Who are those people who would > not be OK with SHA3-256 but are happy with SHA3-224 ? Why can't they use > shorter public keys (to solve space concerns?) ? I think I found some support to my suggestion in the latest SHA2 spec: FIPS 180-4 "Secure Hash Standard (SHS)": > 7. TRUNCATION OF A MESSAGE DIGEST > Some application may require a hash function with a message digest length different than those > provided by the hash functions in this Standard. In such cases, a truncated message digest may be > used, whereby a hash function with a larger message digest length is applied to the data to be > hashed, and the resulting message digest is truncated by selecting an appropriate number of the > leftmost bits. For guidelines on choosing the length of the truncated message digest and > information about its security implications for the cryptographic application that uses it, see SP > 800-107 [SP 800-107]. In SHA2 SHA-224 is the SHA-256 with different IV. NIST was worrying about some theoretical concerns with examples that show non-uniform distribution of the SHA2 hash output (see http://csrc.nist.gov/groups/ST/hash/documents/Kelsey_Truncation.pdf) Given that there are no IVs in Keccak, the section 7 of FIPS 180-4 allows the truncation, and the truncation should be happening anyway in practice when you use mismatched weaker DSA keys with stronger hashes, benefits of SHA3-224 are even harder to see. From wk@gnupg.org Sun Jan 6 04:27:23 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B79E21F87A9 for ; Sun, 6 Jan 2013 04:27:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O84tIyTLK0E4 for ; Sun, 6 Jan 2013 04:27:23 -0800 (PST) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by ietfa.amsl.com (Postfix) with ESMTP id 03A8A21F8750 for ; Sun, 6 Jan 2013 04:27:22 -0800 (PST) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.72 #1 (Debian)) id 1TrpJx-0005v7-91 for ; Sun, 06 Jan 2013 13:27:21 +0100 Received: from wk by vigenere.g10code.de with local (Exim 4.77 #3 (Debian)) id 1TrpFu-0007Yh-Hr; Sun, 06 Jan 2013 13:23:10 +0100 From: Werner Koch To: Jon Callas References: <50E530D6.6020609@brainhub.org> <50E5494E.6090905@iang.org> <50E60748.3040103@brainhub.org> <50E60F7A.8000001@fifthhorseman.net> <50E61BF7.4020905@brainhub.org> <50E88141.1030907@iang.org> <87vcbb9qpu.fsf@vigenere.g10code.de> <50E8B59C.4010807@fifthhorseman.net> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=1E42B367; url=finger:wk@g10code.com Date: Sun, 06 Jan 2013 13:23:10 +0100 In-Reply-To: (Jon Callas's message of "Sat, 5 Jan 2013 19:19:43 -0800") Message-ID: <87ip7aa4b5.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: openpgp@ietf.org, Daniel Kahn Gillmor , ianG Subject: Re: [openpgp] Fingerprints and their collisions resistance X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2013 12:27:23 -0000 On Sun, 6 Jan 2013 04:19, jon@callas.org said: > Also, the point compression patent expired last year. Oh really. That would be great news. No other patents to the same effect? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk@gnupg.org Sun Jan 6 04:27:23 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9259C21F87AB for ; Sun, 6 Jan 2013 04:27:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sq2U2igFy1o3 for ; Sun, 6 Jan 2013 04:27:23 -0800 (PST) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by ietfa.amsl.com (Postfix) with ESMTP id 0356821F8703 for ; Sun, 6 Jan 2013 04:27:22 -0800 (PST) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.72 #1 (Debian)) id 1TrpJx-0005vP-QV for ; Sun, 06 Jan 2013 13:27:21 +0100 Received: from wk by vigenere.g10code.de with local (Exim 4.77 #3 (Debian)) id 1TrpHk-0007Zi-Hu; Sun, 06 Jan 2013 13:25:04 +0100 From: Werner Koch To: Andrey Jivsov References: <50E530D6.6020609@brainhub.org> <50E5494E.6090905@iang.org> <50E60748.3040103@brainhub.org> <50E60F7A.8000001@fifthhorseman.net> <50E61BF7.4020905@brainhub.org> <50E88141.1030907@iang.org> <87vcbb9qpu.fsf@vigenere.g10code.de> <50E8B59C.4010807@fifthhorseman.net> <50E9199B.1090509@brainhub.org> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=1E42B367; url=finger:wk@g10code.com Date: Sun, 06 Jan 2013 13:25:04 +0100 In-Reply-To: <50E9199B.1090509@brainhub.org> (Andrey Jivsov's message of "Sat, 05 Jan 2013 22:28:43 -0800") Message-ID: <87ehhya47z.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: openpgp@ietf.org Subject: Re: [openpgp] Fingerprints and their collisions resistance X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2013 12:27:23 -0000 On Sun, 6 Jan 2013 07:28, openpgp@brainhub.org said: > Given that OpenPGP messages are very compact by design, everything > fits nicely together. Finally Phils preference for saving every little bit turns out be an advantage :-). Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From frantz@pwpconsult.com Sun Jan 6 09:29:12 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F87F21F84FD for ; Sun, 6 Jan 2013 09:29:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPRC2K9OHLdu for ; Sun, 6 Jan 2013 09:29:12 -0800 (PST) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id C1D8521F84F5 for ; Sun, 6 Jan 2013 09:29:11 -0800 (PST) Received: from [173.75.83.83] (helo=Williams-MacBook-Pro.local) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Tru22-0004p5-B5; Sun, 06 Jan 2013 12:29:10 -0500 Date: Sun, 6 Jan 2013 09:29:10 -0800 From: Bill Frantz To: Andrey Jivsov X-Priority: 3 In-Reply-To: <50E91770.3050203@brainhub.org> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.3.1 (422) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec7942a4a2d03d544dc3d70467dcfd94a494350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 173.75.83.83 Cc: openpgp@ietf.org Subject: Re: [openpgp] Fingerprints and their collisions resistance X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2013 17:29:12 -0000 On 1/5/13 at 10:19 PM, openpgp@brainhub.org (Andrey Jivsov) wrote: >There is an objective need to ID the key material with a hash.=20 >I think at the very least we should spec the algorithm in an=20 >e-mail on this list. It would even be better if this algorithm=20 >was supported across applications, so that the IDs are portable. I hope that anything which affects program interoperability or=20 escapes to the user would be specified in a more permanent way=20 than an email to a list. An informational RFC might be the easy choice. Cheers - Bill --------------------------------------------------------------------------- Bill Frantz |"We used to quip that "password" is the most common 408-356-8506 | password. Now it's 'password1.' Who said=20 users haven't www.pwpconsult.com | learned anything about security?" -- Bruce Schneier From jon@callas.org Sun Jan 6 11:10:27 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD28821F855A for ; Sun, 6 Jan 2013 11:10:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qbUuGeKauR0O for ; Sun, 6 Jan 2013 11:10:26 -0800 (PST) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id D85C521F8558 for ; Sun, 6 Jan 2013 11:10:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id 2EC7818BDAB3; Sun, 6 Jan 2013 11:10:26 -0800 (PST) X-Virus-Scanned: amavisd-new at merrymeet.com Received: from mail.merrymeet.com ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sz8PIdofhlRu; Sun, 6 Jan 2013 11:10:25 -0800 (PST) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id 064FF18BDA99; Sun, 6 Jan 2013 11:10:22 -0800 (PST) Received: from [10.0.23.15] ([173.164.244.98]) by keys.merrymeet.com (PGP Universal service); Sun, 06 Jan 2013 11:10:25 -0800 X-PGP-Universal: processed; by keys.merrymeet.com on Sun, 06 Jan 2013 11:10:25 -0800 References: <50E530D6.6020609@brainhub.org> <50E5494E.6090905@iang.org> <50E60748.3040103@brainhub.org> <50E60F7A.8000001@fifthhorseman.net> <50E61BF7.4020905@brainhub.org> <50E88141.1030907@iang.org> <87vcbb9qpu.fsf@vigenere.g10code.de> <50E8B59C.4010807@fifthhorseman.net> <87ip7aa4b5.fsf@vigenere.g10code.de> In-Reply-To: <87ip7aa4b5.fsf@vigenere.g10code.de> Mime-Version: 1.0 (1.0) Message-Id: <5D0A7443-944D-4992-B8F5-20468BBE3CAD@callas.org> X-Mailer: iPad Mail (10A523) From: Jon Callas Date: Sun, 6 Jan 2013 11:10:23 -0800 To: Werner Koch Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Cc: "openpgp@ietf.org" , Daniel Kahn Gillmor , ianG Subject: Re: [openpgp] Fingerprints and their collisions resistance X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2013 19:10:27 -0000 On Jan 6, 2013, at 4:23, Werner Koch wrote: > On Sun, 6 Jan 2013 04:19, jon@callas.org said: >=20 >> Also, the point compression patent expired last year. >=20 > Oh really. That would be great news. No other patents to the same > effect? The ECC patents are starting to expire en masse. It started last year, and o= ver the next year or two most of the really annoying ones are going. Others,= like MQV will take longer. But the IP reasons to avoid ECC are going quickl= y, especially if you stick to the Suite B curves, as Andrey did with his dra= ft.=20 Jon= From nicholas.cole@gmail.com Sun Jan 6 23:20:24 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75BB221F8481 for ; Sun, 6 Jan 2013 23:20:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dl7qSOh30zK3 for ; Sun, 6 Jan 2013 23:20:24 -0800 (PST) Received: from mail-vb0-f47.google.com (mail-vb0-f47.google.com [209.85.212.47]) by ietfa.amsl.com (Postfix) with ESMTP id CA20521F8479 for ; Sun, 6 Jan 2013 23:20:23 -0800 (PST) Received: by mail-vb0-f47.google.com with SMTP id e21so18617083vbm.6 for ; Sun, 06 Jan 2013 23:20:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ssD5YB4TvuerhPPH08DMC1oHSVcrS8S34iBL/HnakVA=; b=ISMjBm+L1LI2vR8ZcLbX6+aGZwknz8aHInW8Beloa2eWW54sYPbgkoy/qRksfCH3MT JA+IPfHd+Roe/rok8k3iIH2gTKq/vP2N/5jYka2Dsv5ecOpseUOUoexULRsTqVnKfcEr 59Ua4OKy/xwIKOk8WBkKG4Nj60GhfK2cT29GAQ3fdE2u8XwPsN/qzX06Y/owIhvq1jMx ege59jY+sCYbNOd0PKGEZP6EmAPRN/qSJBSN+MfVO+QcO37r+kaxXpmpfiDBsnu+6VNA 4OVMuz28NB4+MdZpmEALQjtxtyqqunPS+IupIi8miTd+uXG2xbeaBjc513VmsmLSuRm5 ESWA== MIME-Version: 1.0 Received: by 10.58.64.51 with SMTP id l19mr85133375ves.15.1357543223156; Sun, 06 Jan 2013 23:20:23 -0800 (PST) Received: by 10.58.37.40 with HTTP; Sun, 6 Jan 2013 23:20:22 -0800 (PST) In-Reply-To: <874nixev2u.fsf@vigenere.g10code.de> References: <50E530D6.6020609@brainhub.org> <50E5D6AA.6060200@brainhub.org> <874nixev2u.fsf@vigenere.g10code.de> Date: Mon, 7 Jan 2013 07:20:22 +0000 Message-ID: From: Nicholas Cole To: Werner Koch Content-Type: multipart/alternative; boundary=047d7b6d8102955e4e04d2ada995 Cc: openpgp@ietf.org Subject: Re: [openpgp] Fingerprints and their collisions resistance X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 07:20:24 -0000 --047d7b6d8102955e4e04d2ada995 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jan 3, 2013 at 10:54 PM, Werner Koch wrote: > On Thu, 3 Jan 2013 20:06, openpgp@brainhub.org said: > > > > export/import control of encryption). Fingerptins are special data > > structures because they are sometimes input by humans. > > Well, humans compare fingerprints but don't enter them. I doubt that I > ever did this in the last 20 years. Yes. And it is also important that there is a way to 'uniquely' (granted the *very* small chance of a collision - I think there has been only one possible collision with SHA-1 fingerprints reported on the gnupg list) identify keys to other programs. I suspect that a lot of programs using gnupg and other implementations expect the fingerprint to be unique. There does have to be a reliable way to refer to a particular key. So fingerprints are compared by humans, but they are also important for computers too - and probably used more by computers than by humans. I don't see the sense in adopting a truncated standard. Any new fingerprint is going to be more tedious than comparing SHA-1, but that's the price to be paid for security. I suppose that humans will start relying more on the key-id. I assume that any new standard would adopt a more collision-resistant key-id. N. --047d7b6d8102955e4e04d2ada995 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Jan 3, 2013 at 10:54 PM, Werner Koch <wk@gnupg= .org> wrote:
On Thu, =A03 Jan 2013 20:0= 6, openpgp@brainhub.org said:

> export/import control of encryption). Fingerptins are special data
> structures because they are sometimes input by humans.

Well, humans compare fingerprints but don't enter them. =A0I doub= t that I
ever did this in the last 20 years.

Y= es. =A0And it is also important that there is a way to 'uniquely' (= granted the *very* small chance of a collision - I think there has been onl= y one possible collision with SHA-1 fingerprints reported on the gnupg list= ) identify keys to other programs. =A0I suspect that a lot of programs usin= g gnupg and other implementations expect the fingerprint to be unique. =A0T= here does have to be a reliable way to refer to a particular key.

So fingerprints are compared by humans, but= they are also important for computers too - and probably used more by comp= uters than by humans. =A0I don't see the sense in adopting a truncated = standard. =A0Any new fingerprint is going to be more tedious than comparing= SHA-1, but that's the price to be paid for security.

I suppose that humans will start relying mo= re on the key-id. =A0I assume that any new standard would adopt a more coll= ision-resistant key-id.

N.


--047d7b6d8102955e4e04d2ada995-- From iang@iang.org Mon Jan 7 00:30:44 2013 Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBF1521F857B for ; Mon, 7 Jan 2013 00:30:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IE2aK1+KtjBv for ; Mon, 7 Jan 2013 00:30:43 -0800 (PST) Received: from pyyl.pair.com (pyyl.pair.com [209.68.1.203]) by ietfa.amsl.com (Postfix) with ESMTP id 3466221F8526 for ; Mon, 7 Jan 2013 00:30:36 -0800 (PST) Received: from [IPv6:::1] (www2.futureware.at [78.41.115.142]) by pyyl.pair.com (Postfix) with ESMTPSA id 92808B240E; Mon, 7 Jan 2013 03:30:27 -0500 (EST) Message-ID: <50EA879F.60208@iang.org> Date: Mon, 07 Jan 2013 11:30:23 +0300 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: openpgp@ietf.org References: <50E530D6.6020609@brainhub.org> <50E5D6AA.6060200@brainhub.org> <874nixev2u.fsf@vigenere.g10code.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [openpgp] Fingerprints and their collisions resistance X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 08:30:45 -0000 Part of the problem here is that claiming uniqueness to a cryptographic level is harder to do than say. Typically if we are dealing with larger keys and much more aggressive attackers, we'd want to up the size of the hash to larger SHA2/3s. Which means that ordinary users with their human comparison function are going to be left behind. Time factors also make us too conservative. For about 10-15 years we had relative peace with this question because we had a strong single SHA1 that survived well. That is unusual in the history of cryptographic computing, and we can see the reflection of this low expectation in later algorithms - AES, SHA2 and SHA3 all offer a range of strengths. So perhaps we have been lulled into a sense that we can do two or more not-so-complementary things with one algorithm. I cannot see how we can totally mix the unique programmatic identifier with the fingerprint function with a single fixed hash. Basically, humans can be relied upon to never go beyond the 160 bit length of SHA1, and even the dedicated struggle to get that on their business card. 80 bits is far more sensible. So in this sense, we seem to be facing two possible directions: Stick with SHA1, and have the fingerprint for people only. If programs want more, it is up to them to extract out the key and generate their own unique identifier. I do this all the time in my code, and it isn't a bother. There are benefits in doing the right thing up front. Alternatively, if we combine these roles, what we might need then is a more agile *length* but one fixed algorithm. Right now we have KeyID, Fingerprint and something else I forget - 2 or 3 lengths extracted from the same algorithm. To pursue that, we could simply stick in the longest biggest baddest Keccak and write up a process for truncation, for different lengths. Then match that up to the key sizes. (Or, option 3 - as Jon points out, ECC is looking good, and just use the key as is. That has many advantages.) iang On 7/01/13 10:20 AM, Nicholas Cole wrote: > > > > On Thu, Jan 3, 2013 at 10:54 PM, Werner Koch > wrote: > > On Thu, 3 Jan 2013 20:06, openpgp@brainhub.org > said: > > > > export/import control of encryption). Fingerptins are special data > > structures because they are sometimes input by humans. > > Well, humans compare fingerprints but don't enter them. I doubt that I > ever did this in the last 20 years. > > > Yes. And it is also important that there is a way to 'uniquely' > (granted the *very* small chance of a collision - I think there has been > only one possible collision with SHA-1 fingerprints reported on the > gnupg list) identify keys to other programs. I suspect that a lot of > programs using gnupg and other implementations expect the fingerprint to > be unique. There does have to be a reliable way to refer to a > particular key. > > So fingerprints are compared by humans, but they are also important for > computers too - and probably used more by computers than by humans. I > don't see the sense in adopting a truncated standard. Any new > fingerprint is going to be more tedious than comparing SHA-1, but that's > the price to be paid for security. > > I suppose that humans will start relying more on the key-id. I assume > that any new standard would adopt a more collision-resistant key-id. > > N. > > > > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp >