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