SHA3 IANA registration - method?
Andrey Jivsov
openpgp at brainhub.org
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 spodhuis.org> wrote:
>
>> Sorry for asking here, but mail to <ietf-openpgp-request at imc.org> 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:
>> http://www.ietf.org/wg/concluded/openpgp.html
>
> The IETF OpenPGP WG completed their work, so that list was closed. There is another list, however, for ongoing discussions: https://www.ietf.org/mailman/listinfo/openpgp. 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 http://www.iana.org/assignments/pgp-parameters/pgp-parameters.xml 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 (http://tools.ietf.org/html/rfc5581) 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 gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel
>
-------------- 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
draft-jivsov-openpgp-sha3-00
Abstract
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 http://datatracker.ietf.org/drafts/current/.
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
(http://trustee.ietf.org/license-info) 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
available)
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
yet)
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
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
interoperability.
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
algorithms.
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
[RFC6637].
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
algorithm
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
[RFC4880].
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
[RFC4880].
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
certification.
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,
<http://http://keccak.noekeon.org/>.
[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, <http://csrc.nist.gov/publications/
fips/fips197/fips-197.pdf>.
[Announcement]
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,
<http://www.nist.gov/itl/csd/sha-100212.cfm>.
[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,
<http://csrc.nist.gov/publications/PubsSPs.html>.
Author's Address
Andrey Jivsov
Symantec Corporation
Email: openpgp at brainhub.org
Jivsov Expires April 20, 2013 [Page 8]
More information about the Gnupg-devel
mailing list