--- 1/draft-ietf-lamps-cms-shakes-13.txt 2019-07-22 08:13:44.630484651 -0700
+++ 2/draft-ietf-lamps-cms-shakes-14.txt 2019-07-22 08:13:44.666485564 -0700
@@ -1,20 +1,20 @@
LAMPS WG P. Kampanakis
Internet-Draft Cisco Systems
Updates: 3370 (if approved) Q. Dang
Intended status: Standards Track NIST
Expires: January 22, 2020 July 21, 2019
Use of the SHAKE One-way Hash Functions in the Cryptographic Message
Syntax (CMS)
- draft-ietf-lamps-cms-shakes-13
+ draft-ietf-lamps-cms-shakes-14
Abstract
This document updates the "Cryptographic Message Syntax Algorithms"
(RFC3370) and describes the conventions for using the SHAKE family of
hash functions in the Cryptographic Message Syntax as one-way hash
functions with the RSA Probabilistic signature and ECDSA signature
algorithms. The conventions for the associated signer public keys in
CMS are also described.
@@ -46,45 +46,50 @@
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.
Table of Contents
1. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 2
- 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
3. Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Use in CMS . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Message Digests . . . . . . . . . . . . . . . . . . . . . 7
4.2. Signatures . . . . . . . . . . . . . . . . . . . . . . . 7
4.2.1. RSASSA-PSS Signatures . . . . . . . . . . . . . . . . 8
- 4.2.2. ECDSA Signatures . . . . . . . . . . . . . . . . . . 8
+ 4.2.2. ECDSA Signatures . . . . . . . . . . . . . . . . . . 9
4.3. Public Keys . . . . . . . . . . . . . . . . . . . . . . . 9
4.4. Message Authentication Codes . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Change Log
[ EDNOTE: Remove this section before publication. ]
o draft-ietf-lamps-cms-shake-13:
+ * Fixing error with incorrect preimage resistance bits for SHA128
+ and SHA256.
+
+ o draft-ietf-lamps-cms-shake-13:
+
* Addressing comments from Dan M.'s secdir review.
* Addressing comment from Scott B.'s opsdir review about
references in the abstract.
o draft-ietf-lamps-cms-shake-12:
* Nits identified by Roman, Barry L. in ballot position review.
o draft-ietf-lamps-cms-shake-11:
@@ -346,33 +351,33 @@
the same: both SHAKE128 or both SHAKE256. The output length of the
hash algorithm which hashes the message SHALL be 32 (for SHAKE128) or
64 bytes (for SHAKE256).
The mask generation function takes an octet string of variable length
and a desired output length as input, and outputs an octet string of
the desired length. In RSASSA-PSS with SHAKEs, the SHAKEs MUST be
used natively as the MGF function, instead of the MGF1 algorithm that
uses the hash function in multiple iterations as specified in
Section B.2.1 of [RFC8017]. In other words, the MGF is defined as
- the SHAKE128 or SHAKE256 output of the mgfSeed for id-RSASSA-PSS-
- SHAKE128 and id-RSASSA-PSS-SHAKE256, respectively. The mgfSeed is
- the seed from which mask is generated, an octet string [RFC8017]. As
- explained in Step 9 of section 9.1.1 of [RFC8017], the output length
- of the MGF is emLen - hLen - 1 bytes. emLen is the maximum message
- length ceil((n-1)/8), where n is the RSA modulus in bits. hLen is 32
- and 64-bytes for id-RSASSA-PSS-SHAKE128 and id-RSASSA-PSS-SHAKE256,
- respectively. Thus when SHAKE is used as the MGF, the SHAKE output
- length maskLen is (8*emLen - 264) or (8*emLen - 520) bits,
- respectively. For example, when RSA modulus n is 2048, the output
- length of SHAKE128 or SHAKE256 as the MGF will be 1784 or 1528-bits
- when id-RSASSA-PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256 is used,
- respectively.
+ the SHAKE128 or SHAKE256 with input being the mgfSeed for id-RSASSA-
+ PSS- SHAKE128 and id-RSASSA-PSS-SHAKE256, respectively. The mgfSeed
+ is the seed from which mask is generated, an octet string [RFC8017].
+ As explained in Step 9 of section 9.1.1 of [RFC8017], the output
+ length of the MGF is emLen - hLen - 1 bytes. emLen is the maximum
+ message length ceil((n-1)/8), where n is the RSA modulus in bits.
+ hLen is 32 and 64-bytes for id-RSASSA-PSS-SHAKE128 and id-RSASSA-PSS-
+ SHAKE256, respectively. Thus when SHAKE is used as the MGF, the
+ SHAKE output length maskLen is (8*emLen - 264) or (8*emLen - 520)
+ bits, respectively. For example, when RSA modulus n is 2048, the
+ output length of SHAKE128 or SHAKE256 as the MGF will be 1784 or
+ 1528-bits when id-RSASSA-PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256 is
+ used, respectively.
The RSASSA-PSS saltLength MUST be 32 bytes for id-RSASSA-PSS-SHAKE128
or 64 bytes for id-RSASSA-PSS-SHAKE256. Finally, the trailerField
MUST be 1, which represents the trailer field with hexadecimal value
0xBC [RFC8017].
4.2.2. ECDSA Signatures
The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in
[X9.62]. When the id-ecdsa-with-shake128 or id-ecdsa-with-shake256
@@ -463,30 +468,30 @@
This document updates [RFC3370]. The security considerations section
of that document applies to this specification as well.
NIST has defined appropriate use of the hash functions in terms of
the algorithm strengths and expected time frames for secure use in
Special Publications (SPs) [SP800-78-4] and [SP800-107]. These
documents can be used as guides to choose appropriate key sizes for
various security scenarios.
SHAKE128 with output length of 256-bits offers 128-bits of collision
- and 256-bits of preimage resistance. Thus, SHAKE128 OIDs in this
- specification are RECOMMENDED with 2048 (112-bit security) or
- 3072-bit (128-bit security) RSA modulus or curves with group order of
- 256-bits (128-bit security). SHAKE256 with 512-bits output length
- offers 256-bits of collision and 512-bits of preimage resistance.
- Thus, the SHAKE256 OIDs in this specification are RECOMMENDED with
- 4096-bit RSA modulus or higher or curves with group order of 384-bits
- (256-bit security) or higher. Note that we recommended 4096-bit RSA
- because we would need 15360-bit modulus for 256-bits of security
- which is impractical for today's technology.
+ preimage resistance. Thus, SHAKE128 OIDs in this specification are
+ RECOMMENDED with 2048 (112-bit security) or 3072-bit (128-bit
+ security) RSA modulus or curves with group order of 256-bits (128-bit
+ security). SHAKE256 with 512-bits output length offers 256-bits of
+ collision and preimage resistance. Thus, the SHAKE256 OIDs in this
+ specification are RECOMMENDED with 4096-bit RSA modulus or higher or
+ curves with group order of 521-bits (256-bit security) or higher.
+ Note that we recommended 4096-bit RSA because we would need 15360-bit
+ modulus for 256-bits of security which is impractical for today's
+ technology.
When more than two parties share the same message-authentication key,
data origin authentication is not provided. Any party that knows the
message-authentication key can compute a valid MAC, therefore the
content could originate from any one of the parties.
7. Acknowledgements
This document is based on Russ Housley's draft
[I-D.housley-lamps-cms-sha3-hash]. It replaces SHA3 hash functions