Re: [openpgp] New fingerprint: to v5 or not to v5

"Daniel A. Nagy" <> Tue, 29 September 2015 14:26 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 54D941B4205 for <>; Tue, 29 Sep 2015 07:26:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Hg5BWBFVXop8 for <>; Tue, 29 Sep 2015 07:26:10 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5135A1B4204 for <>; Tue, 29 Sep 2015 07:26:09 -0700 (PDT)
Received: by wicfx3 with SMTP id fx3so153259045wic.1 for <>; Tue, 29 Sep 2015 07:26:07 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=FDGNvGTd+Oj/ReeqFTdGSu/O5ONVzf144gKq6FKJl0A=; b=TdUiTole1Qig7wOqEo5r9Q9LG2ZNxJZCLUk3DvrYJsOGolFbzRdTutYTWFrTSsBI7J Nyhta/wNeIIxqoXO+apgd3Z6tEsewOTFk8IH1xHaKAu6x02lu0PHA38FB2jAQhC2Jpnd lstcuWD9d7oyJPSwATJmJ5OC9E/t0QcOwI5e1zEn7ISXj4gjcuGbf2eFYzDKyenSs83S 1USXO4SrN6LHAMbZ2R58M/er+lzxC9pNogEqeh/1IH+h8NNv8rp44X0pizVbf7TaqXSU nlLz4LA8c8uRS946Bl++9K7Hj037PzZeMbsrHOuB58ct8imgkFaQUz31Fsg05wvuLXb3 u3eQ==
X-Gm-Message-State: ALoCoQkRmU2TMyx6jq0GzW4J+pJ00sIAebquLre3MaMxkj8Gb9ElCeSAfQL6XWetaoL6kTzJUaoL
X-Received: by with SMTP id nf19mr26455953wic.74.1443536767778; Tue, 29 Sep 2015 07:26:07 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id z2sm24215910wij.1.2015. for <> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Sep 2015 07:26:06 -0700 (PDT)
References: <> <> <> <>
From: "Daniel A. Nagy" <>
X-Enigmail-Draft-Status: N1110
Message-ID: <>
Date: Tue, 29 Sep 2015 16:26:03 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [openpgp] New fingerprint: to v5 or not to v5
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 29 Sep 2015 14:26:14 -0000


I fully support the "One True Cipher Suite" paradigm of Ian. At Ethereum
(which is where I currently work), we have had quite a long explorative
discussion about the choice of THE hash function, and we came out in
favor of SHA3 (Keccak) for a multitude of good reasons most of which
apply to OpenPGP as well. I believe that the most important documents
from that debate are publicly available, but if necessary, I am willing
to repeat the arguments in a nutshell.

Furthermore, I also believe that if OpenPGP finally leaves the
convoluted CFB variant behind and goes for stream ciphers, SHAKE has
some very clear benefits over AES-CTR, chief among them that by using a
closely related hash function and stream cipher, we follow the "keep all
your eggs in one basket and watch that basket" principle; in other
words, we present a smaller cross-section to potential attackers.



On 2015-09-29 15:54, ianG wrote:
> On 21/09/2015 05:13 am, Simon Josefsson wrote:
>> ianG <> writes:
>>> Hi Werner,
>>> On 17/09/2015 19:41 pm, Werner Koch wrote:
>>>> I'd like to get opinions on one specific aspect of a new fingerprint
>>>> format in 4880bis.
>>>> In the past we bound the fingerprint format to the key packet version:
>>>> v3 keys used MD5 and v4 keys SHA-1 fingerprints.  This gained us the
>>>> benefit of having a bijective connection between fingerprint and key.
>>> I'm hugely on that side.  I'll always vote for that.  I even staked my
>>> rep on it :)
>>> Which came directly from the experience of hacking PGP & OpenPGP in
>>> Perl/Java as part of Cryptix.  The tears, the fears, the costs.
>>> So:  the only choice for me is which hash you pick for v5.  If you
>>> want another one, start planning for v6.
>> +1
>> I believe sub-negotiating in security protocol leads to obscure problems
>> and makes security evaluation harder.  If we can avoid that, and that
>> appears to be the case, I'm all for it.
>> Regarding which hash to use, SHA-256 is probably the simplest choice
>>  From a practicallity and consensus point of view.  Are there any strong
>> reasons to favor something else?
>> What would be the relevant options be anyway?  SHA-256, BLAKE2,
>> SHA3-256, SHA-512, CubeHash?  Would there be value in being able to use
>> variable length SHAKE variants?
> There are a few reasons to go to SHA3 or SHAKE, as far as I see it.
> 1.  It leaps us ahead by about a decade in terms of cryptographic
> experience.
> 2.  It can do any size so we can use the same algorithm for all the
> different uses, without getting into esoteric arguments about
> truncation.  Indeed this is intended -- although rare, the team that
> made SHA3 felt our pain and improved our interface to the black box
> known as the message digest.
> 3.  This further leads to the possibility that if we get scared of the
> "short" length, we can just lengthen the base array and let the software
> work it out.  Similar to PHB's concept, we could just pre-ordain some
> applicable lengths that work for all purposes.
> 4.  The same base algorithm can be used as a symmetric AE cipher.  This
> leads to the possibility of one algorithm family giving most of the
> cryptographic needs (we'd need an asymmetric one too).  The development
> savings and the size savings are not to be sniffed at:  leads to small
> lightweight deployments e.g., on IoT and many more and maintainable
> language implementations.
> 5.  As a higher level meta-advantage, getting us away from the alphabet
> soup approach to protocol design might clarify to us why it is that
> there is an advantage in having more than one of everything around.
> iang
> _______________________________________________
> openpgp mailing list