SHA3 IANA registration - method?

Andrey Jivsov openpgp at
Wed Dec 12 22:09:08 CET 2012

I wrote a draft to support SHA-3 Keccak in OpenPGP.

I slowed down thinking about what to do about SHA1 fingerprints before I 
was distracted by unrelated things. My thought was that perhaps this 
draft should be used to resolve the issue of a SHA1 fingerprint by 
introducing a hardwired Keccac fingerprint.

Ignoring the fingerprint issue, the rest of the spec should be 
straighforward. I am attaching the document that I created.

Is it OK if I submit this document in the next few weeks to IETF (has to 
be as a personal work, since there is no WG anymore)? I will announce 
this on openpgp and we go from there.

Is there interest to discuss the fingerprint issue on the openpgp list?

Regarding the immediate implementation, I suppose you can just post the 
private Keccak IDs that you used, promising that these IDs will be 
temporary before we get the IANA numbers.

Thank you.

On 12/12/2012 08:04 AM, David Shaw wrote:
> On Dec 12, 2012, at 5:46 AM, Phil Pennock <gnupg-devel at> wrote:
>> Sorry for asking here, but mail to <ietf-openpgp-request at> is
>> bouncing, so it looks as though the ietf-openpgp list is now completely
>> dead.  The only IETF forum I can spot is the concluded openpgp WG:
> The IETF OpenPGP WG completed their work, so that list was closed.  There is another list, however, for ongoing discussions:  That would be the appropriate place to discuss adding SHA-3 support to OpenPGP.
>> So: what's the best mechanism for registering a "Hash Algorithms" entry
>> in for
>> SHA-3 ?  RFC without implementation or implementation based on PRIVATE
>> USE code-points and then RFC?
> It's pretty simple to propose a new algorithm for OpenPGP: discuss it on the OpenPGP list, and then write and submit an RFC.  The RFC is mainly boilerplate that says "This extends OpenPGP, here's a new hash algorithm, it's specified in such-and-such document, and its algorithm number is XXX.  All the usual statements about hash algorithms from RFC-4880 apply here as well."  IANA changes XXX to the algorithm number on publication.  Take a look at the one I did for Camellia ( and feel free to steal any or all of it.
>> I'm guessing that a working implementation using a PRIVATE USE
>> code-point, per RFC4880 section 13.10, is a decent way to go?  Or is PGP
>> one of the protocols where folks have settled on avoiding private use
>> fields because of the difficulty in migrating away from them?
> The private algorithm numbers are useful for internal use and testing, but I would not ship code that uses them, except for interop testing and similar.  Otherwise, the private algorithm number effectively becomes public, and implementers need to support the real number and the temporary private number for a long time, if not indefinitely.
> David
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel at

-------------- next part --------------

Network Workign Group                                          A. Jivsov
Internet-Draft                                      Symantec Corporation
Intended status: Standards Track                        October 17, 2012
Expires: April 20, 2013

             The use of Secure Hash Algorithm 3 in OpenPGP


   This document presents the necessary information to use the SHA-3
   hash algorithm with the OpenPGP format.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 20, 2013.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   ( in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Jivsov                   Expires April 20, 2013                 [Page 1]
Internet-Draft              SHA-3 in OpenPGP                October 2012

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Conventions used in this document . . . . . . . . . . . . . . . 3
   3.  Overview of the hash algorithm use in OpenPGP . . . . . . . . . 3
   4.  Supported SHA-3 algorithms  . . . . . . . . . . . . . . . . . . 4
   5.  Use with RSA digital signatures . . . . . . . . . . . . . . . . 4
   6.  Interoperability concerns arising from an introduction of
       a new hash algorithm  . . . . . . . . . . . . . . . . . . . . . 5
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   8.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     9.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
     9.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 8

Jivsov                   Expires April 20, 2013                 [Page 2]
Internet-Draft              SHA-3 in OpenPGP                October 2012

1.  Introduction

   The OpenPGP format [RFC4880] supports multiple hash algorithms.  This
   document provides the necessary information to use the Secure Hash
   Algorithm 3 (SHA-3) hash algorithm with the OpenPGP format.

   National Institute of Standards and Technology (NIST) selected
   [Keccak] as the SHA-3 algorithm for its elegant design, its ability
   to run well on different computing devices, higher performance in
   hardware implementations, and different internal structure that
   provides assurances against attacks on its predecessors from the
   SHA-1 and SHA-2 family [Announcement].

   This document has following external dependencies that must be
   resolved prior to the publication:

   TODO 1:   Add the reference to the official SHA-3 specification by
             NIST (only Keccak author's information is currently

   TODO 2:   Review NIST-recommended SHA-3 output sizes (256, 384, 512
             are currently included; exclude 224 if it's in the list?).

   TODO 3:   Add ASN.1 OIDs for RSA signatures (the OIDs are not created

2.  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].

3.  Overview of the hash algorithm use in OpenPGP

   Hash algorithm is used in [RFC4880] in digital signatures, in
   modification detection code, and in key fingerprints.  Only digital
   signatures allow algorithm agility and are most vulnerable to various
   attacks on hash functions.  Thus, the focus of this document is on
   the use of SHA-3 hash with OpenPGP digital signatures.

   The use of hash algorithm with digital signatures in OpenPGP falls
   into two categories.  The first one is the digital signatures over
   messages, and another one is the certifications of the key material.
   The latter area includes self-signatures, which convey key preference
   information, among other tasks.  The rest of key certifications are
   third party key signatures.  These categories will be considered

Jivsov                   Expires April 20, 2013                 [Page 3]
Internet-Draft              SHA-3 in OpenPGP                October 2012

   separately in more details in Section 6 for the impact on

4.  Supported SHA-3 algorithms

   SHA-3 specification REF defines a single cryptographic hash function
   that is parameterized to produce hash output of certain sizes.  This
   document refers to these instantiations of the same hash algorithm as
   SHA-3 hash algorithms and treats them as different hash algorithms.
   This is needed because OpenPGP format expects a fully specified hash
   algorithm, in particular, a hash algorithm identifier (ID) is
   associated with a single fixed hash size.

   The SHA-3 algorithm with the output size of 256, 384, and 512 bits
   MAY be used as a hash algorithm with digital signatures.  The input
   size to the hash algorithm in OpenPGP MUST be even to 8 bits, in
   other words, the input is always represented as a sequence of full
   8-bit octets.

   It is possible to implement all SHA-3 algorithms with a single
   unified implementation, such that the only variable that
   distinguishes these algorithms is an integer representing the hash
   output size.  For example, there are no special tables or magic
   constants that are specific to the hash output size of the SHA-3

   For this reason an application MUST implement signature verification
   for all 3 hash output sizes of SHA-3 algorithm if it implements at
   least one of them.  Application MAY generate signatures with SHA-3-
   256, SHA-3-384, and SHA-3-512 hash algorithms.

   Applications MAY use any SHA-3 digital signature algorithm described
   in [RFC4880] and with Elliptic Curve DSA algorithm described in

5.  Use with RSA digital signatures

   Section 5.2.2 of [RFC4880] describes the Version 3 Signature Packet
   Format.  One of allowed public key algorithms in that section is the
   RSA digital signature algorithm.  RSA signatures use the PKCS#1
   encoding to format (cryptographically "pad") the output of the hash
   algorithm.  The padding includes the DER-encoded prefix that remain
   fixed for the given hash algorithm.  While this prefix is an DER
   encoding of an ASN.1 Object Identifier (OID), the length value of the
   hash output, and other fields, it's possible to specify the prefix as
   a fixed sequence of octets for convenience.  These prefixes are

Jivsov                   Expires April 20, 2013                 [Page 4]
Internet-Draft              SHA-3 in OpenPGP                October 2012

   defined bellow.

     Algorithm             ASN.1 OID             DER of the OID
     --------------------- --------------------- ---------------------
     SHA-3-256             x.y.z ...             XX XX XX ...
     SHA-3-384             x.y.z ...             XX XX XX ...
     SHA-3-512             x.y.z ...             XX XX XX ...

                              SHA-3 hash IDs

   The full DER-encoded hash prefixes are provided bellow.

     Algorithm             Full DER prefix
     --------------------- -------------------------------------------
     SHA-3-256             XX XX XX ...
     SHA-3-384             XX XX XX ...
     SHA-3-512             XX XX XX ...

                       SHA-3 hash full DER prefixes

6.  Interoperability concerns arising from an introduction of a new hash

   This section provides interoperability considerations to help the
   adoption of the SHA-3 algorithm.  Note that these interoperability
   concerns are not unique to SHA-3.  For example, exactly the same
   concerns apply during the introduction of a new digital signature
   algorithm.  Informally speaking, these concerns are the result of the
   process by which we create a data structure that will be processed by
   unknown parties at an undetermined future moment.

   The digital signature validation is dependent on wide support of the
   selected hash algorithm by deployed OpenPGP implementations that will
   be verifying the digital signature.  The consequence of the absence
   of the support for a particular message hash is a public key
   considered invalid, a message reported as that it is tampered with,
   or both.  In general, there is no method in OpenPGP by which a party
   that issues a digital signature can be certain about the support of a
   hash algorithm by other implementations.

   The safest method to mitigate these challenges is a phased deployment
   of the new hash algorithm support, as follows:

   o  Implement the hash algorithm, test it thoroughly.

   o  Enable its use with the supported digital signature algorithms and
      test signature generation and verification with your

Jivsov                   Expires April 20, 2013                 [Page 5]
Internet-Draft              SHA-3 in OpenPGP                October 2012

      implementation and, if possible, others' implementations as well.
      Then disable the signature generation in the production code (i.e.
      leave the "read support" only).

   o  Wait sufficiently long for the deployment of the applications that
      can verify digital signatures with the new hash algorithm.

   The above steps make enabling the generation of signatures with the
   new hash algorithm at a future time safer.

   Two categories of digital signatures in OpenPGP, as described in
   Section 3, have different impact on interoperability.  The use of new
   hash algorithm in a public key certifications, especially in self-
   signatures, too early can make the key unusable in the large extent
   of the OpenPGP ecosystem.  On the other hand, the impact of the use
   of the new hash algorithm in a digital signature over a message is
   limited to users who will be verifying this message.

   The idea of introducing the new hash algorithm first to protect
   messages is consistent with the security risks.  Collision resistance
   is the most difficult to accomplish requirement of the hash
   algorithm.  Collision attacks are most effective when an attacker is
   free to use arbitrary data as a signed plaintext.  It follows that
   such attacks are easier on OpenPGP signed messages as opposed to key
   certifications, therefore, signed messages will benefit the most from
   a stronger hash algorithm.

   In cases when the message is both encrypted and signed, the
   application knows the keys of the entities who will be performing
   signature verification.  The application SHOULD rely on Hash
   Algorithm Preferences of the recipients public keys to learn about
   SHA-3 support.  This preference is described in the Section 13.3.2 of

7.  IANA Considerations

   This document asks to allocate the consecutive hash algorithm IDs
   from the Hash Algorithm ID range, defined in the Section 9.4 of

   The starting ID is not important, but the properties that the IDs are
   sequential and that they are in the given order are expected to
   simplify implementation.

Jivsov                   Expires April 20, 2013                 [Page 6]
Internet-Draft              SHA-3 in OpenPGP                October 2012

                ID   Algorithm                   Text Name
              ------ --------------------------- -----------
                17   SHA-3 with 256 bit output   "SHA-3-256"
                18   SHA-3 with 384 bit output   "SHA-3-384"
                19   SHA-3 with 512 bit output   "SHA-3-512"

                          Table 1: SHA-3 hash IDs

8.  Security Considerations

   The choice of the SHA-3 hash algorithm SHOULD not be weaker than the
   desired level of security of the message signature or the key

   The security bit strength of the hash algorithm is assumed to be half
   of the hash output size; this value is equal to the key size of the
   symmetric key algorithm of equivalent strength.  For example, the
   strength of the SHA-3 256 is equivalent to the strength of the AES-
   128 [AES].

   Using the security bit strength of the hash algorithm, Table 2 from
   [SP 800-57 Part1] SHOULD be used to determine the corresponding
   strength of the public key algorithm.  For example, the SHA-3 256 has
   equivalent security strength to the NIST curve P-256 [RFC6637].

9.  References

9.1.  Normative References

   [Keccak]   Bertoni, G., Daemen, J., Peeters, M., and G. Van Assche,
              "The Keccak sponge function family", 2012,

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4880]  Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
              Thayer, "OpenPGP Message Format", RFC 4880, November 2007.

9.2.  Informative References

   [AES]      NIST, "Specification for the ADVANCED ENCRYPTION STANDARD
              (AES)", November 2001, <


Jivsov                   Expires April 20, 2013                 [Page 7]
Internet-Draft              SHA-3 in OpenPGP                October 2012

              NIST, "NIST Selects Winner of Secure Hash Algorithm
              (SHA-3) Competition", October 2012,

   [RFC6637]  Jivsov, A., "Elliptic Curve Cryptography (ECC) in
              OpenPGP", RFC 6637, June 2012.

   [SP 800-57 Part1]
              NIST, "Recommendation for Key Management -- Part 1:
              General (Revision 3)", July 2012,

Author's Address

   Andrey Jivsov
   Symantec Corporation

   Email: openpgp at

Jivsov                   Expires April 20, 2013                 [Page 8]

More information about the Gnupg-devel mailing list