Re: [openpgp] Fingerprints and their collisions resistance
Andrey Jivsov <openpgp@brainhub.org> Thu, 03 January 2013 23:30 UTC
Return-Path: <openpgp@brainhub.org>
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 <openpgp@ietfa.amsl.com>; 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 <openpgp@ietfa.amsl.com>; 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 <openpgp@ietf.org>; 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 <openpgp@brainhub.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120605 Thunderbird/13.0
MIME-Version: 1.0
To: Werner Koch <wk@gnupg.org>
References: <50E530D6.6020609@brainhub.org> <D3684BB5-FDC6-4834-8FAE-C482A25E3FB0@callas.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@brainhub.org>, openpgp@ietf.org, Jon Callas <jon@callas.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." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/openpgp>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=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.
- [openpgp] Fingerprints and their collisions resis… Andrey Jivsov
- Re: [openpgp] Fingerprints and their collisions r… ianG
- Re: [openpgp] Fingerprints and their collisions r… Nicholas Cole
- Re: [openpgp] Fingerprints and their collisions r… Jon Callas
- Re: [openpgp] Fingerprints and their collisions r… Arturo 'Buanzo' Busleiman
- Re: [openpgp] Fingerprints and their collisions r… Andrey Jivsov
- Re: [openpgp] Fingerprints and their collisions r… Tony Hansen
- Re: [openpgp] Fingerprints and their collisions r… Andrey Jivsov
- Re: [openpgp] Fingerprints and their collisions r… Andrey Jivsov
- Re: [openpgp] Fingerprints and their collisions r… Werner Koch
- Re: [openpgp] Fingerprints and their collisions r… Daniel Kahn Gillmor
- Re: [openpgp] Fingerprints and their collisions r… Andrey Jivsov
- Re: [openpgp] Fingerprints and their collisions r… Andrey Jivsov
- Re: [openpgp] Fingerprints and their collisions r… Daniel Kahn Gillmor
- Re: [openpgp] Fingerprints and their collisions r… Andrey Jivsov
- Re: [openpgp] Fingerprints and their collisions r… ianG
- Re: [openpgp] Fingerprints and their collisions r… ianG
- Re: [openpgp] Fingerprints and their collisions r… ianG
- Re: [openpgp] Fingerprints and their collisions r… Christian Aistleitner
- Re: [openpgp] Fingerprints and their collisions r… Andrey Jivsov
- Re: [openpgp] Fingerprints and their collisions r… Andrey Jivsov
- Re: [openpgp] Fingerprints and their collisions r… jbar
- Re: [openpgp] Fingerprints and their collisions r… Christian Aistleitner
- Re: [openpgp] Fingerprints and their collisions r… Daniel Kahn Gillmor
- Re: [openpgp] Fingerprints and their collisions r… Andrey Jivsov
- Re: [openpgp] Fingerprints and their collisions r… ianG
- Re: [openpgp] Fingerprints and their collisions r… Jon Callas
- Re: [openpgp] Fingerprints and their collisions r… Werner Koch
- Re: [openpgp] Fingerprints and their collisions r… Daniel Kahn Gillmor
- Re: [openpgp] Fingerprints and their collisions r… Jon Callas
- Re: [openpgp] Fingerprints and their collisions r… Andrey Jivsov
- Re: [openpgp] Fingerprints and their collisions r… Andrey Jivsov
- Re: [openpgp] Fingerprints and their collisions r… Andrey Jivsov
- Re: [openpgp] Fingerprints and their collisions r… Werner Koch
- Re: [openpgp] Fingerprints and their collisions r… Werner Koch
- Re: [openpgp] Fingerprints and their collisions r… Bill Frantz
- Re: [openpgp] Fingerprints and their collisions r… Jon Callas
- Re: [openpgp] Fingerprints and their collisions r… Nicholas Cole
- Re: [openpgp] Fingerprints and their collisions r… ianG