Re: [openpgp] SHA3 algorithm ids.

Werner Koch <> Tue, 11 August 2015 10:15 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6CBEA1A6FF6 for <>; Tue, 11 Aug 2015 03:15:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Q4rNq5qVvLTg for <>; Tue, 11 Aug 2015 03:15:34 -0700 (PDT)
Received: from ( [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 44B1E1A6FF0 for <>; Tue, 11 Aug 2015 03:15:34 -0700 (PDT)
Received: from uucp by with local-rmail (Exim 4.80 #2 (Debian)) id 1ZP6ah-0005wg-MS for <>; Tue, 11 Aug 2015 12:15:31 +0200
Received: from wk by with local (Exim 4.84 #3 (Debian)) id 1ZP6W5-0007oW-6k; Tue, 11 Aug 2015 12:10:45 +0200
From: Werner Koch <>
To: Phillip Hallam-Baker <>
References: <> <> <> <> <>
Organisation: g10 Code GmbH
X-message-flag: Mails containing HTML will not be read! Please send only plain text.
OpenPGP: id=F2AD85AC1E42B367;
Mail-Followup-To: Phillip Hallam-Baker <>, Derek Atkins <>, IETF OpenPGP <>, ianG <>
Date: Tue, 11 Aug 2015 12:10:45 +0200
In-Reply-To: <> (Phillip Hallam-Baker's message of "Mon, 10 Aug 2015 16:50:32 -0400")
Message-ID: <>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Archived-At: <>
Cc: IETF OpenPGP <>, Derek Atkins <>, ianG <>
Subject: Re: [openpgp] SHA3 algorithm ids.
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, 11 Aug 2015 10:15:36 -0000

On Mon, 10 Aug 2015 22:50, said:

> Given that email recipients tend to end up having to implement all the code
> points in a cipher suite because they can't really control what is sent, I

That is not the case with OpenPGP.  If you encrypt and sign the key
gives you a list of hash algorithms supported by the recipient.  Only
those may be used.   In a signature only case there is no point in an using
extravagant hash algorithm because most recipients won't be able to
verify such a signature.

We have a lot of experience in how to deploy new algorithms and we are
very conservative here.  My request for adding SHA3 algo ids does not
mean in any way that I endorse its use or would even suggest that
4880bis should contain a SHOULD or MAY for implementing such an
algorithm.  When we come to the point on deciding on algorithms I would
suggest something like this: 

 - Implementations MUST implement SHA-1.  Implementations MAY implement
 - other algorithms.  MD5 is deprecated.
 + Implementations MUST implement SHA-1 and SHA2-FIXME.  Implementations
 + MUST NOT implement MD5.  Implementations SHOULD NOT implement
 + SHA3-xxxx.  Implementations MAY implement other algorithms.

The algo ids are a different case and I would be fine with the RFC-7120
method.  Iff the unexpected case happens that a severe weakness in SHA2
is found, the pre-allocated SHA3 ids will allow us to quickly switch to
SHA3.  Isn't that the whole point of SHA3 being plugin-in replacements
for SHA2?

I suggest to use a different thread for discussing algorithm selection
because that is a different topic than assigning algorithm ids.



Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.