summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8017.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8017.txt')
-rw-r--r--doc/rfc/rfc8017.txt4371
1 files changed, 4371 insertions, 0 deletions
diff --git a/doc/rfc/rfc8017.txt b/doc/rfc/rfc8017.txt
new file mode 100644
index 0000000..4984989
--- /dev/null
+++ b/doc/rfc/rfc8017.txt
@@ -0,0 +1,4371 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) K. Moriarty, Ed.
+Request for Comments: 8017 EMC Corporation
+Obsoletes: 3447 B. Kaliski
+Category: Informational Verisign
+ISSN: 2070-1721 J. Jonsson
+ Subset AB
+ A. Rusch
+ RSA
+ November 2016
+
+
+ PKCS #1: RSA Cryptography Specifications Version 2.2
+
+Abstract
+
+ This document provides recommendations for the implementation of
+ public-key cryptography based on the RSA algorithm, covering
+ cryptographic primitives, encryption schemes, signature schemes with
+ appendix, and ASN.1 syntax for representing keys and for identifying
+ the schemes.
+
+ This document represents a republication of PKCS #1 v2.2 from RSA
+ Laboratories' Public-Key Cryptography Standards (PKCS) series. By
+ publishing this RFC, change control is transferred to the IETF.
+
+ This document also obsoletes RFC 3447.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Not all documents
+ approved by the IESG are a candidate for any level of Internet
+ Standard; see Section 2 of RFC 7841.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc8017.
+
+
+
+
+
+
+
+
+
+Moriarty, et al. Informational [Page 1]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+Copyright Notice
+
+ Copyright (c) 2016 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moriarty, et al. Informational [Page 2]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
+ 2. Notation . . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 3. Key Types . . . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 3.1. RSA Public Key . . . . . . . . . . . . . . . . . . . . . 8
+ 3.2. RSA Private Key . . . . . . . . . . . . . . . . . . . . . 9
+ 4. Data Conversion Primitives . . . . . . . . . . . . . . . . . 11
+ 4.1. I2OSP . . . . . . . . . . . . . . . . . . . . . . . . . . 11
+ 4.2. OS2IP . . . . . . . . . . . . . . . . . . . . . . . . . . 12
+ 5. Cryptographic Primitives . . . . . . . . . . . . . . . . . . 12
+ 5.1. Encryption and Decryption Primitives . . . . . . . . . . 12
+ 5.1.1. RSAEP . . . . . . . . . . . . . . . . . . . . . . . . 13
+ 5.1.2. RSADP . . . . . . . . . . . . . . . . . . . . . . . . 13
+ 5.2. Signature and Verification Primitives . . . . . . . . . . 15
+ 5.2.1. RSASP1 . . . . . . . . . . . . . . . . . . . . . . . 15
+ 5.2.2. RSAVP1 . . . . . . . . . . . . . . . . . . . . . . . 16
+ 6. Overview of Schemes . . . . . . . . . . . . . . . . . . . . . 17
+ 7. Encryption Schemes . . . . . . . . . . . . . . . . . . . . . 18
+ 7.1. RSAES-OAEP . . . . . . . . . . . . . . . . . . . . . . . 19
+ 7.1.1. Encryption Operation . . . . . . . . . . . . . . . . 22
+ 7.1.2. Decryption Operation . . . . . . . . . . . . . . . . 25
+ 7.2. RSAES-PKCS1-v1_5 . . . . . . . . . . . . . . . . . . . . 27
+ 7.2.1. Encryption Operation . . . . . . . . . . . . . . . . 28
+ 7.2.2. Decryption Operation . . . . . . . . . . . . . . . . 29
+ 8. Signature Scheme with Appendix . . . . . . . . . . . . . . . 31
+ 8.1. RSASSA-PSS . . . . . . . . . . . . . . . . . . . . . . . 32
+ 8.1.1. Signature Generation Operation . . . . . . . . . . . 33
+ 8.1.2. Signature Verification Operation . . . . . . . . . . 34
+ 8.2. RSASSA-PKCS1-v1_5 . . . . . . . . . . . . . . . . . . . . 35
+ 8.2.1. Signature Generation Operation . . . . . . . . . . . 36
+ 8.2.2. Signature Verification Operation . . . . . . . . . . 37
+ 9. Encoding Methods for Signatures with Appendix . . . . . . . . 39
+ 9.1. EMSA-PSS . . . . . . . . . . . . . . . . . . . . . . . . 40
+ 9.1.1. Encoding Operation . . . . . . . . . . . . . . . . . 42
+ 9.1.2. Verification Operation . . . . . . . . . . . . . . . 44
+ 9.2. EMSA-PKCS1-v1_5 . . . . . . . . . . . . . . . . . . . . . 45
+ 10. Security Considerations . . . . . . . . . . . . . . . . . . . 47
+ 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 48
+ 11.1. Normative References . . . . . . . . . . . . . . . . . . 48
+ 11.2. Informative References . . . . . . . . . . . . . . . . . 48
+
+
+
+
+
+
+
+
+
+Moriarty, et al. Informational [Page 3]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+ Appendix A. ASN.1 Syntax . . . . . . . . . . . . . . . . . . . . 54
+ A.1. RSA Key Representation . . . . . . . . . . . . . . . . . 54
+ A.1.1. RSA Public Key Syntax . . . . . . . . . . . . . . . . 54
+ A.1.2. RSA Private Key Syntax . . . . . . . . . . . . . . . 55
+ A.2. Scheme Identification . . . . . . . . . . . . . . . . . . 57
+ A.2.1. RSAES-OAEP . . . . . . . . . . . . . . . . . . . . . 57
+ A.2.2. RSAES-PKCS-v1_5 . . . . . . . . . . . . . . . . . . . 60
+ A.2.3. RSASSA-PSS . . . . . . . . . . . . . . . . . . . . . 60
+ A.2.4. RSASSA-PKCS-v1_5 . . . . . . . . . . . . . . . . . . 62
+ Appendix B. Supporting Techniques . . . . . . . . . . . . . . . 63
+ B.1. Hash Functions . . . . . . . . . . . . . . . . . . . . . 63
+ B.2. Mask Generation Functions . . . . . . . . . . . . . . . . 66
+ B.2.1. MGF1 . . . . . . . . . . . . . . . . . . . . . . . . 67
+ Appendix C. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 68
+ Appendix D. Revision History of PKCS #1 . . . . . . . . . . . . 76
+ Appendix E. About PKCS . . . . . . . . . . . . . . . . . . . . . 77
+ Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 78
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 78
+
+1. Introduction
+
+ This document provides recommendations for the implementation of
+ public-key cryptography based on the RSA algorithm [RSA], covering
+ the following aspects:
+
+ o Cryptographic primitives
+
+ o Encryption schemes
+
+ o Signature schemes with appendix
+
+ o ASN.1 syntax for representing keys and for identifying the schemes
+
+ The recommendations are intended for general application within
+ computer and communications systems and as such include a fair amount
+ of flexibility. It is expected that application standards based on
+ these specifications may include additional constraints. The
+ recommendations are intended to be compatible with the standards IEEE
+ 1363 [IEEE1363], IEEE 1363a [IEEE1363A], and ANSI X9.44 [ANSIX944].
+
+ This document supersedes PKCS #1 version 2.1 [RFC3447] but includes
+ compatible techniques.
+
+ The organization of this document is as follows:
+
+ o Section 1 is an introduction.
+
+ o Section 2 defines some notation used in this document.
+
+
+
+Moriarty, et al. Informational [Page 4]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+ o Section 3 defines the RSA public and private key types.
+
+ o Sections 4 and 5 define several primitives, or basic mathematical
+ operations. Data conversion primitives are in Section 4, and
+ cryptographic primitives (encryption-decryption and signature-
+ verification) are in Section 5.
+
+ o Sections 6, 7, and 8 deal with the encryption and signature
+ schemes in this document. Section 6 gives an overview. Along
+ with the methods found in PKCS #1 v1.5, Section 7 defines an
+ encryption scheme based on Optimal Asymmetric Encryption Padding
+ (OAEP) [OAEP], and Section 8 defines a signature scheme with
+ appendix based on the Probabilistic Signature Scheme (PSS)
+ [RSARABIN] [PSS].
+
+ o Section 9 defines the encoding methods for the signature schemes
+ in Section 8.
+
+ o Appendix A defines the ASN.1 syntax for the keys defined in
+ Section 3 and the schemes in Sections 7 and 8.
+
+ o Appendix B defines the hash functions and the mask generation
+ function (MGF) used in this document, including ASN.1 syntax for
+ the techniques.
+
+ o Appendix C gives an ASN.1 module.
+
+ o Appendices D and E outline the revision history of PKCS #1 and
+ provide general information about the Public-Key Cryptography
+ Standards.
+
+ This document represents a republication of PKCS #1 v2.2 [PKCS1_22]
+ from RSA Laboratories' Public-Key Cryptography Standards (PKCS)
+ series.
+
+1.1. Requirements Language
+
+ 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].
+
+
+
+
+
+
+
+
+
+
+
+Moriarty, et al. Informational [Page 5]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+2. Notation
+
+ The notation in this document includes:
+
+ c ciphertext representative, an integer between 0 and
+ n-1
+
+ C ciphertext, an octet string
+
+ d RSA private exponent
+
+ d_i additional factor r_i's CRT exponent,
+ a positive integer such that
+
+ e * d_i == 1 (mod (r_i-1)), i = 3, ..., u
+
+ dP p's CRT exponent, a positive integer such that
+
+ e * dP == 1 (mod (p-1))
+
+ dQ q's CRT exponent, a positive integer such that
+
+ e * dQ == 1 (mod (q-1))
+
+ e RSA public exponent
+
+ EM encoded message, an octet string
+
+ emBits (intended) length in bits of an encoded message EM
+
+ emLen (intended) length in octets of an encoded message
+ EM
+
+ GCD(. , .) greatest common divisor of two nonnegative integers
+
+ Hash hash function
+
+ hLen output length in octets of hash function Hash
+
+ k length in octets of the RSA modulus n
+
+ K RSA private key
+
+ L optional RSAES-OAEP label, an octet string
+
+ LCM(., ..., .) least common multiple of a list of nonnegative
+ integers
+
+
+
+
+Moriarty, et al. Informational [Page 6]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+ m message representative, an integer between 0 and
+ n-1
+
+ M message, an octet string
+
+ mask MGF output, an octet string
+
+ maskLen (intended) length of the octet string mask
+
+ MGF mask generation function
+
+ mgfSeed seed from which mask is generated, an octet string
+
+ mLen length in octets of a message M
+
+ n RSA modulus, n = r_1 * r_2 * ... * r_u , u >= 2
+
+ (n, e) RSA public key
+
+ p, q first two prime factors of the RSA modulus n
+
+ qInv CRT coefficient, a positive integer less than
+ p such that q * qInv == 1 (mod p)
+
+ r_i prime factors of the RSA modulus n, including
+ r_1 = p, r_2 = q, and additional factors if any
+
+ s signature representative, an integer between 0 and
+ n-1
+
+ S signature, an octet string
+
+ sLen length in octets of the EMSA-PSS salt
+
+ t_i additional prime factor r_i's CRT coefficient, a
+ positive integer less than r_i such that
+
+ r_1 * r_2 * ... * r_(i-1) * t_i == 1 (mod r_i) ,
+
+ i = 3, ... , u
+
+ u number of prime factors of the RSA modulus, u >= 2
+
+ x a nonnegative integer
+
+ X an octet string corresponding to x
+
+ xLen (intended) length of the octet string X
+
+
+
+Moriarty, et al. Informational [Page 7]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+ 0x indicator of hexadecimal representation of an octet
+ or an octet string: "0x48" denotes the octet with
+ hexadecimal value 48; "(0x)48 09 0e" denotes the
+ string of three consecutive octets with hexadecimal
+ values 48, 09, and 0e, respectively
+
+ \lambda(n) LCM(r_1-1, r_2-1, ... , r_u-1)
+
+ \xor bit-wise exclusive-or of two octet strings
+
+ \ceil(.) ceiling function; \ceil(x) is the smallest integer
+ larger than or equal to the real number x
+
+ || concatenation operator
+
+ == congruence symbol; a == b (mod n) means that the
+ integer n divides the integer a - b
+
+ Note: The Chinese Remainder Theorem (CRT) can be applied in a non-
+ recursive as well as a recursive way. In this document, a recursive
+ approach following Garner's algorithm [GARNER] is used. See also
+ Note 1 in Section 3.2.
+
+3. Key Types
+
+ Two key types are employed in the primitives and schemes defined in
+ this document: RSA public key and RSA private key. Together, an RSA
+ public key and an RSA private key form an RSA key pair.
+
+ This specification supports so-called "multi-prime" RSA where the
+ modulus may have more than two prime factors. The benefit of multi-
+ prime RSA is lower computational cost for the decryption and
+ signature primitives, provided that the CRT is used. Better
+ performance can be achieved on single processor platforms, but to a
+ greater extent on multiprocessor platforms, where the modular
+ exponentiations involved can be done in parallel.
+
+ For a discussion on how multi-prime affects the security of the RSA
+ cryptosystem, the reader is referred to [SILVERMAN].
+
+3.1. RSA Public Key
+
+ For the purposes of this document, an RSA public key consists of two
+ components:
+
+ n the RSA modulus, a positive integer
+ e the RSA public exponent, a positive integer
+
+
+
+
+Moriarty, et al. Informational [Page 8]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+ In a valid RSA public key, the RSA modulus n is a product of u
+ distinct odd primes r_i, i = 1, 2, ..., u, where u >= 2, and the RSA
+ public exponent e is an integer between 3 and n - 1 satisfying
+ GCD(e,\lambda(n)) = 1, where \lambda(n) = LCM(r_1 - 1, ..., r_u - 1).
+ By convention, the first two primes r_1 and r_2 may also be denoted p
+ and q, respectively.
+
+ A recommended syntax for interchanging RSA public keys between
+ implementations is given in Appendix A.1.1; an implementation's
+ internal representation may differ.
+
+3.2. RSA Private Key
+
+ For the purposes of this document, an RSA private key may have either
+ of two representations.
+
+ 1. The first representation consists of the pair (n, d), where the
+ components have the following meanings:
+
+ n the RSA modulus, a positive integer
+ d the RSA private exponent, a positive integer
+
+ 2. The second representation consists of a quintuple (p, q, dP, dQ,
+ qInv) and a (possibly empty) sequence of triplets (r_i, d_i,
+ t_i), i = 3, ..., u, one for each prime not in the quintuple,
+ where the components have the following meanings:
+
+ p the first factor, a positive integer
+ q the second factor, a positive integer
+ dP the first factor's CRT exponent, a positive integer
+ dQ the second factor's CRT exponent, a positive integer
+ qInv the (first) CRT coefficient, a positive integer
+ r_i the i-th factor, a positive integer
+ d_i the i-th factor's CRT exponent, a positive integer
+ t_i the i-th factor's CRT coefficient, a positive integer
+
+ In a valid RSA private key with the first representation, the RSA
+ modulus n is the same as in the corresponding RSA public key and is
+ the product of u distinct odd primes r_i, i = 1, 2, ..., u, where u
+ >= 2. The RSA private exponent d is a positive integer less than n
+ satisfying
+
+ e * d == 1 (mod \lambda(n)),
+
+ where e is the corresponding RSA public exponent and \lambda(n) is
+ defined as in Section 3.1.
+
+
+
+
+
+Moriarty, et al. Informational [Page 9]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+ In a valid RSA private key with the second representation, the two
+ factors p and q are the first two prime factors of the RSA modulus n
+ (i.e., r_1 and r_2); the CRT exponents dP and dQ are positive
+ integers less than p and q, respectively, satisfying
+
+ e * dP == 1 (mod (p-1))
+
+ e * dQ == 1 (mod (q-1)) ,
+
+ and the CRT coefficient qInv is a positive integer less than p
+ satisfying
+
+ q * qInv == 1 (mod p).
+
+ If u > 2, the representation will include one or more triplets (r_i,
+ d_i, t_i), i = 3, ..., u. The factors r_i are the additional prime
+ factors of the RSA modulus n. Each CRT exponent d_i (i = 3, ..., u)
+ satisfies
+
+ e * d_i == 1 (mod (r_i - 1)).
+
+ Each CRT coefficient t_i (i = 3, ..., u) is a positive integer less
+ than r_i satisfying
+
+ R_i * t_i == 1 (mod r_i) ,
+
+ where R_i = r_1 * r_2 * ... * r_(i-1).
+
+ A recommended syntax for interchanging RSA private keys between
+ implementations, which includes components from both representations,
+ is given in Appendix A.1.2; an implementation's internal
+ representation may differ.
+
+ Notes:
+
+ 1. The definition of the CRT coefficients here and the formulas that
+ use them in the primitives in Section 5 generally follow Garner's
+ algorithm [GARNER] (see also Algorithm 14.71 in [HANDBOOK]).
+ However, for compatibility with the representations of RSA
+ private keys in PKCS #1 v2.0 and previous versions, the roles of
+ p and q are reversed compared to the rest of the primes. Thus,
+ the first CRT coefficient, qInv, is defined as the inverse of q
+ mod p, rather than as the inverse of R_1 mod r_2, i.e., of
+ p mod q.
+
+ 2. Quisquater and Couvreur [FASTDEC] observed the benefit of
+ applying the CRT to RSA operations.
+
+
+
+
+Moriarty, et al. Informational [Page 10]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+4. Data Conversion Primitives
+
+ Two data conversion primitives are employed in the schemes defined in
+ this document:
+
+ o I2OSP - Integer-to-Octet-String primitive
+
+ o OS2IP - Octet-String-to-Integer primitive
+
+ For the purposes of this document, and consistent with ASN.1 syntax,
+ an octet string is an ordered sequence of octets (eight-bit bytes).
+ The sequence is indexed from first (conventionally, leftmost) to last
+ (rightmost). For purposes of conversion to and from integers, the
+ first octet is considered the most significant in the following
+ conversion primitives.
+
+4.1. I2OSP
+
+ I2OSP converts a nonnegative integer to an octet string of a
+ specified length.
+
+ I2OSP (x, xLen)
+
+ Input:
+
+ x nonnegative integer to be converted
+
+ xLen intended length of the resulting octet string
+
+ Output:
+
+ X corresponding octet string of length xLen
+
+ Error: "integer too large"
+
+ Steps:
+
+ 1. If x >= 256^xLen, output "integer too large" and stop.
+
+ 2. Write the integer x in its unique xLen-digit representation in
+ base 256:
+
+ x = x_(xLen-1) 256^(xLen-1) + x_(xLen-2) 256^(xLen-2) + ...
+ + x_1 256 + x_0,
+
+ where 0 <= x_i < 256 (note that one or more leading digits
+ will be zero if x is less than 256^(xLen-1)).
+
+
+
+
+Moriarty, et al. Informational [Page 11]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+ 3. Let the octet X_i have the integer value x_(xLen-i) for 1 <= i
+ <= xLen. Output the octet string
+
+ X = X_1 X_2 ... X_xLen.
+
+4.2. OS2IP
+
+ OS2IP converts an octet string to a nonnegative integer.
+
+ OS2IP (X)
+
+ Input: X octet string to be converted
+
+ Output: x corresponding nonnegative integer
+
+ Steps:
+
+ 1. Let X_1 X_2 ... X_xLen be the octets of X from first to last,
+ and let x_(xLen-i) be the integer value of the octet X_i for 1
+ <= i <= xLen.
+
+ 2. Let x = x_(xLen-1) 256^(xLen-1) + x_(xLen-2) 256^(xLen-2) +
+ ... + x_1 256 + x_0.
+
+ 3. Output x.
+
+5. Cryptographic Primitives
+
+ Cryptographic primitives are basic mathematical operations on which
+ cryptographic schemes can be built. They are intended for
+ implementation in hardware or as software modules and are not
+ intended to provide security apart from a scheme.
+
+ Four types of primitive are specified in this document, organized in
+ pairs: encryption and decryption; and signature and verification.
+
+ The specifications of the primitives assume that certain conditions
+ are met by the inputs, in particular that RSA public and private keys
+ are valid.
+
+5.1. Encryption and Decryption Primitives
+
+ An encryption primitive produces a ciphertext representative from a
+ message representative under the control of a public key, and a
+ decryption primitive recovers the message representative from the
+ ciphertext representative under the control of the corresponding
+ private key.
+
+
+
+
+Moriarty, et al. Informational [Page 12]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+ One pair of encryption and decryption primitives is employed in the
+ encryption schemes defined in this document and is specified here:
+ RSA Encryption Primitive (RSAEP) / RSA Decryption Primitive (RSADP).
+ RSAEP and RSADP involve the same mathematical operation, with
+ different keys as input. The primitives defined here are the same as
+ Integer Factorization Encryption Primitive using RSA (IFEP-RSA) /
+ Integer Factorization Decryption Primitive using RSA (IFDP-RSA) in
+ IEEE 1363 [IEEE1363] (except that support for multi-prime RSA has
+ been added) and are compatible with PKCS #1 v1.5.
+
+ The main mathematical operation in each primitive is exponentiation.
+
+5.1.1. RSAEP
+
+ RSAEP ((n, e), m)
+
+ Input:
+
+ (n, e) RSA public key
+
+ m message representative, an integer between 0 and n - 1
+
+ Output: c ciphertext representative, an integer between 0 and n - 1
+
+ Error: "message representative out of range"
+
+ Assumption: RSA public key (n, e) is valid
+
+ Steps:
+
+ 1. If the message representative m is not between 0 and n - 1,
+ output "message representative out of range" and stop.
+
+ 2. Let c = m^e mod n.
+
+ 3. Output c.
+
+5.1.2. RSADP
+
+ RSADP (K, c)
+
+ Input:
+
+ K RSA private key, where K has one of the following forms:
+
+ + a pair (n, d)
+
+
+
+
+
+Moriarty, et al. Informational [Page 13]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+ + a quintuple (p, q, dP, dQ, qInv) and a possibly empty
+ sequence of triplets (r_i, d_i, t_i), i = 3, ..., u
+
+ c ciphertext representative, an integer between 0 and n - 1
+
+ Output: m message representative, an integer between 0 and n - 1
+
+ Error: "ciphertext representative out of range"
+
+ Assumption: RSA private key K is valid
+
+ Steps:
+
+ 1. If the ciphertext representative c is not between 0 and n - 1,
+ output "ciphertext representative out of range" and stop.
+
+ 2. The message representative m is computed as follows.
+
+ a. If the first form (n, d) of K is used, let m = c^d mod n.
+
+ b. If the second form (p, q, dP, dQ, qInv) and (r_i, d_i,
+ t_i) of K is used, proceed as follows:
+
+ i. Let m_1 = c^dP mod p and m_2 = c^dQ mod q.
+
+ ii. If u > 2, let m_i = c^(d_i) mod r_i, i = 3, ..., u.
+
+ iii. Let h = (m_1 - m_2) * qInv mod p.
+
+ iv. Let m = m_2 + q * h.
+
+ v. If u > 2, let R = r_1 and for i = 3 to u do
+
+ 1. Let R = R * r_(i-1).
+
+ 2. Let h = (m_i - m) * t_i mod r_i.
+
+ 3. Let m = m + R * h.
+
+ 3. Output m.
+
+ Note: Step 2.b can be rewritten as a single loop, provided that one
+ reverses the order of p and q. For consistency with PKCS #1 v2.0,
+ however, the first two primes p and q are treated separately from the
+ additional primes.
+
+
+
+
+
+
+Moriarty, et al. Informational [Page 14]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+5.2. Signature and Verification Primitives
+
+ A signature primitive produces a signature representative from a
+ message representative under the control of a private key, and a
+ verification primitive recovers the message representative from the
+ signature representative under the control of the corresponding
+ public key. One pair of signature and verification primitives is
+ employed in the signature schemes defined in this document and is
+ specified here: RSA Signature Primitive, version 1 (RSASP1) / RSA
+ Verification Primitive, version 1 (RSAVP1).
+
+ The primitives defined here are the same as Integer Factorization
+ Signature Primitive using RSA, version 1 (IFSP-RSA1) / Integer
+ Factorization Verification Primitive using RSA, version 1 (IFVP-RSA1)
+ in IEEE 1363 [IEEE1363] (except that support for multi-prime RSA has
+ been added) and are compatible with PKCS #1 v1.5.
+
+ The main mathematical operation in each primitive is exponentiation,
+ as in the encryption and decryption primitives of Section 5.1.
+ RSASP1 and RSAVP1 are the same as RSADP and RSAEP except for the
+ names of their input and output arguments; they are distinguished as
+ they are intended for different purposes.
+
+5.2.1. RSASP1
+
+ RSASP1 (K, m)
+
+ Input:
+
+ K RSA private key, where K has one of the following forms:
+ - a pair (n, d)
+ - a quintuple (p, q, dP, dQ, qInv) and a (possibly empty)
+ sequence of triplets (r_i, d_i, t_i), i = 3, ..., u
+ m message representative, an integer between 0 and n - 1
+
+
+ Output:
+
+ s signature representative, an integer between 0 and n - 1
+
+ Error: "message representative out of range"
+
+ Assumption: RSA private key K is valid
+
+
+
+
+
+
+
+
+Moriarty, et al. Informational [Page 15]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+ Steps:
+
+ 1. If the message representative m is not between 0 and n - 1,
+ output "message representative out of range" and stop.
+
+ 2. The signature representative s is computed as follows.
+
+ a. If the first form (n, d) of K is used, let s = m^d mod n.
+
+ b. If the second form (p, q, dP, dQ, qInv) and (r_i, d_i,
+ t_i) of K is used, proceed as follows:
+
+ 1. Let s_1 = m^dP mod p and s_2 = m^dQ mod q.
+
+ 2. If u > 2, let s_i = m^(d_i) mod r_i, i = 3, ..., u.
+
+ 3. Let h = (s_1 - s_2) * qInv mod p.
+
+ 4. Let s = s_2 + q * h.
+
+ 5. If u > 2, let R = r_1 and for i = 3 to u do
+
+ a. Let R = R * r_(i-1).
+
+ b. Let h = (s_i - s) * t_i mod r_i.
+
+ c. Let s = s + R * h.
+
+ 3. Output s.
+
+ Note: Step 2.b can be rewritten as a single loop, provided that one
+ reverses the order of p and q. For consistency with PKCS #1 v2.0,
+ however, the first two primes p and q are treated separately from the
+ additional primes.
+
+5.2.2. RSAVP1
+
+ RSAVP1 ((n, e), s)
+
+ Input:
+
+ (n, e) RSA public key
+
+ s signature representative, an integer between 0 and n - 1
+
+
+
+
+
+
+
+Moriarty, et al. Informational [Page 16]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+ Output:
+
+ m message representative, an integer between 0 and n - 1
+
+ Error: "signature representative out of range"
+
+ Assumption: RSA public key (n, e) is valid
+
+ Steps:
+
+ 1. If the signature representative s is not between 0 and n - 1,
+ output "signature representative out of range" and stop.
+
+ 2. Let m = s^e mod n.
+
+ 3. Output m.
+
+6. Overview of Schemes
+
+ A scheme combines cryptographic primitives and other techniques to
+ achieve a particular security goal. Two types of scheme are
+ specified in this document: encryption schemes and signature schemes
+ with appendix.
+
+ The schemes specified in this document are limited in scope in that
+ their operations consist only of steps to process data with an RSA
+ public or private key, and they do not include steps for obtaining or
+ validating the key. Thus, in addition to the scheme operations, an
+ application will typically include key management operations by which
+ parties may select RSA public and private keys for a scheme
+ operation. The specific additional operations and other details are
+ outside the scope of this document.
+
+ As was the case for the cryptographic primitives (Section 5), the
+ specifications of scheme operations assume that certain conditions
+ are met by the inputs, in particular that RSA public and private keys
+ are valid. The behavior of an implementation is thus unspecified
+ when a key is invalid. The impact of such unspecified behavior
+ depends on the application. Possible means of addressing key
+ validation include explicit key validation by the application; key
+ validation within the public-key infrastructure; and assignment of
+ liability for operations performed with an invalid key to the party
+ who generated the key.
+
+ A generally good cryptographic practice is to employ a given RSA key
+ pair in only one scheme. This avoids the risk that vulnerability in
+ one scheme may compromise the security of the other and may be
+ essential to maintain provable security. While RSAES-PKCS1-v1_5
+
+
+
+Moriarty, et al. Informational [Page 17]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+ (Section 7.2) and RSASSA-PKCS1-v1_5 (Section 8.2) have traditionally
+ been employed together without any known bad interactions (indeed,
+ this is the model introduced by PKCS #1 v1.5), such a combined use of
+ an RSA key pair is NOT RECOMMENDED for new applications.
+
+ To illustrate the risks related to the employment of an RSA key pair
+ in more than one scheme, suppose an RSA key pair is employed in both
+ RSAES-OAEP (Section 7.1) and RSAES-PKCS1-v1_5. Although RSAES-OAEP
+ by itself would resist attack, an opponent might be able to exploit a
+ weakness in the implementation of RSAES-PKCS1-v1_5 to recover
+ messages encrypted with either scheme. As another example, suppose
+ an RSA key pair is employed in both RSASSA-PSS (Section 8.1) and
+ RSASSA-PKCS1-v1_5. Then the security proof for RSASSA-PSS would no
+ longer be sufficient since the proof does not account for the
+ possibility that signatures might be generated with a second scheme.
+ Similar considerations may apply if an RSA key pair is employed in
+ one of the schemes defined here and in a variant defined elsewhere.
+
+7. Encryption Schemes
+
+ For the purposes of this document, an encryption scheme consists of
+ an encryption operation and a decryption operation, where the
+ encryption operation produces a ciphertext from a message with a
+ recipient's RSA public key, and the decryption operation recovers the
+ message from the ciphertext with the recipient's corresponding RSA
+ private key.
+
+ An encryption scheme can be employed in a variety of applications. A
+ typical application is a key establishment protocol, where the
+ message contains key material to be delivered confidentially from one
+ party to another. For instance, PKCS #7 [RFC2315] employs such a
+ protocol to deliver a content-encryption key from a sender to a
+ recipient; the encryption schemes defined here would be suitable key-
+ encryption algorithms in that context.
+
+ Two encryption schemes are specified in this document: RSAES-OAEP and
+ RSAES-PKCS1-v1_5. RSAES-OAEP is REQUIRED to be supported for new
+ applications; RSAES-PKCS1-v1_5 is included only for compatibility
+ with existing applications.
+
+ The encryption schemes given here follow a general model similar to
+ that employed in IEEE 1363 [IEEE1363], combining encryption and
+ decryption primitives with an encoding method for encryption. The
+ encryption operations apply a message encoding operation to a message
+ to produce an encoded message, which is then converted to an integer
+ message representative. An encryption primitive is applied to the
+ message representative to produce the ciphertext. Reversing this,
+ the decryption operations apply a decryption primitive to the
+
+
+
+Moriarty, et al. Informational [Page 18]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+ ciphertext to recover a message representative, which is then
+ converted to an octet-string-encoded message. A message decoding
+ operation is applied to the encoded message to recover the message
+ and verify the correctness of the decryption.
+
+ To avoid implementation weaknesses related to the way errors are
+ handled within the decoding operation (see [BLEICHENBACHER] and
+ [MANGER]), the encoding and decoding operations for RSAES-OAEP and
+ RSAES-PKCS1-v1_5 are embedded in the specifications of the respective
+ encryption schemes rather than defined in separate specifications.
+ Both encryption schemes are compatible with the corresponding schemes
+ in PKCS #1 v2.1.
+
+7.1. RSAES-OAEP
+
+ RSAES-OAEP combines the RSAEP and RSADP primitives (Sections 5.1.1
+ and 5.1.2) with the EME-OAEP encoding method (Step 2 in
+ Section 7.1.1, and Step 3 in Section 7.1.2). EME-OAEP is based on
+ Bellare and Rogaway's Optimal Asymmetric Encryption scheme [OAEP].
+ It is compatible with the Integer Factorization Encryption Scheme
+ (IFES) defined in IEEE 1363 [IEEE1363], where the encryption and
+ decryption primitives are IFEP-RSA and IFDP-RSA and the message
+ encoding method is EME-OAEP. RSAES-OAEP can operate on messages of
+ length up to k - 2hLen -2 octets, where hLen is the length of the
+ output from the underlying hash function and k is the length in
+ octets of the recipient's RSA modulus.
+
+ Assuming that computing e-th roots modulo n is infeasible and the
+ mask generation function in RSAES-OAEP has appropriate properties,
+ RSAES-OAEP is semantically secure against adaptive chosen-ciphertext
+ attacks. This assurance is provable in the sense that the difficulty
+ of breaking RSAES-OAEP can be directly related to the difficulty of
+ inverting the RSA function, provided that the mask generation
+ function is viewed as a black box or random oracle; see [FOPS] and
+ the note below for further discussion.
+
+ Both the encryption and the decryption operations of RSAES-OAEP take
+ the value of a label L as input. In this version of PKCS #1, L is
+ the empty string; other uses of the label are outside the scope of
+ this document. See Appendix A.2.1 for the relevant ASN.1 syntax.
+
+ RSAES-OAEP is parameterized by the choice of hash function and mask
+ generation function. This choice should be fixed for a given RSA
+ key. Suggested hash and mask generation functions are given in
+ Appendix B.
+
+
+
+
+
+
+Moriarty, et al. Informational [Page 19]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+ Note: Past results have helpfully clarified the security properties
+ of the OAEP encoding method [OAEP] (roughly the procedure described
+ in Step 2 in Section 7.1.1). The background is as follows. In 1994,
+ Bellare and Rogaway [OAEP] introduced a security concept that they
+ denoted plaintext awareness (PA94). They proved that if a
+ deterministic public-key encryption primitive (e.g., RSAEP) is hard
+ to invert without the private key, then the corresponding OAEP-based
+ encryption scheme is plaintext aware (in the random oracle model),
+ meaning roughly that an adversary cannot produce a valid ciphertext
+ without actually "knowing" the underlying plaintext. Plaintext
+ awareness of an encryption scheme is closely related to the
+ resistance of the scheme against chosen-ciphertext attacks. In such
+ attacks, an adversary is given the opportunity to send queries to an
+ oracle simulating the decryption primitive. Using the results of
+ these queries, the adversary attempts to decrypt a challenge
+ ciphertext.
+
+ However, there are two flavors of chosen-ciphertext attacks, and PA94
+ implies security against only one of them. The difference relies on
+ what the adversary is allowed to do after she is given the challenge
+ ciphertext. The indifferent attack scenario (denoted CCA1) does not
+ admit any queries to the decryption oracle after the adversary is
+ given the challenge ciphertext, whereas the adaptive scenario
+ (denoted CCA2) does (except that the decryption oracle refuses to
+ decrypt the challenge ciphertext once it is published). In 1998,
+ Bellare and Rogaway, together with Desai and Pointcheval [PA98], came
+ up with a new, stronger notion of plaintext awareness (PA98) that
+ does imply security against CCA2.
+
+ To summarize, there have been two potential sources for
+ misconception: that PA94 and PA98 are equivalent concepts, or that
+ CCA1 and CCA2 are equivalent concepts. Either assumption leads to
+ the conclusion that the Bellare-Rogaway paper implies security of
+ OAEP against CCA2, which it does not.
+
+ (Footnote: It might be fair to mention that PKCS #1 v2.0 cites [OAEP]
+ and claims that "a chosen ciphertext attack is ineffective against a
+ plaintext-aware encryption scheme such as RSAES-OAEP" without
+ specifying the kind of plaintext awareness or chosen ciphertext
+ attack considered.)
+
+ OAEP has never been proven secure against CCA2; in fact, Victor Shoup
+ [SHOUP] has demonstrated that such a proof does not exist in the
+ general case. Put briefly, Shoup showed that an adversary in the
+ CCA2 scenario who knows how to partially invert the encryption
+ primitive but does not know how to invert it completely may well be
+ able to break the scheme. For example, one may imagine an attacker
+ who is able to break RSAES-OAEP if she knows how to recover all but
+
+
+
+Moriarty, et al. Informational [Page 20]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+ the first 20 bytes of a random integer encrypted with RSAEP. Such an
+ attacker does not need to be able to fully invert RSAEP, because she
+ does not use the first 20 octets in her attack.
+
+ Still, RSAES-OAEP is secure against CCA2, which was proved by
+ Fujisaki, Okamoto, Pointcheval, and Stern [FOPS] shortly after the
+ announcement of Shoup's result. Using clever lattice reduction
+ techniques, they managed to show how to invert RSAEP completely given
+ a sufficiently large part of the pre-image. This observation,
+ combined with a proof that OAEP is secure against CCA2 if the
+ underlying encryption primitive is hard to partially invert, fills
+ the gap between what Bellare and Rogaway proved about RSAES-OAEP and
+ what some may have believed that they proved. Somewhat
+ paradoxically, we are hence saved by an ostensible weakness in RSAEP
+ (i.e., the whole inverse can be deduced from parts of it).
+
+ Unfortunately, however, the security reduction is not efficient for
+ concrete parameters. While the proof successfully relates an
+ adversary A against the CCA2 security of RSAES-OAEP to an algorithm I
+ inverting RSA, the probability of success for I is only approximately
+ \epsilon^2 / 2^18, where \epsilon is the probability of success for
+ A.
+
+ (Footnote: In [FOPS], the probability of success for the inverter was
+ \epsilon^2 / 4. The additional factor 1 / 2^16 is due to the eight
+ fixed zero bits at the beginning of the encoded message EM, which are
+ not present in the variant of OAEP considered in [FOPS]. (A must be
+ applied twice to invert RSA, and each application corresponds to a
+ factor 1 / 2^8.))
+
+ In addition, the running time for I is approximately t^2, where t is
+ the running time of the adversary. The consequence is that we cannot
+ exclude the possibility that attacking RSAES-OAEP is considerably
+ easier than inverting RSA for concrete parameters. Still, the
+ existence of a security proof provides some assurance that the
+ RSAES-OAEP construction is sounder than ad hoc constructions such as
+ RSAES-PKCS1-v1_5.
+
+ Hybrid encryption schemes based on the RSA Key Encapsulation
+ Mechanism (RSA-KEM) paradigm offer tight proofs of security directly
+ applicable to concrete parameters; see [ISO18033] for discussion.
+ Future versions of PKCS #1 may specify schemes based on this
+ paradigm.
+
+
+
+
+
+
+
+
+Moriarty, et al. Informational [Page 21]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+7.1.1. Encryption Operation
+
+ RSAES-OAEP-ENCRYPT ((n, e), M, L)
+
+ Options:
+
+ Hash hash function (hLen denotes the length in octets of
+ the hash function output)
+ MGF mask generation function
+
+ Input:
+
+ (n, e) recipient's RSA public key (k denotes the length in
+ octets of the RSA modulus n)
+ M message to be encrypted, an octet string of length mLen,
+ where mLen <= k - 2hLen - 2
+ L optional label to be associated with the message; the
+ default value for L, if L is not provided, is the empty
+ string
+
+ Output:
+
+ C ciphertext, an octet string of length k
+
+ Errors: "message too long"; "label too long"
+
+ Assumption: RSA public key (n, e) is valid
+
+ Steps:
+
+ 1. Length checking:
+
+ a. If the length of L is greater than the input limitation
+ for the hash function (2^61 - 1 octets for SHA-1), output
+ "label too long" and stop.
+
+ b. If mLen > k - 2hLen - 2, output "message too long" and
+ stop.
+
+ 2. EME-OAEP encoding (see Figure 1 below):
+
+ a. If the label L is not provided, let L be the empty string.
+ Let lHash = Hash(L), an octet string of length hLen (see
+ the note below).
+
+ b. Generate a padding string PS consisting of k - mLen -
+ 2hLen - 2 zero octets. The length of PS may be zero.
+
+
+
+
+Moriarty, et al. Informational [Page 22]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+ c. Concatenate lHash, PS, a single octet with hexadecimal
+ value 0x01, and the message M to form a data block DB of
+ length k - hLen - 1 octets as
+
+ DB = lHash || PS || 0x01 || M.
+
+ d. Generate a random octet string seed of length hLen.
+
+ e. Let dbMask = MGF(seed, k - hLen - 1).
+
+ f. Let maskedDB = DB \xor dbMask.
+
+ g. Let seedMask = MGF(maskedDB, hLen).
+
+ h. Let maskedSeed = seed \xor seedMask.
+
+ i. Concatenate a single octet with hexadecimal value 0x00,
+ maskedSeed, and maskedDB to form an encoded message EM of
+ length k octets as
+
+ EM = 0x00 || maskedSeed || maskedDB.
+
+ 3. RSA encryption:
+
+ a. Convert the encoded message EM to an integer message
+ representative m (see Section 4.2):
+
+ m = OS2IP (EM).
+
+ b. Apply the RSAEP encryption primitive (Section 5.1.1) to
+ the RSA public key (n, e) and the message representative m
+ to produce an integer ciphertext representative c:
+
+ c = RSAEP ((n, e), m).
+
+ c. Convert the ciphertext representative c to a ciphertext C
+ of length k octets (see Section 4.1):
+
+ C = I2OSP (c, k).
+
+
+
+
+
+
+
+
+
+
+
+
+Moriarty, et al. Informational [Page 23]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+ 4. Output the ciphertext C.
+
+ _________________________________________________________________
+
+ +----------+------+--+-------+
+ DB = | lHash | PS |01| M |
+ +----------+------+--+-------+
+ |
+ +----------+ |
+ | seed | |
+ +----------+ |
+ | |
+ |-------> MGF ---> xor
+ | |
+ +--+ V |
+ |00| xor <----- MGF <-----|
+ +--+ | |
+ | | |
+ V V V
+ +--+----------+----------------------------+
+ EM = |00|maskedSeed| maskedDB |
+ +--+----------+----------------------------+
+ _________________________________________________________________
+
+ Figure 1: EME-OAEP Encoding Operation
+
+ Notes:
+
+ - lHash is the hash of the optional label L.
+
+ - The decoding operation follows reverse steps to recover M and
+ verify lHash and PS.
+
+ - If L is the empty string, the corresponding hash value lHash has
+ the following hexadecimal representation for different choices of
+ Hash:
+
+ SHA-1: (0x)da39a3ee 5e6b4b0d 3255bfef 95601890 afd80709
+ SHA-256: (0x)e3b0c442 98fc1c14 9afbf4c8 996fb924 27ae41e4 649b934c
+ a495991b 7852b855
+ SHA-384: (0x)38b060a7 51ac9638 4cd9327e b1b1e36a 21fdb711 14be0743
+ 4c0cc7bf 63f6e1da 274edebf e76f65fb d51ad2f1 4898b95b
+ SHA-512: (0x)cf83e135 7eefb8bd f1542850 d66d8007 d620e405 0b5715dc
+ 83f4a921 d36ce9ce 47d0d13c 5d85f2b0 ff8318d2 877eec2f
+ 63b931bd 47417a81 a538327a f927da3e
+
+
+
+
+
+
+Moriarty, et al. Informational [Page 24]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+7.1.2. Decryption Operation
+
+ RSAES-OAEP-DECRYPT (K, C, L)
+
+ Options:
+
+ Hash hash function (hLen denotes the length in octets of
+ the hash function output)
+ MGF mask generation function
+
+ Input:
+
+ K recipient's RSA private key (k denotes the length in
+ octets of the RSA modulus n), where k >= 2hLen + 2
+ C ciphertext to be decrypted, an octet string of length k
+ L optional label whose association with the message is to
+ be verified; the default value for L, if L is not
+ provided, is the empty string
+
+ Output:
+
+ M message, an octet string of length mLen, where
+ mLen <= k - 2hLen - 2
+
+ Error: "decryption error"
+
+ Steps:
+
+ 1. Length checking:
+
+ a. If the length of L is greater than the input limitation
+ for the hash function (2^61 - 1 octets for SHA-1), output
+ "decryption error" and stop.
+
+ b. If the length of the ciphertext C is not k octets, output
+ "decryption error" and stop.
+
+ c. If k < 2hLen + 2, output "decryption error" and stop.
+
+ 2. RSA decryption:
+
+ a. Convert the ciphertext C to an integer ciphertext
+ representative c (see Section 4.2):
+
+ c = OS2IP (C).
+
+
+
+
+
+
+Moriarty, et al. Informational [Page 25]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+ b. Apply the RSADP decryption primitive (Section 5.1.2) to
+ the RSA private key K and the ciphertext representative c
+ to produce an integer message representative m:
+
+ m = RSADP (K, c).
+
+ If RSADP outputs "ciphertext representative out of range"
+ (meaning that c >= n), output "decryption error" and stop.
+
+ c. Convert the message representative m to an encoded message
+ EM of length k octets (see Section 4.1):
+
+ EM = I2OSP (m, k).
+
+ 3. EME-OAEP decoding:
+
+ a. If the label L is not provided, let L be the empty string.
+ Let lHash = Hash(L), an octet string of length hLen (see
+ the note in Section 7.1.1).
+
+ b. Separate the encoded message EM into a single octet Y, an
+ octet string maskedSeed of length hLen, and an octet
+ string maskedDB of length k - hLen - 1 as
+
+ EM = Y || maskedSeed || maskedDB.
+
+ c. Let seedMask = MGF(maskedDB, hLen).
+
+ d. Let seed = maskedSeed \xor seedMask.
+
+ e. Let dbMask = MGF(seed, k - hLen - 1).
+
+ f. Let DB = maskedDB \xor dbMask.
+
+ g. Separate DB into an octet string lHash' of length hLen, a
+ (possibly empty) padding string PS consisting of octets
+ with hexadecimal value 0x00, and a message M as
+
+ DB = lHash' || PS || 0x01 || M.
+
+ If there is no octet with hexadecimal value 0x01 to
+ separate PS from M, if lHash does not equal lHash', or if
+ Y is nonzero, output "decryption error" and stop. (See
+ the note below.)
+
+
+
+
+
+
+
+Moriarty, et al. Informational [Page 26]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+ 4. Output the message M.
+
+ Note: Care must be taken to ensure that an opponent cannot
+ distinguish the different error conditions in Step 3.g, whether by
+ error message or timing, and, more generally, that an opponent
+ cannot learn partial information about the encoded message EM.
+ Otherwise, an opponent may be able to obtain useful information
+ about the decryption of the ciphertext C, leading to a chosen-
+ ciphertext attack such as the one observed by Manger [MANGER].
+
+7.2. RSAES-PKCS1-v1_5
+
+ RSAES-PKCS1-v1_5 combines the RSAEP and RSADP primitives (Sections
+ 5.1.1 and 5.1.2) with the EME-PKCS1-v1_5 encoding method (Step 2 in
+ Section 7.2.1, and Step 3 in Section 7.2.2). It is mathematically
+ equivalent to the encryption scheme in PKCS #1 v1.5.
+ RSAES-PKCS1-v1_5 can operate on messages of length up to k - 11
+ octets (k is the octet length of the RSA modulus), although care
+ should be taken to avoid certain attacks on low-exponent RSA due to
+ Coppersmith, Franklin, Patarin, and Reiter when long messages are
+ encrypted (see the third bullet in the notes below and [LOWEXP];
+ [NEWATTACK] contains an improved attack). As a general rule, the use
+ of this scheme for encrypting an arbitrary message, as opposed to a
+ randomly generated key, is NOT RECOMMENDED.
+
+ It is possible to generate valid RSAES-PKCS1-v1_5 ciphertexts without
+ knowing the corresponding plaintexts, with a reasonable probability
+ of success. This ability can be exploited in a chosen-ciphertext
+ attack as shown in [BLEICHENBACHER]. Therefore, if RSAES-PKCS1-v1_5
+ is to be used, certain easily implemented countermeasures should be
+ taken to thwart the attack found in [BLEICHENBACHER]. Typical
+ examples include the addition of structure to the data to be encoded,
+ rigorous checking of PKCS #1 v1.5 conformance (and other redundancy)
+ in decrypted messages, and the consolidation of error messages in a
+ client-server protocol based on PKCS #1 v1.5. These can all be
+ effective countermeasures and do not involve changes to a protocol
+ based on PKCS #1 v1.5. See [BKS] for a further discussion of these
+ and other countermeasures. It has recently been shown that the
+ security of the SSL/TLS handshake protocol [RFC5246], which uses
+ RSAES-PKCS1-v1_5 and certain countermeasures, can be related to a
+ variant of the RSA problem; see [RSATLS] for discussion.
+
+ Note: The following passages describe some security recommendations
+ pertaining to the use of RSAES-PKCS1-v1_5. Recommendations from PKCS
+ #1 v1.5 are included as well as new recommendations motivated by
+ cryptanalytic advances made in the intervening years.
+
+
+
+
+
+Moriarty, et al. Informational [Page 27]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+ o It is RECOMMENDED that the pseudorandom octets in Step 2 in
+ Section 7.2.1 be generated independently for each encryption
+ process, especially if the same data is input to more than one
+ encryption process. Haastad's results [HAASTAD] are one
+ motivation for this recommendation.
+
+ o The padding string PS in Step 2 in Section 7.2.1 is at least eight
+ octets long, which is a security condition for public-key
+ operations that makes it difficult for an attacker to recover data
+ by trying all possible encryption blocks.
+
+ o The pseudorandom octets can also help thwart an attack due to
+ Coppersmith et al. [LOWEXP] (see [NEWATTACK] for an improvement
+ of the attack) when the size of the message to be encrypted is
+ kept small. The attack works on low-exponent RSA when similar
+ messages are encrypted with the same RSA public key. More
+ specifically, in one flavor of the attack, when two inputs to
+ RSAEP agree on a large fraction of bits (8/9) and low-exponent RSA
+ (e = 3) is used to encrypt both of them, it may be possible to
+ recover both inputs with the attack. Another flavor of the attack
+ is successful in decrypting a single ciphertext when a large
+ fraction (2/3) of the input to RSAEP is already known. For
+ typical applications, the message to be encrypted is short (e.g.,
+ a 128-bit symmetric key), so not enough information will be known
+ or common between two messages to enable the attack. However, if
+ a long message is encrypted, or if part of a message is known,
+ then the attack may be a concern. In any case, the RSAES-OAEP
+ scheme overcomes the attack.
+
+7.2.1. Encryption Operation
+
+ RSAES-PKCS1-V1_5-ENCRYPT ((n, e), M)
+
+ Input:
+
+ (n, e) recipient's RSA public key (k denotes the length in
+ octets of the modulus n)
+ M message to be encrypted, an octet string of length
+ mLen, where mLen <= k - 11
+
+ Output:
+
+ C ciphertext, an octet string of length k
+
+ Error: "message too long"
+
+
+
+
+
+
+Moriarty, et al. Informational [Page 28]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+ Steps:
+
+ 1. Length checking: If mLen > k - 11, output "message too long"
+ and stop.
+
+ 2. EME-PKCS1-v1_5 encoding:
+
+ a. Generate an octet string PS of length k - mLen - 3
+ consisting of pseudo-randomly generated nonzero octets.
+ The length of PS will be at least eight octets.
+
+ b. Concatenate PS, the message M, and other padding to form
+ an encoded message EM of length k octets as
+
+ EM = 0x00 || 0x02 || PS || 0x00 || M.
+
+ 3. RSA encryption:
+
+ a. Convert the encoded message EM to an integer message
+ representative m (see Section 4.2):
+
+ m = OS2IP (EM).
+
+ b. Apply the RSAEP encryption primitive (Section 5.1.1) to
+ the RSA public key (n, e) and the message representative m
+ to produce an integer ciphertext representative c:
+
+ c = RSAEP ((n, e), m).
+
+ c. Convert the ciphertext representative c to a ciphertext C
+ of length k octets (see Section 4.1):
+
+ C = I2OSP (c, k).
+
+ 4. Output the ciphertext C.
+
+7.2.2. Decryption Operation
+
+ RSAES-PKCS1-V1_5-DECRYPT (K, C)
+
+ Input:
+
+ K recipient's RSA private key
+ C ciphertext to be decrypted, an octet string of length k,
+ where k is the length in octets of the RSA modulus n
+
+
+
+
+
+
+Moriarty, et al. Informational [Page 29]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+ Output:
+
+ M message, an octet string of length at most k - 11
+
+ Error: "decryption error"
+
+ Steps:
+
+ 1. Length checking: If the length of the ciphertext C is not k
+ octets (or if k < 11), output "decryption error" and stop.
+
+ 2. RSA decryption:
+
+ a. Convert the ciphertext C to an integer ciphertext
+ representative c (see Section 4.2):
+
+ c = OS2IP (C).
+
+ b. Apply the RSADP decryption primitive (Section 5.1.2) to
+ the RSA private key (n, d) and the ciphertext
+ representative c to produce an integer message
+ representative m:
+
+ m = RSADP ((n, d), c).
+
+ If RSADP outputs "ciphertext representative out of range"
+ (meaning that c >= n), output "decryption error" and stop.
+
+ c. Convert the message representative m to an encoded message
+ EM of length k octets (see Section 4.1):
+
+ EM = I2OSP (m, k).
+
+ 3. EME-PKCS1-v1_5 decoding: Separate the encoded message EM into
+ an octet string PS consisting of nonzero octets and a message
+ M as
+
+ EM = 0x00 || 0x02 || PS || 0x00 || M.
+
+ If the first octet of EM does not have hexadecimal value 0x00,
+ if the second octet of EM does not have hexadecimal value
+ 0x02, if there is no octet with hexadecimal value 0x00 to
+ separate PS from M, or if the length of PS is less than 8
+ octets, output "decryption error" and stop. (See the note
+ below.)
+
+ 4. Output M.
+
+
+
+
+Moriarty, et al. Informational [Page 30]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+ Note: Care shall be taken to ensure that an opponent cannot
+ distinguish the different error conditions in Step 3, whether by
+ error message or timing. Otherwise, an opponent may be able to
+ obtain useful information about the decryption of the ciphertext
+ C, leading to a strengthened version of Bleichenbacher's attack
+ [BLEICHENBACHER]; compare to Manger's attack [MANGER].
+
+8. Signature Scheme with Appendix
+
+ For the purposes of this document, a signature scheme with appendix
+ consists of a signature generation operation and a signature
+ verification operation, where the signature generation operation
+ produces a signature from a message with a signer's RSA private key,
+ and the signature verification operation verifies the signature on
+ the message with the signer's corresponding RSA public key. To
+ verify a signature constructed with this type of scheme, it is
+ necessary to have the message itself. In this way, signature schemes
+ with appendix are distinguished from signature schemes with message
+ recovery, which are not supported in this document.
+
+ A signature scheme with appendix can be employed in a variety of
+ applications. For instance, the signature schemes with appendix
+ defined here would be suitable signature algorithms for X.509
+ certificates [ISO9594]. Related signature schemes could be employed
+ in PKCS #7 [RFC2315], although for technical reasons the current
+ version of PKCS #7 separates a hash function from a signature scheme,
+ which is different than what is done here; see the note in
+ Appendix A.2.3 for more discussion.
+
+ Two signature schemes with appendix are specified in this document:
+ RSASSA-PSS and RSASSA-PKCS1-v1_5. Although no attacks are known
+ against RSASSA-PKCS1-v1_5, in the interest of increased robustness,
+ RSASSA-PSS is REQUIRED in new applications. RSASSA-PKCS1-v1_5 is
+ included only for compatibility with existing applications.
+
+ The signature schemes with appendix given here follow a general model
+ similar to that employed in IEEE 1363 [IEEE1363], combining signature
+ and verification primitives with an encoding method for signatures.
+ The signature generation operations apply a message encoding
+ operation to a message to produce an encoded message, which is then
+ converted to an integer message representative. A signature
+ primitive is applied to the message representative to produce the
+ signature. Reversing this, the signature verification operations
+ apply a signature verification primitive to the signature to recover
+ a message representative, which is then converted to an octet-string-
+ encoded message. A verification operation is applied to the message
+ and the encoded message to determine whether they are consistent.
+
+
+
+
+Moriarty, et al. Informational [Page 31]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+ If the encoding method is deterministic (e.g., EMSA-PKCS1-v1_5), the
+ verification operation may apply the message encoding operation to
+ the message and compare the resulting encoded message to the
+ previously derived encoded message. If there is a match, the
+ signature is considered valid. If the method is randomized (e.g.,
+ EMSA-PSS), the verification operation is typically more complicated.
+ For example, the verification operation in EMSA-PSS extracts the
+ random salt and a hash output from the encoded message and checks
+ whether the hash output, the salt, and the message are consistent;
+ the hash output is a deterministic function in terms of the message
+ and the salt. For both signature schemes with appendix defined in
+ this document, the signature generation and signature verification
+ operations are readily implemented as "single-pass" operations if the
+ signature is placed after the message. See PKCS #7 [RFC2315] for an
+ example format in the case of RSASSA-PKCS1-v1_5.
+
+8.1. RSASSA-PSS
+
+ RSASSA-PSS combines the RSASP1 and RSAVP1 primitives with the
+ EMSA-PSS encoding method. It is compatible with the Integer
+ Factorization Signature Scheme with Appendix (IFSSA) as amended in
+ IEEE 1363a [IEEE1363A], where the signature and verification
+ primitives are IFSP-RSA1 and IFVP-RSA1 as defined in IEEE 1363
+ [IEEE1363], and the message encoding method is EMSA4. EMSA4 is
+ slightly more general than EMSA-PSS as it acts on bit strings rather
+ than on octet strings. EMSA-PSS is equivalent to EMSA4 restricted to
+ the case that the operands as well as the hash and salt values are
+ octet strings.
+
+ The length of messages on which RSASSA-PSS can operate is either
+ unrestricted or constrained by a very large number, depending on the
+ hash function underlying the EMSA-PSS encoding method.
+
+ Assuming that computing e-th roots modulo n is infeasible and the
+ hash and mask generation functions in EMSA-PSS have appropriate
+ properties, RSASSA-PSS provides secure signatures. This assurance is
+ provable in the sense that the difficulty of forging signatures can
+ be directly related to the difficulty of inverting the RSA function,
+ provided that the hash and mask generation functions are viewed as
+ black boxes or random oracles. The bounds in the security proof are
+ essentially "tight", meaning that the success probability and running
+ time for the best forger against RSASSA-PSS are very close to the
+ corresponding parameters for the best RSA inversion algorithm; see
+ [RSARABIN] [PSSPROOF] [JONSSON] for further discussion.
+
+ In contrast to the RSASSA-PKCS1-v1_5 signature scheme, a hash
+ function identifier is not embedded in the EMSA-PSS encoded message,
+ so in theory it is possible for an adversary to substitute a
+
+
+
+Moriarty, et al. Informational [Page 32]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+ different (and potentially weaker) hash function than the one
+ selected by the signer. Therefore, it is RECOMMENDED that the
+ EMSA-PSS mask generation function be based on the same hash function.
+ In this manner, the entire encoded message will be dependent on the
+ hash function, and it will be difficult for an opponent to substitute
+ a different hash function than the one intended by the signer. This
+ matching of hash functions is only for the purpose of preventing hash
+ function substitution and is not necessary if hash function
+ substitution is addressed by other means (e.g., the verifier accepts
+ only a designated hash function). See [HASHID] for further
+ discussion of these points. The provable security of RSASSA-PSS does
+ not rely on the hash function in the mask generation function being
+ the same as the hash function applied to the message.
+
+ RSASSA-PSS is different from other RSA-based signature schemes in
+ that it is probabilistic rather than deterministic, incorporating a
+ randomly generated salt value. The salt value enhances the security
+ of the scheme by affording a "tighter" security proof than
+ deterministic alternatives such as Full Domain Hashing (FDH); see
+ [RSARABIN] for discussion. However, the randomness is not critical
+ to security. In situations where random generation is not possible,
+ a fixed value or a sequence number could be employed instead, with
+ the resulting provable security similar to that of FDH [FDH].
+
+8.1.1. Signature Generation Operation
+
+ RSASSA-PSS-SIGN (K, M)
+
+ Input:
+
+ K signer's RSA private key
+ M message to be signed, an octet string
+
+ Output:
+
+ S signature, an octet string of length k, where k is the
+ length in octets of the RSA modulus n
+
+ Errors: "message too long;" "encoding error"
+
+ Steps:
+
+ 1. EMSA-PSS encoding: Apply the EMSA-PSS encoding operation
+ (Section 9.1.1) to the message M to produce an encoded message
+ EM of length \ceil ((modBits - 1)/8) octets such that the bit
+ length of the integer OS2IP (EM) (see Section 4.2) is at most
+ modBits - 1, where modBits is the length in bits of the RSA
+ modulus n:
+
+
+
+Moriarty, et al. Informational [Page 33]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+ EM = EMSA-PSS-ENCODE (M, modBits - 1).
+
+ Note that the octet length of EM will be one less than k if
+ modBits - 1 is divisible by 8 and equal to k otherwise. If
+ the encoding operation outputs "message too long", output
+ "message too long" and stop. If the encoding operation
+ outputs "encoding error", output "encoding error" and stop.
+
+ 2. RSA signature:
+
+ a. Convert the encoded message EM to an integer message
+ representative m (see Section 4.2):
+
+ m = OS2IP (EM).
+
+ b. Apply the RSASP1 signature primitive (Section 5.2.1) to
+ the RSA private key K and the message representative m to
+ produce an integer signature representative s:
+
+ s = RSASP1 (K, m).
+
+ c. Convert the signature representative s to a signature S of
+ length k octets (see Section 4.1):
+
+ S = I2OSP (s, k).
+
+ 3. Output the signature S.
+
+8.1.2. Signature Verification Operation
+
+ RSASSA-PSS-VERIFY ((n, e), M, S)
+
+ Input:
+
+ (n, e) signer's RSA public key
+ M message whose signature is to be verified, an octet string
+ S signature to be verified, an octet string of length k,
+ where k is the length in octets of the RSA modulus n
+
+ Output: "valid signature" or "invalid signature"
+
+ Steps:
+
+ 1. Length checking: If the length of the signature S is not k
+ octets, output "invalid signature" and stop.
+
+
+
+
+
+
+Moriarty, et al. Informational [Page 34]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+ 2. RSA verification:
+
+ a. Convert the signature S to an integer signature
+ representative s (see Section 4.2):
+
+ s = OS2IP (S).
+
+ b. Apply the RSAVP1 verification primitive (Section 5.2.2) to
+ the RSA public key (n, e) and the signature representative
+ s to produce an integer message representative m:
+
+ m = RSAVP1 ((n, e), s).
+
+ If RSAVP1 output "signature representative out of range",
+ output "invalid signature" and stop.
+
+ c. Convert the message representative m to an encoded message
+ EM of length emLen = \ceil ((modBits - 1)/8) octets, where
+ modBits is the length in bits of the RSA modulus n (see
+ Section 4.1):
+
+ EM = I2OSP (m, emLen).
+
+ Note that emLen will be one less than k if modBits - 1 is
+ divisible by 8 and equal to k otherwise. If I2OSP outputs
+ "integer too large", output "invalid signature" and stop.
+
+ 3. EMSA-PSS verification: Apply the EMSA-PSS verification
+ operation (Section 9.1.2) to the message M and the encoded
+ message EM to determine whether they are consistent:
+
+ Result = EMSA-PSS-VERIFY (M, EM, modBits - 1).
+
+ 4. If Result = "consistent", output "valid signature".
+ Otherwise, output "invalid signature".
+
+8.2. RSASSA-PKCS1-v1_5
+
+ RSASSA-PKCS1-v1_5 combines the RSASP1 and RSAVP1 primitives with the
+ EMSA-PKCS1-v1_5 encoding method. It is compatible with the IFSSA
+ scheme defined in IEEE 1363 [IEEE1363], where the signature and
+ verification primitives are IFSP-RSA1 and IFVP-RSA1, and the message
+ encoding method is EMSA-PKCS1-v1_5 (which is not defined in IEEE 1363
+ but is in IEEE 1363a [IEEE1363A]).
+
+ The length of messages on which RSASSA-PKCS1-v1_5 can operate is
+ either unrestricted or constrained by a very large number, depending
+ on the hash function underlying the EMSA-PKCS1-v1_5 method.
+
+
+
+Moriarty, et al. Informational [Page 35]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+ Assuming that computing e-th roots modulo n is infeasible and the
+ hash function in EMSA-PKCS1-v1_5 has appropriate properties,
+ RSASSA-PKCS1-v1_5 is conjectured to provide secure signatures. More
+ precisely, forging signatures without knowing the RSA private key is
+ conjectured to be computationally infeasible. Also, in the encoding
+ method EMSA-PKCS1-v1_5, a hash function identifier is embedded in the
+ encoding. Because of this feature, an adversary trying to find a
+ message with the same signature as a previously signed message must
+ find collisions of the particular hash function being used; attacking
+ a different hash function than the one selected by the signer is not
+ useful to the adversary. See [HASHID] for further discussion.
+
+ Note: As noted in PKCS #1 v1.5, the EMSA-PKCS1-v1_5 encoding method
+ has the property that the encoded message, converted to an integer
+ message representative, is guaranteed to be large and at least
+ somewhat "random". This prevents attacks of the kind proposed by
+ Desmedt and Odlyzko [CHOSEN] where multiplicative relationships
+ between message representatives are developed by factoring the
+ message representatives into a set of small values (e.g., a set of
+ small primes). Coron, Naccache, and Stern [PADDING] showed that a
+ stronger form of this type of attack could be quite effective against
+ some instances of the ISO/IEC 9796-2 signature scheme. They also
+ analyzed the complexity of this type of attack against the
+ EMSA-PKCS1-v1_5 encoding method and concluded that an attack would be
+ impractical, requiring more operations than a collision search on the
+ underlying hash function (i.e., more than 2^80 operations).
+ Coppersmith, Halevi, and Jutla [FORGERY] subsequently extended Coron
+ et al.'s attack to break the ISO/IEC 9796-1 signature scheme with
+ message recovery. The various attacks illustrate the importance of
+ carefully constructing the input to the RSA signature primitive,
+ particularly in a signature scheme with message recovery.
+ Accordingly, the EMSA-PKCS-v1_5 encoding method explicitly includes a
+ hash operation and is not intended for signature schemes with message
+ recovery. Moreover, while no attack is known against the
+ EMSA-PKCS-v1_5 encoding method, a gradual transition to EMSA-PSS is
+ recommended as a precaution against future developments.
+
+8.2.1. Signature Generation Operation
+
+ RSASSA-PKCS1-V1_5-SIGN (K, M)
+
+ Input:
+
+ K signer's RSA private key
+ M message to be signed, an octet string
+
+
+
+
+
+
+Moriarty, et al. Informational [Page 36]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+ Output:
+
+ S signature, an octet string of length k, where k is the
+ length in octets of the RSA modulus n
+
+ Errors: "message too long"; "RSA modulus too short"
+
+ Steps:
+
+ 1. EMSA-PKCS1-v1_5 encoding: Apply the EMSA-PKCS1-v1_5 encoding
+ operation (Section 9.2) to the message M to produce an encoded
+ message EM of length k octets:
+
+ EM = EMSA-PKCS1-V1_5-ENCODE (M, k).
+
+ If the encoding operation outputs "message too long", output
+ "message too long" and stop. If the encoding operation
+ outputs "intended encoded message length too short", output
+ "RSA modulus too short" and stop.
+
+ 2. RSA signature:
+
+ a. Convert the encoded message EM to an integer message
+ representative m (see Section 4.2):
+
+ m = OS2IP (EM).
+
+ b. Apply the RSASP1 signature primitive (Section 5.2.1) to
+ the RSA private key K and the message representative m to
+ produce an integer signature representative s:
+
+ s = RSASP1 (K, m).
+
+ c. Convert the signature representative s to a signature S of
+ length k octets (see Section 4.1):
+
+ S = I2OSP (s, k).
+
+ 3. Output the signature S.
+
+8.2.2. Signature Verification Operation
+
+ RSASSA-PKCS1-V1_5-VERIFY ((n, e), M, S)
+
+ Input:
+
+ (n, e) signer's RSA public key
+ M message whose signature is to be verified, an octet string
+
+
+
+Moriarty, et al. Informational [Page 37]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+ S signature to be verified, an octet string of length k,
+ where k is the length in octets of the RSA modulus n
+
+ Output "valid signature" or "invalid signature"
+
+ Errors: "message too long"; "RSA modulus too short"
+
+ Steps:
+
+ 1. Length checking: If the length of the signature S is not k
+ octets, output "invalid signature" and stop.
+
+ 2. RSA verification:
+
+ a. Convert the signature S to an integer signature
+ representative s (see Section 4.2):
+
+ s = OS2IP (S).
+
+ b. Apply the RSAVP1 verification primitive (Section 5.2.2) to
+ the RSA public key (n, e) and the signature representative
+ s to produce an integer message representative m:
+
+ m = RSAVP1 ((n, e), s).
+
+ If RSAVP1 outputs "signature representative out of range",
+ output "invalid signature" and stop.
+
+ c. Convert the message representative m to an encoded message
+ EM of length k octets (see Section 4.1):
+
+ EM = I2OSP (m, k).
+
+ If I2OSP outputs "integer too large", output "invalid
+ signature" and stop.
+
+ 3. EMSA-PKCS1-v1_5 encoding: Apply the EMSA-PKCS1-v1_5 encoding
+ operation (Section 9.2) to the message M to produce a second
+ encoded message EM' of length k octets:
+
+ EM' = EMSA-PKCS1-V1_5-ENCODE (M, k).
+
+ If the encoding operation outputs "message too long", output
+ "message too long" and stop. If the encoding operation
+ outputs "intended encoded message length too short", output
+ "RSA modulus too short" and stop.
+
+
+
+
+
+Moriarty, et al. Informational [Page 38]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+ 4. Compare the encoded message EM and the second encoded message
+ EM'. If they are the same, output "valid signature";
+ otherwise, output "invalid signature".
+
+ Note: Another way to implement the signature verification
+ operation is to apply a "decoding" operation (not specified in
+ this document) to the encoded message to recover the underlying
+ hash value, and then compare it to a newly computed hash value.
+ This has the advantage that it requires less intermediate storage
+ (two hash values rather than two encoded messages), but the
+ disadvantage that it requires additional code.
+
+9. Encoding Methods for Signatures with Appendix
+
+ Encoding methods consist of operations that map between octet string
+ messages and octet-string-encoded messages, which are converted to
+ and from integer message representatives in the schemes. The integer
+ message representatives are processed via the primitives. The
+ encoding methods thus provide the connection between the schemes,
+ which process messages, and the primitives.
+
+ An encoding method for signatures with appendix, for the purposes of
+ this document, consists of an encoding operation and optionally a
+ verification operation. An encoding operation maps a message M to an
+ encoded message EM of a specified length. A verification operation
+ determines whether a message M and an encoded message EM are
+ consistent, i.e., whether the encoded message EM is a valid encoding
+ of the message M.
+
+ The encoding operation may introduce some randomness, so that
+ different applications of the encoding operation to the same message
+ will produce different encoded messages, which has benefits for
+ provable security. For such an encoding method, both an encoding and
+ a verification operation are needed unless the verifier can reproduce
+ the randomness (e.g., by obtaining the salt value from the signer).
+ For a deterministic encoding method, only an encoding operation is
+ needed.
+
+ Two encoding methods for signatures with appendix are employed in the
+ signature schemes and are specified here: EMSA-PSS and
+ EMSA-PKCS1-v1_5.
+
+
+
+
+
+
+
+
+
+
+Moriarty, et al. Informational [Page 39]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+9.1. EMSA-PSS
+
+ This encoding method is parameterized by the choice of hash function,
+ mask generation function, and salt length. These options should be
+ fixed for a given RSA key, except that the salt length can be
+ variable (see [JONSSON] for discussion). Suggested hash and mask
+ generation functions are given in Appendix B. The encoding method is
+ based on Bellare and Rogaway's Probabilistic Signature Scheme (PSS)
+ [RSARABIN][PSS]. It is randomized and has an encoding operation and
+ a verification operation.
+
+ Figure 2 illustrates the encoding operation.
+
+ __________________________________________________________________
+
+ +-----------+
+ | M |
+ +-----------+
+ |
+ V
+ Hash
+ |
+ V
+ +--------+----------+----------+
+ M' = |Padding1| mHash | salt |
+ +--------+----------+----------+
+ |
+ +--------+----------+ V
+ DB = |Padding2| salt | Hash
+ +--------+----------+ |
+ | |
+ V |
+ xor <--- MGF <---|
+ | |
+ | |
+ V V
+ +-------------------+----------+--+
+ EM = | maskedDB | H |bc|
+ +-------------------+----------+--+
+ __________________________________________________________________
+
+ Figure 2: EMSA-PSS Encoding Operation
+
+ Note that the verification operation follows reverse steps to recover
+ salt and then forward steps to recompute and compare H.
+
+
+
+
+
+
+Moriarty, et al. Informational [Page 40]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+ Notes:
+
+ 1. The encoding method defined here differs from the one in Bellare
+ and Rogaway's submission to IEEE 1363a [PSS] in three respects:
+
+ * It applies a hash function rather than a mask generation
+ function to the message. Even though the mask generation
+ function is based on a hash function, it seems more natural to
+ apply a hash function directly.
+
+ * The value that is hashed together with the salt value is the
+ string (0x)00 00 00 00 00 00 00 00 || mHash rather than the
+ message M itself. Here, mHash is the hash of M. Note that
+ the hash function is the same in both steps. See Note 3 below
+ for further discussion. (Also, the name "salt" is used
+ instead of "seed", as it is more reflective of the value's
+ role.)
+
+ * The encoded message in EMSA-PSS has nine fixed bits; the first
+ bit is 0 and the last eight bits form a "trailer field", the
+ octet 0xbc. In the original scheme, only the first bit is
+ fixed. The rationale for the trailer field is for
+ compatibility with the Integer Factorization Signature
+ Primitive using Rabin-Williams (IFSP-RW) in IEEE 1363
+ [IEEE1363] and the corresponding primitive in ISO/IEC
+ 9796-2:2010 [ISO9796].
+
+ 2. Assuming that the mask generation function is based on a hash
+ function, it is RECOMMENDED that the hash function be the same as
+ the one that is applied to the message; see Section 8.1 for
+ further discussion.
+
+ 3. Without compromising the security proof for RSASSA-PSS, one may
+ perform Steps 1 and 2 of EMSA-PSS-ENCODE and EMSA-PSS-VERIFY (the
+ application of the hash function to the message) outside the
+ module that computes the rest of the signature operation, so that
+ mHash rather than the message M itself is input to the module.
+ In other words, the security proof for RSASSA-PSS still holds
+ even if an opponent can control the value of mHash. This is
+ convenient if the module has limited I/O bandwidth, e.g., a smart
+ card. Note that previous versions of PSS [RSARABIN][PSS] did not
+ have this property. Of course, it may be desirable for other
+ security reasons to have the module process the full message.
+ For instance, the module may need to "see" what it is signing if
+ it does not trust the component that computes the hash value.
+
+
+
+
+
+
+Moriarty, et al. Informational [Page 41]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+ 4. Typical salt lengths in octets are hLen (the length of the output
+ of the hash function Hash) and 0. In both cases, the security of
+ RSASSA-PSS can be closely related to the hardness of inverting
+ RSAVP1. Bellare and Rogaway [RSARABIN] give a tight lower bound
+ for the security of the original RSA-PSS scheme, which
+ corresponds roughly to the former case, while Coron [FDH] gives a
+ lower bound for the related Full Domain Hashing scheme, which
+ corresponds roughly to the latter case. In [PSSPROOF], Coron
+ provides a general treatment with various salt lengths ranging
+ from 0 to hLen; see [IEEE1363A] for discussion. See also
+ [JONSSON], which adapts the security proofs in [RSARABIN]
+ [PSSPROOF] to address the differences between the original and
+ the present version of RSA-PSS as listed in Note 1 above.
+
+ 5. As noted in IEEE 1363a [IEEE1363A], the use of randomization in
+ signature schemes -- such as the salt value in EMSA-PSS -- may
+ provide a "covert channel" for transmitting information other
+ than the message being signed. For more on covert channels, see
+ [SIMMONS].
+
+9.1.1. Encoding Operation
+
+ EMSA-PSS-ENCODE (M, emBits)
+
+ Options:
+
+ Hash hash function (hLen denotes the length in octets of
+ the hash function output)
+ MGF mask generation function
+ sLen intended length in octets of the salt
+
+ Input:
+
+ M message to be encoded, an octet string
+ emBits maximal bit length of the integer OS2IP (EM) (see Section
+ 4.2), at least 8hLen + 8sLen + 9
+
+ Output:
+
+ EM encoded message, an octet string of length emLen = \ceil
+ (emBits/8)
+
+ Errors: "Encoding error"; "message too long"
+
+
+
+
+
+
+
+
+Moriarty, et al. Informational [Page 42]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+ Steps:
+
+ 1. If the length of M is greater than the input limitation for
+ the hash function (2^61 - 1 octets for SHA-1), output
+ "message too long" and stop.
+
+ 2. Let mHash = Hash(M), an octet string of length hLen.
+
+ 3. If emLen < hLen + sLen + 2, output "encoding error" and stop.
+
+ 4. Generate a random octet string salt of length sLen; if sLen =
+ 0, then salt is the empty string.
+
+ 5. Let
+
+ M' = (0x)00 00 00 00 00 00 00 00 || mHash || salt;
+
+ M' is an octet string of length 8 + hLen + sLen with eight
+ initial zero octets.
+
+ 6. Let H = Hash(M'), an octet string of length hLen.
+
+ 7. Generate an octet string PS consisting of emLen - sLen - hLen
+ - 2 zero octets. The length of PS may be 0.
+
+ 8. Let DB = PS || 0x01 || salt; DB is an octet string of length
+ emLen - hLen - 1.
+
+ 9. Let dbMask = MGF(H, emLen - hLen - 1).
+
+ 10. Let maskedDB = DB \xor dbMask.
+
+ 11. Set the leftmost 8emLen - emBits bits of the leftmost octet
+ in maskedDB to zero.
+
+ 12. Let EM = maskedDB || H || 0xbc.
+
+ 13. Output EM.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moriarty, et al. Informational [Page 43]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+9.1.2. Verification Operation
+
+ EMSA-PSS-VERIFY (M, EM, emBits)
+
+ Options:
+
+ Hash hash function (hLen denotes the length in octets of
+ the hash function output)
+ MGF mask generation function
+ sLen intended length in octets of the salt
+
+ Input:
+
+ M message to be verified, an octet string
+ EM encoded message, an octet string of length emLen = \ceil
+ (emBits/8)
+ emBits maximal bit length of the integer OS2IP (EM) (see Section
+ 4.2), at least 8hLen + 8sLen + 9
+
+ Output: "consistent" or "inconsistent"
+
+ Steps:
+
+ 1. If the length of M is greater than the input limitation for
+ the hash function (2^61 - 1 octets for SHA-1), output
+ "inconsistent" and stop.
+
+ 2. Let mHash = Hash(M), an octet string of length hLen.
+
+ 3. If emLen < hLen + sLen + 2, output "inconsistent" and stop.
+
+ 4. If the rightmost octet of EM does not have hexadecimal value
+ 0xbc, output "inconsistent" and stop.
+
+ 5. Let maskedDB be the leftmost emLen - hLen - 1 octets of EM,
+ and let H be the next hLen octets.
+
+ 6. If the leftmost 8emLen - emBits bits of the leftmost octet in
+ maskedDB are not all equal to zero, output "inconsistent" and
+ stop.
+
+ 7. Let dbMask = MGF(H, emLen - hLen - 1).
+
+ 8. Let DB = maskedDB \xor dbMask.
+
+ 9. Set the leftmost 8emLen - emBits bits of the leftmost octet
+ in DB to zero.
+
+
+
+
+Moriarty, et al. Informational [Page 44]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+ 10. If the emLen - hLen - sLen - 2 leftmost octets of DB are not
+ zero or if the octet at position emLen - hLen - sLen - 1 (the
+ leftmost position is "position 1") does not have hexadecimal
+ value 0x01, output "inconsistent" and stop.
+
+ 11. Let salt be the last sLen octets of DB.
+
+ 12. Let
+
+ M' = (0x)00 00 00 00 00 00 00 00 || mHash || salt ;
+
+ M' is an octet string of length 8 + hLen + sLen with eight
+ initial zero octets.
+
+ 13. Let H' = Hash(M'), an octet string of length hLen.
+
+ 14. If H = H', output "consistent". Otherwise, output
+ "inconsistent".
+
+9.2. EMSA-PKCS1-v1_5
+
+ This encoding method is deterministic and only has an encoding
+ operation.
+
+ EMSA-PKCS1-v1_5-ENCODE (M, emLen)
+
+ Option:
+
+ Hash hash function (hLen denotes the length in octets of
+ the hash function output)
+
+ Input:
+
+ M message to be encoded
+ emLen intended length in octets of the encoded message, at
+ least tLen + 11, where tLen is the octet length of the
+ Distinguished Encoding Rules (DER) encoding T of
+ a certain value computed during the encoding operation
+
+ Output:
+
+ EM encoded message, an octet string of length emLen
+
+ Errors: "message too long"; "intended encoded message length too
+ short"
+
+
+
+
+
+
+Moriarty, et al. Informational [Page 45]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+ Steps:
+
+ 1. Apply the hash function to the message M to produce a hash
+ value H:
+
+ H = Hash(M).
+
+ If the hash function outputs "message too long", output
+ "message too long" and stop.
+
+ 2. Encode the algorithm ID for the hash function and the hash
+ value into an ASN.1 value of type DigestInfo (see
+ Appendix A.2.4) with the DER, where the type DigestInfo has
+ the syntax
+
+ DigestInfo ::= SEQUENCE {
+ digestAlgorithm AlgorithmIdentifier,
+ digest OCTET STRING
+ }
+
+ The first field identifies the hash function and the second
+ contains the hash value. Let T be the DER encoding of the
+ DigestInfo value (see the notes below), and let tLen be the
+ length in octets of T.
+
+ 3. If emLen < tLen + 11, output "intended encoded message length
+ too short" and stop.
+
+ 4. Generate an octet string PS consisting of emLen - tLen - 3
+ octets with hexadecimal value 0xff. The length of PS will be
+ at least 8 octets.
+
+ 5. Concatenate PS, the DER encoding T, and other padding to form
+ the encoded message EM as
+
+ EM = 0x00 || 0x01 || PS || 0x00 || T.
+
+ 6. Output EM.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moriarty, et al. Informational [Page 46]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+ Notes:
+
+ 1. For the nine hash functions mentioned in Appendix B.1, the DER
+ encoding T of the DigestInfo value is equal to the following:
+
+ MD2: (0x)30 20 30 0c 06 08 2a 86 48 86 f7 0d 02 02 05 00 04
+ 10 || H.
+ MD5: (0x)30 20 30 0c 06 08 2a 86 48 86 f7 0d 02 05 05 00 04
+ 10 || H.
+ SHA-1: (0x)30 21 30 09 06 05 2b 0e 03 02 1a 05 00 04 14 || H.
+ SHA-224: (0x)30 2d 30 0d 06 09 60 86 48 01 65 03 04 02 04
+ 05 00 04 1c || H.
+ SHA-256: (0x)30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00
+ 04 20 || H.
+ SHA-384: (0x)30 41 30 0d 06 09 60 86 48 01 65 03 04 02 02 05 00
+ 04 30 || H.
+ SHA-512: (0x)30 51 30 0d 06 09 60 86 48 01 65 03 04 02 03 05 00
+ 04 40 || H.
+ SHA-512/224: (0x)30 2d 30 0d 06 09 60 86 48 01 65 03 04 02 05
+ 05 00 04 1c || H.
+ SHA-512/256: (0x)30 31 30 0d 06 09 60 86 48 01 65 03 04 02 06
+ 05 00 04 20 || H.
+
+ 2. In version 1.5 of this document, T was defined as the BER
+ encoding, rather than the DER encoding, of the DigestInfo value.
+ In particular, it is possible -- at least in theory -- that the
+ verification operation defined in this document (as well as in
+ version 2.0) rejects a signature that is valid with respect to
+ the specification given in PKCS #1 v1.5. This occurs if other
+ rules than DER are applied to DigestInfo (e.g., an indefinite
+ length encoding of the underlying SEQUENCE type). While this is
+ unlikely to be a concern in practice, a cautious implementor may
+ choose to employ a verification operation based on a BER decoding
+ operation as specified in PKCS #1 v1.5. In this manner,
+ compatibility with any valid implementation based on PKCS #1 v1.5
+ is obtained. Such a verification operation should indicate
+ whether the underlying BER encoding is a DER encoding and hence
+ whether the signature is valid with respect to the specification
+ given in this document.
+
+10. Security Considerations
+
+ Security considerations are discussed throughout this memo.
+
+
+
+
+
+
+
+
+Moriarty, et al. Informational [Page 47]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+11. References
+
+11.1. Normative References
+
+ [GARNER] Garner, H., "The Residue Number System", IRE Transactions
+ on Electronic Computers, Volume EC-8, Issue 2, pp.
+ 140-147, DOI 10.1109/TEC.1959.5219515, June 1959.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119,
+ DOI 10.17487/RFC2119, March 1997,
+ <http://www.rfc-editor.org/info/rfc2119>.
+
+ [RSA] Rivest, R., Shamir, A., and L. Adleman, "A Method for
+ Obtaining Digital Signatures and Public-Key
+ Cryptosystems", Communications of the ACM, Volume 21,
+ Issue 2, pp. 120-126, DOI 10.1145/359340.359342, February
+ 1978.
+
+11.2. Informative References
+
+ [ANSIX944] ANSI, "Key Establishment Using Integer Factorization
+ Cryptography", ANSI X9.44-2007, August 2007.
+
+ [BKS] Bleichenbacher, D., Kaliski, B., and J. Staddon, "Recent
+ Results on PKCS #1: RSA Encryption Standard", RSA
+ Laboratories, Bulletin No. 7, June 1998.
+
+ [BLEICHENBACHER]
+ Bleichenbacher, D., "Chosen Ciphertext Attacks Against
+ Protocols Based on the RSA Encryption Standard PKCS #1",
+ Lecture Notes in Computer Science, Volume 1462, pp. 1-12,
+ 1998.
+
+ [CHOSEN] Desmedt, Y. and A. Odlyzko, "A Chosen Text Attack on the
+ RSA Cryptosystem and Some Discrete Logarithm Schemes",
+ Lecture Notes in Computer Science, Volume 218, pp.
+ 516-522, 1985.
+
+ [COCHRAN] Cochran, M., "Notes on the Wang et al. 2^63 SHA-1
+ Differential Path", Cryptology ePrint Archive: Report
+ 2007/474, August 2008, <http://eprint.iacr.org/2007/474>.
+
+ [FASTDEC] Quisquater, J. and C. Couvreur, "Fast Decipherment
+ Algorithm for RSA Public-Key Cryptosystem", Electronic
+ Letters, Volume 18, Issue 21, pp. 905-907,
+ DOI 10.1049/el:19820617, October 1982.
+
+
+
+
+Moriarty, et al. Informational [Page 48]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+ [FDH] Coron, J., "On the Exact Security of Full Domain Hash",
+ Lecture Notes in Computer Science, Volume 1880, pp.
+ 229-235, 2000.
+
+ [FOPS] Fujisaki, E., Okamoto, T., Pointcheval, D., and J. Stern,
+ "RSA-OAEP is Secure under the RSA Assumption", Lecture
+ Notes in Computer Science, Volume 2139, pp. 260-274,
+ August 2001.
+
+ [FORGERY] Coppersmith, D., Halevi, S., and C. Jutla, "ISO 9796-1 and
+ the new forgery strategy", rump session of Crypto, August
+ 1999.
+
+ [HAASTAD] Haastad, J., "Solving Simultaneous Modular Equations of
+ Low Degree", SIAM Journal on Computing, Volume 17,
+ Issue 2, pp. 336-341, DOI 10.1137/0217019, April 1988.
+
+ [HANDBOOK] Menezes, A., van Oorschot, P., and S. Vanstone, "Handbook
+ of Applied Cryptography", CRC Press, ISBN: 0849385237,
+ 1996.
+
+ [HASHID] Kaliski, B., "On Hash Function Firewalls in Signature
+ Schemes", Lecture Notes in Computer Science, Volume 2271,
+ pp. 1-16, DOI 10.1007/3-540-45760-7_1, February 2002.
+
+ [IEEE1363] IEEE, "Standard Specifications for Public Key
+ Cryptography", IEEE Std 1363-2000,
+ DOI 10.1109/IEEESTD.2000.92292, August 2000,
+ <http://ieeexplore.ieee.org/document/891000/>.
+
+ [IEEE1363A]
+ IEEE, "Standard Specifications for Public Key Cryptography
+ - Amendment 1: Additional Techniques", IEEE Std 1363a-
+ 2004, DOI 10.1109/IEEESTD.2004.94612, September 2004,
+ <http://ieeexplore.ieee.org/document/1335427/>.
+
+ [ISO18033] International Organization for Standardization,
+ "Information technology -- Security techniques --
+ Encryption algorithms - Part 2: Asymmetric ciphers", ISO/
+ IEC 18033-2:2006, May 2006.
+
+ [ISO9594] International Organization for Standardization,
+ "Information technology - Open Systems Interconnection -
+ The Directory: Public-key and attribute certificate
+ frameworks", ISO/IEC 9594-8:2008, December 2008.
+
+
+
+
+
+
+Moriarty, et al. Informational [Page 49]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+ [ISO9796] International Organization for Standardization,
+ "Information technology - Security techniques - Digital
+ signature schemes giving message recovery - Part 2:
+ Integer factorization based mechanisms",
+ ISO/IEC 9796-2:2010, December 2010.
+
+ [JONSSON] Jonsson, J., "Security Proofs for the RSA-PSS Signature
+ Scheme and Its Variants", Cryptology ePrint
+ Archive: Report 2001/053, March 2002,
+ <http://eprint.iacr.org/2001/053>.
+
+ [LOWEXP] Coppersmith, D., Franklin, M., Patarin, J., and M. Reiter,
+ "Low-Exponent RSA with Related Messages", Lecture Notes in
+ Computer Science, Volume 1070, pp. 1-9, 1996.
+
+ [MANGER] Manger, J., "A Chosen Ciphertext Attack on RSA Optimal
+ Asymmetric Encryption Padding (OAEP) as Standardized in
+ PKCS #1 v2.0", Lecture Notes in Computer Science, Volume
+ 2139, pp. 230-238, DOI 10.1007/3-540-44647-8_14, 2001.
+
+ [MD4] Dobbertin, H., "Cryptanalysis of MD4", Lecture Notes in
+ Computer Science, Volume 1039, pp. 53-69,
+ DOI 10.1007/3-540-60865-6_43, 1996.
+
+ [MD4FIRST] Dobbertin, H., "The First Two Rounds of MD4 are Not One-
+ Way", Lecture Notes in Computer Science, Volume 1372, pp.
+ 284-292, DOI 10.1007/3-540-69710-1_19, March 1998.
+
+ [MD4LAST] den Boer, B. and A. Bosselaers, "An Attack on the Last Two
+ Rounds of MD4", Lecture Notes in Computer Science, Volume
+ 576, pp. 194-203, DOI 10.1007/3-540-46766-1_14, 1992.
+
+ [NEWATTACK]
+ Coron, J., Joye, M., Naccache, D., and P. Paillier, "New
+ Attacks on PKCS #1 v1.5 Encryption", Lecture Notes in
+ Computer Science, Volume 1807, pp. 369-381,
+ DOI 10.1007/3-540-45539-6_25, May 2000.
+
+ [OAEP] Bellare, M. and P. Rogaway, "Optimal Asymmetric Encryption
+ - How to Encrypt with RSA", Lecture Notes in Computer
+ Science, Volume 950, pp. 92-111, November 1995.
+
+ [PA98] Bellare, M., Desai, A., Pointcheval, D., and P. Rogaway,
+ "Relations Among Notions of Security for Public-Key
+ Encryption Schemes", Lecture Notes in Computer
+ Science, Volume 1462, pp. 26-45, DOI 10.1007/BFb0055718,
+ 1998.
+
+
+
+
+Moriarty, et al. Informational [Page 50]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+ [PADDING] Coron, J., Naccache, D., and J. Stern, "On the Security of
+ RSA Padding", Lecture Notes in Computer Science, Volume
+ 1666, pp. 1-18, DOI 10.1007/3-540-48405-1_1, December
+ 1999.
+
+ [PKCS1_22] RSA Laboratories, "PKCS #1: RSA Cryptography Standard
+ Version 2.2", October 2012.
+
+ [PREFIX] Stevens, M., Lenstra, A., and B. de Weger, "Chosen-prefix
+ collisions for MD5 and applications", International
+ Journal of Applied Cryptography, Volume 2, No. 4, pp.
+ 322-359, July 2012.
+
+ [PSS] Bellare, M. and P. Rogaway, "PSS: Provably Secure Encoding
+ Method for Digital Signatures", Submission to IEEE P1363a,
+ August 1998, <http://grouper.ieee.org/groups/1363/
+ P1363a/contributions/pss-submission.pdf>.
+
+ [PSSPROOF] Coron, J., "Optimal Security Proofs for PSS and Other
+ Signature Schemes", Lecture Notes in Computer
+ Science, Volume 2332, pp. 272-287,
+ DOI 10.1007/3-540-46035-7_18, 2002.
+
+ [RFC1319] Kaliski, B., "The MD2 Message-Digest Algorithm", RFC 1319,
+ DOI 10.17487/RFC1319, April 1992,
+ <http://www.rfc-editor.org/info/rfc1319>.
+
+ [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
+ DOI 10.17487/RFC1321, April 1992,
+ <http://www.rfc-editor.org/info/rfc1321>.
+
+ [RFC2313] Kaliski, B., "PKCS #1: RSA Encryption Version 1.5",
+ RFC 2313, DOI 10.17487/RFC2313, March 1998,
+ <http://www.rfc-editor.org/info/rfc2313>.
+
+ [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax
+ Version 1.5", RFC 2315, DOI 10.17487/RFC2315, March 1998,
+ <http://www.rfc-editor.org/info/rfc2315>.
+
+ [RFC2437] Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography
+ Specifications Version 2.0", RFC 2437,
+ DOI 10.17487/RFC2437, October 1998,
+ <http://www.rfc-editor.org/info/rfc2437>.
+
+ [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
+ Standards (PKCS) #1: RSA Cryptography Specifications
+ Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February
+ 2003, <http://www.rfc-editor.org/info/rfc3447>.
+
+
+
+Moriarty, et al. Informational [Page 51]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+ [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
+ (TLS) Protocol Version 1.2", RFC 5246,
+ DOI 10.17487/RFC5246, August 2008,
+ <http://www.rfc-editor.org/info/rfc5246>.
+
+ [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
+ RFC 5652, DOI 10.17487/RFC5652, September 2009,
+ <http://www.rfc-editor.org/info/rfc5652>.
+
+ [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958,
+ DOI 10.17487/RFC5958, August 2010,
+ <http://www.rfc-editor.org/info/rfc5958>.
+
+ [RFC6149] Turner, S. and L. Chen, "MD2 to Historic Status",
+ RFC 6149, DOI 10.17487/RFC6149, March 2011,
+ <http://www.rfc-editor.org/info/rfc6149>.
+
+ [RFC7292] Moriarty, K., Ed., Nystrom, M., Parkinson, S., Rusch, A.,
+ and M. Scott, "PKCS #12: Personal Information Exchange
+ Syntax v1.1", RFC 7292, DOI 10.17487/RFC7292, July 2014,
+ <http://www.rfc-editor.org/info/rfc7292>.
+
+ [RSARABIN] Bellare, M. and P. Rogaway, "The Exact Security of Digital
+ Signatures - How to Sign with RSA and Rabin", Lecture
+ Notes in Computer Science, Volume 1070, pp. 399-416,
+ DOI 10.1007/3-540-68339-9_34, 1996.
+
+ [RSATLS] Jonsson, J. and B. Kaliski, "On the Security of RSA
+ Encryption in TLS", Lecture Notes in Computer
+ Science, Volume 2442, pp. 127-142,
+ DOI 10.1007/3-540-45708-9_9, 2002.
+
+ [SHA1CRYPT]
+ Wang, X., Yao, A., and F. Yao, "Cryptanalysis on SHA-1",
+ Lecture Notes in Computer Science, Volume 2442, pp.
+ 127-142, February 2005,
+ <http://csrc.nist.gov/groups/ST/hash/documents/
+ Wang_SHA1-New-Result.pdf>.
+
+ [SHOUP] Shoup, V., "OAEP Reconsidered (Extended Abstract)",
+ Lecture Notes in Computer Science, Volume 2139, pp.
+ 239-259, DOI 10.1007/3-540-44647-8_15, 2001.
+
+ [SHS] National Institute of Standards and Technology, "Secure
+ Hash Standard (SHS)", FIPS PUB 180-4, August 2015,
+ <http://dx.doi.org/10.6028/NIST.FIPS.180-4>.
+
+
+
+
+
+Moriarty, et al. Informational [Page 52]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+ [SILVERMAN]
+ Silverman, R., "A Cost-Based Security Analysis of
+ Symmetric and Asymmetric Key Lengths", RSA
+ Laboratories, Bulletin No. 13, 2000.
+
+ [SIMMONS] Simmons, G., "Subliminal Communication is Easy Using the
+ DSA", Lecture Notes in Computer Science, Volume 765, pp.
+ 218-232, DOI 10.1007/3-540-48285-7_18, 1994.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moriarty, et al. Informational [Page 53]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+Appendix A. ASN.1 Syntax
+
+A.1. RSA Key Representation
+
+ This section defines ASN.1 object identifiers for RSA public and
+ private keys and defines the types RSAPublicKey and RSAPrivateKey.
+ The intended application of these definitions includes X.509
+ certificates, PKCS #8 [RFC5958], and PKCS #12 [RFC7292].
+
+ The object identifier rsaEncryption identifies RSA public and private
+ keys as defined in Appendices A.1.1 and A.1.2. The parameters field
+ has associated with this OID in a value of type AlgorithmIdentifier
+ SHALL have a value of type NULL.
+
+ rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1 }
+
+ The definitions in this section have been extended to support multi-
+ prime RSA, but they are backward compatible with previous versions.
+
+A.1.1. RSA Public Key Syntax
+
+ An RSA public key should be represented with the ASN.1 type
+ RSAPublicKey:
+
+ RSAPublicKey ::= SEQUENCE {
+ modulus INTEGER, -- n
+ publicExponent INTEGER -- e
+ }
+
+ The fields of type RSAPublicKey have the following meanings:
+
+ o modulus is the RSA modulus n.
+
+ o publicExponent is the RSA public exponent e.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moriarty, et al. Informational [Page 54]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+A.1.2. RSA Private Key Syntax
+
+ An RSA private key should be represented with the ASN.1 type
+ RSAPrivateKey:
+
+ RSAPrivateKey ::= SEQUENCE {
+ version Version,
+ modulus INTEGER, -- n
+ publicExponent INTEGER, -- e
+ privateExponent INTEGER, -- d
+ prime1 INTEGER, -- p
+ prime2 INTEGER, -- q
+ exponent1 INTEGER, -- d mod (p-1)
+ exponent2 INTEGER, -- d mod (q-1)
+ coefficient INTEGER, -- (inverse of q) mod p
+ otherPrimeInfos OtherPrimeInfos OPTIONAL
+ }
+
+ The fields of type RSAPrivateKey have the following meanings:
+
+ o version is the version number, for compatibility with future
+ revisions of this document. It SHALL be 0 for this version of the
+ document, unless multi-prime is used; in which case, it SHALL be
+ 1.
+
+ Version ::= INTEGER { two-prime(0), multi(1) }
+ (CONSTRAINED BY
+ {-- version must be multi if otherPrimeInfos present --})
+
+ o modulus is the RSA modulus n.
+
+ o publicExponent is the RSA public exponent e.
+
+ o privateExponent is the RSA private exponent d.
+
+ o prime1 is the prime factor p of n.
+
+ o prime2 is the prime factor q of n.
+
+ o exponent1 is d mod (p - 1).
+
+ o exponent2 is d mod (q - 1).
+
+ o coefficient is the CRT coefficient q^(-1) mod p.
+
+
+
+
+
+
+
+Moriarty, et al. Informational [Page 55]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+ o otherPrimeInfos contains the information for the additional primes
+ r_3, ..., r_u, in order. It SHALL be omitted if version is 0 and
+ SHALL contain at least one instance of OtherPrimeInfo if version
+ is 1.
+
+ OtherPrimeInfos ::= SEQUENCE SIZE(1..MAX) OF OtherPrimeInfo
+
+ OtherPrimeInfo ::= SEQUENCE {
+ prime INTEGER, -- ri
+ exponent INTEGER, -- di
+ coefficient INTEGER -- ti
+ }
+
+ The fields of type OtherPrimeInfo have the following meanings:
+
+ o prime is a prime factor r_i of n, where i >= 3.
+
+ o exponent is d_i = d mod (r_i - 1).
+
+ o coefficient is the CRT coefficient t_i = (r_1 * r_2 * ... *
+ r_(i-1))^(-1) mod r_i.
+
+ Note: It is important to protect the RSA private key against both
+ disclosure and modification. Techniques for such protection are
+ outside the scope of this document. Methods for storing and
+ distributing private keys and other cryptographic data are described
+ in PKCS #12 and #15.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moriarty, et al. Informational [Page 56]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+A.2. Scheme Identification
+
+ This section defines object identifiers for the encryption and
+ signature schemes. The schemes compatible with PKCS #1 v1.5 have the
+ same definitions as in PKCS #1 v1.5. The intended application of
+ these definitions includes X.509 certificates and PKCS #7.
+
+ Here are type identifier definitions for the PKCS #1 OIDs:
+
+ PKCS1Algorithms ALGORITHM-IDENTIFIER ::= {
+ { OID rsaEncryption PARAMETERS NULL } |
+ { OID md2WithRSAEncryption PARAMETERS NULL } |
+ { OID md5WithRSAEncryption PARAMETERS NULL } |
+ { OID sha1WithRSAEncryption PARAMETERS NULL } |
+ { OID sha224WithRSAEncryption PARAMETERS NULL } |
+ { OID sha256WithRSAEncryption PARAMETERS NULL } |
+ { OID sha384WithRSAEncryption PARAMETERS NULL } |
+ { OID sha512WithRSAEncryption PARAMETERS NULL } |
+ { OID sha512-224WithRSAEncryption PARAMETERS NULL } |
+ { OID sha512-256WithRSAEncryption PARAMETERS NULL } |
+ { OID id-RSAES-OAEP PARAMETERS RSAES-OAEP-params } |
+ PKCS1PSourceAlgorithms |
+ { OID id-RSASSA-PSS PARAMETERS RSASSA-PSS-params },
+ ... -- Allows for future expansion --
+ }
+
+A.2.1. RSAES-OAEP
+
+ The object identifier id-RSAES-OAEP identifies the RSAES-OAEP
+ encryption scheme.
+
+ id-RSAES-OAEP OBJECT IDENTIFIER ::= { pkcs-1 7 }
+
+ The parameters field associated with this OID in a value of type
+ AlgorithmIdentifier SHALL have a value of type RSAES-OAEP-params:
+
+ RSAES-OAEP-params ::= SEQUENCE {
+ hashAlgorithm [0] HashAlgorithm DEFAULT sha1,
+ maskGenAlgorithm [1] MaskGenAlgorithm DEFAULT mgf1SHA1,
+ pSourceAlgorithm [2] PSourceAlgorithm DEFAULT pSpecifiedEmpty
+ }
+
+ The fields of type RSAES-OAEP-params have the following meanings:
+
+ o hashAlgorithm identifies the hash function. It SHALL be an
+ algorithm ID with an OID in the set OAEP-PSSDigestAlgorithms. For
+ a discussion of supported hash functions, see Appendix B.1.
+
+
+
+
+Moriarty, et al. Informational [Page 57]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+ HashAlgorithm ::= AlgorithmIdentifier {
+ {OAEP-PSSDigestAlgorithms}
+ }
+
+ OAEP-PSSDigestAlgorithms ALGORITHM-IDENTIFIER ::= {
+ { OID id-sha1 PARAMETERS NULL }|
+ { OID id-sha224 PARAMETERS NULL }|
+ { OID id-sha256 PARAMETERS NULL }|
+ { OID id-sha384 PARAMETERS NULL }|
+ { OID id-sha512 PARAMETERS NULL }|
+ { OID id-sha512-224 PARAMETERS NULL }|
+ { OID id-sha512-256 PARAMETERS NULL },
+ ... -- Allows for future expansion --
+ }
+
+ The default hash function is SHA-1:
+
+ sha1 HashAlgorithm ::= {
+ algorithm id-sha1,
+ parameters SHA1Parameters : NULL
+ }
+
+ SHA1Parameters ::= NULL
+
+ o maskGenAlgorithm identifies the mask generation function. It
+ SHALL be an algorithm ID with an OID in the set
+ PKCS1MGFAlgorithms, which for this version SHALL consist of
+ id-mgf1, identifying the MGF1 mask generation function (see
+ Appendix B.2.1). The parameters field associated with id-mgf1
+ SHALL be an algorithm ID with an OID in the set
+ OAEP-PSSDigestAlgorithms, identifying the hash function on which
+ MGF1 is based.
+
+ MaskGenAlgorithm ::= AlgorithmIdentifier { {PKCS1MGFAlgorithms} }
+
+ PKCS1MGFAlgorithms ALGORITHM-IDENTIFIER ::= {
+ { OID id-mgf1 PARAMETERS HashAlgorithm },
+ ... -- Allows for future expansion --
+ }
+
+ o The default mask generation function is MGF1 with SHA-1:
+
+ mgf1SHA1 MaskGenAlgorithm ::= {
+ algorithm id-mgf1,
+ parameters HashAlgorithm : sha1
+ }
+
+
+
+
+
+Moriarty, et al. Informational [Page 58]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+ o pSourceAlgorithm identifies the source (and possibly the value) of
+ the label L. It SHALL be an algorithm ID with an OID in the set
+ PKCS1PSourceAlgorithms, which for this version SHALL consist of
+ id-pSpecified, indicating that the label is specified explicitly.
+ The parameters field associated with id-pSpecified SHALL have a
+ value of type OCTET STRING, containing the label. In previous
+ versions of this specification, the term "encoding parameters" was
+ used rather than "label", hence the name of the type below.
+
+ PSourceAlgorithm ::= AlgorithmIdentifier {
+ {PKCS1PSourceAlgorithms}
+ }
+
+ PKCS1PSourceAlgorithms ALGORITHM-IDENTIFIER ::= {
+ { OID id-pSpecified PARAMETERS EncodingParameters },
+ ... -- Allows for future expansion --
+ }
+
+ id-pSpecified OBJECT IDENTIFIER ::= { pkcs-1 9 }
+
+ EncodingParameters ::= OCTET STRING(SIZE(0..MAX))
+
+ o The default label is an empty string (so that lHash will contain
+ the hash of the empty string):
+
+ pSpecifiedEmpty PSourceAlgorithm ::= {
+ algorithm id-pSpecified,
+ parameters EncodingParameters : emptyString
+ }
+
+ emptyString EncodingParameters ::= ''H
+
+ If all of the default values of the fields in RSAES-OAEP-params are
+ used, then the algorithm identifier will have the following value:
+
+ rSAES-OAEP-Default-Identifier RSAES-AlgorithmIdentifier ::= {
+ algorithm id-RSAES-OAEP,
+ parameters RSAES-OAEP-params : {
+ hashAlgorithm sha1,
+ maskGenAlgorithm mgf1SHA1,
+ pSourceAlgorithm pSpecifiedEmpty
+ }
+ }
+
+ RSAES-AlgorithmIdentifier ::= AlgorithmIdentifier {
+ {PKCS1Algorithms}
+ }
+
+
+
+
+Moriarty, et al. Informational [Page 59]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+A.2.2. RSAES-PKCS-v1_5
+
+ The object identifier rsaEncryption (see Appendix A.1) identifies the
+ RSAES-PKCS1-v1_5 encryption scheme. The parameters field associated
+ with this OID in a value of type AlgorithmIdentifier SHALL have a
+ value of type NULL. This is the same as in PKCS #1 v1.5.
+
+ rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1 }
+
+A.2.3. RSASSA-PSS
+
+ The object identifier id-RSASSA-PSS identifies the RSASSA-PSS
+ encryption scheme.
+
+ id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 }
+
+ The parameters field associated with this OID in a value of type
+ AlgorithmIdentifier SHALL have a value of type RSASSA-PSS-params:
+
+ RSASSA-PSS-params ::= SEQUENCE {
+ hashAlgorithm [0] HashAlgorithm DEFAULT sha1,
+ maskGenAlgorithm [1] MaskGenAlgorithm DEFAULT mgf1SHA1,
+ saltLength [2] INTEGER DEFAULT 20,
+ trailerField [3] TrailerField DEFAULT trailerFieldBC
+ }
+
+ The fields of type RSASSA-PSS-params have the following meanings:
+
+ o hashAlgorithm identifies the hash function. It SHALL be an
+ algorithm ID with an OID in the set OAEP-PSSDigestAlgorithms (see
+ Appendix A.2.1). The default hash function is SHA-1.
+
+ o maskGenAlgorithm identifies the mask generation function. It
+ SHALL be an algorithm ID with an OID in the set PKCS1MGFAlgorithms
+ (see Appendix A.2.1). The default mask generation function is
+ MGF1 with SHA-1. For MGF1 (and more generally, for other mask
+ generation functions based on a hash function), it is RECOMMENDED
+ that the underlying hash function be the same as the one
+ identified by hashAlgorithm; see Note 2 in Section 9.1 for further
+ comments.
+
+ o saltLength is the octet length of the salt. It SHALL be an
+ integer. For a given hashAlgorithm, the default value of
+ saltLength is the octet length of the hash value. Unlike the
+ other fields of type RSASSA-PSS-params, saltLength does not need
+ to be fixed for a given RSA key pair.
+
+
+
+
+
+Moriarty, et al. Informational [Page 60]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+ o trailerField is the trailer field number, for compatibility with
+ IEEE 1363a [IEEE1363A]. It SHALL be 1 for this version of the
+ document, which represents the trailer field with hexadecimal
+ value 0xbc. Other trailer fields (including the trailer field
+ HashID || 0xcc in IEEE 1363a) are not supported in this document.
+
+ TrailerField ::= INTEGER { trailerFieldBC(1) }
+
+ If the default values of the hashAlgorithm, maskGenAlgorithm, and
+ trailerField fields of RSASSA-PSS-params are used, then the algorithm
+ identifier will have the following value:
+
+ rSASSA-PSS-Default-Identifier RSASSA-AlgorithmIdentifier ::= {
+ algorithm id-RSASSA-PSS,
+ parameters RSASSA-PSS-params : {
+ hashAlgorithm sha1,
+ maskGenAlgorithm mgf1SHA1,
+ saltLength 20,
+ trailerField trailerFieldBC
+ }
+ }
+
+ RSASSA-AlgorithmIdentifier ::= AlgorithmIdentifier {
+ {PKCS1Algorithms}
+ }
+
+ Note: In some applications, the hash function underlying a signature
+ scheme is identified separately from the rest of the operations in
+ the signature scheme. For instance, in PKCS #7 [RFC2315], a hash
+ function identifier is placed before the message and a "digest
+ encryption" algorithm identifier (indicating the rest of the
+ operations) is carried with the signature. In order for PKCS #7 to
+ support the RSASSA-PSS signature scheme, an object identifier would
+ need to be defined for the operations in RSASSA-PSS after the hash
+ function (analogous to the RSAEncryption OID for the
+ RSASSA-PKCS1-v1_5 scheme). S/MIME Cryptographic Message Syntax (CMS)
+ [RFC5652] takes a different approach. Although a hash function
+ identifier is placed before the message, an algorithm identifier for
+ the full signature scheme may be carried with a CMS signature (this
+ is done for DSA signatures). Following this convention, the
+ id-RSASSA-PSS OID can be used to identify RSASSA-PSS signatures in
+ CMS. Since CMS is considered the successor to PKCS #7 and new
+ developments such as the addition of support for RSASSA-PSS will be
+ pursued with respect to CMS rather than PKCS #7, an OID for the "rest
+ of" RSASSA-PSS is not defined in this version of PKCS #1.
+
+
+
+
+
+
+Moriarty, et al. Informational [Page 61]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+A.2.4. RSASSA-PKCS-v1_5
+
+ The object identifier for RSASSA-PKCS1-v1_5 SHALL be one of the
+ following. The choice of OID depends on the choice of hash
+ algorithm: MD2, MD5, SHA-1, SHA-224, SHA-256, SHA-384, SHA-512,
+ SHA-512/224, or SHA-512/256. Note that if either MD2 or MD5 is used,
+ then the OID is just as in PKCS #1 v1.5. For each OID, the
+ parameters field associated with this OID in a value of type
+ AlgorithmIdentifier SHALL have a value of type NULL. The OID should
+ be chosen in accordance with the following table:
+
+ Hash algorithm OID
+ ------------------------------------------------------------
+ MD2 md2WithRSAEncryption ::= {pkcs-1 2}
+ MD5 md5WithRSAEncryption ::= {pkcs-1 4}
+ SHA-1 sha1WithRSAEncryption ::= {pkcs-1 5}
+ SHA-256 sha224WithRSAEncryption ::= {pkcs-1 14}
+ SHA-256 sha256WithRSAEncryption ::= {pkcs-1 11}
+ SHA-384 sha384WithRSAEncryption ::= {pkcs-1 12}
+ SHA-512 sha512WithRSAEncryption ::= {pkcs-1 13}
+ SHA-512/224 sha512-224WithRSAEncryption ::= {pkcs-1 15}
+ SHA-512/256 sha512-256WithRSAEncryption ::= {pkcs-1 16}
+
+ The EMSA-PKCS1-v1_5 encoding method includes an ASN.1 value of type
+ DigestInfo, where the type DigestInfo has the syntax
+
+ DigestInfo ::= SEQUENCE {
+ digestAlgorithm DigestAlgorithm,
+ digest OCTET STRING
+ }
+
+ digestAlgorithm identifies the hash function and SHALL be an
+ algorithm ID with an OID in the set PKCS1-v1-5DigestAlgorithms. For
+ a discussion of supported hash functions, see Appendix B.1.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moriarty, et al. Informational [Page 62]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+ DigestAlgorithm ::= AlgorithmIdentifier {
+ {PKCS1-v1-5DigestAlgorithms}
+ }
+
+ PKCS1-v1-5DigestAlgorithms ALGORITHM-IDENTIFIER ::= {
+ { OID id-md2 PARAMETERS NULL }|
+ { OID id-md5 PARAMETERS NULL }|
+ { OID id-sha1 PARAMETERS NULL }|
+ { OID id-sha224 PARAMETERS NULL }|
+ { OID id-sha256 PARAMETERS NULL }|
+ { OID id-sha384 PARAMETERS NULL }|
+ { OID id-sha512 PARAMETERS NULL }|
+ { OID id-sha512-224 PARAMETERS NULL }|
+ { OID id-sha512-256 PARAMETERS NULL }
+ }
+
+Appendix B. Supporting Techniques
+
+ This section gives several examples of underlying functions
+ supporting the encryption schemes in Section 7 and the encoding
+ methods in Section 9. A range of techniques is given here to allow
+ compatibility with existing applications as well as migration to new
+ techniques. While these supporting techniques are appropriate for
+ applications to implement, none of them is required to be
+ implemented. It is expected that profiles for PKCS #1 v2.2 will be
+ developed that specify particular supporting techniques.
+
+ This section also gives object identifiers for the supporting
+ techniques.
+
+B.1. Hash Functions
+
+ Hash functions are used in the operations contained in Sections 7 and
+ 9. Hash functions are deterministic, meaning that the output is
+ completely determined by the input. Hash functions take octet
+ strings of variable length and generate fixed-length octet strings.
+ The hash functions used in the operations contained in Sections 7 and
+ 9 should generally be collision-resistant. This means that it is
+ infeasible to find two distinct inputs to the hash function that
+ produce the same output. A collision-resistant hash function also
+ has the desirable property of being one-way; this means that given an
+ output, it is infeasible to find an input whose hash is the specified
+ output. In addition to the requirements, the hash function should
+ yield a mask generation function (Appendix B.2) with pseudorandom
+ output.
+
+
+
+
+
+
+Moriarty, et al. Informational [Page 63]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+ Nine hash functions are given as examples for the encoding methods in
+ this document: MD2 [RFC1319] (which was retired by [RFC6149]), MD5
+ [RFC1321], SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224,
+ and SHA-512/256 [SHS]. For the RSAES-OAEP encryption scheme and
+ EMSA-PSS encoding method, only SHA-1, SHA-224, SHA-256, SHA-384, SHA-
+ 512, SHA-512/224, and SHA-512/256 are RECOMMENDED. For the EMSA-
+ PKCS1-v1_5 encoding method, SHA-224, SHA-256, SHA-384, SHA-512, SHA-
+ 512/224, and SHA-512/256 are RECOMMENDED for new applications. MD2,
+ MD5, and SHA-1 are recommended only for compatibility with existing
+ applications based on PKCS #1 v1.5.
+
+ The object identifiers id-md2, id-md5, id-sha1, id-sha224, id-sha256,
+ id-sha384, id-sha512, id-sha512/224, and id-sha512/256 identify the
+ respective hash functions:
+
+ id-md2 OBJECT IDENTIFIER ::= {
+ iso (1) member-body (2) us (840) rsadsi (113549)
+ digestAlgorithm (2) 2
+ }
+
+ id-md5 OBJECT IDENTIFIER ::= {
+ iso (1) member-body (2) us (840) rsadsi (113549)
+ digestAlgorithm (2) 5
+ }
+
+ id-sha1 OBJECT IDENTIFIER ::= {
+ iso(1) identified-organization(3) oiw(14) secsig(3)
+ algorithms(2) 26
+ }
+
+ id-sha224 OBJECT IDENTIFIER ::= {
+ joint-iso-itu-t (2) country (16) us (840) organization (1)
+ gov (101) csor (3) nistalgorithm (4) hashalgs (2) 4
+ }
+
+ id-sha256 OBJECT IDENTIFIER ::= {
+ joint-iso-itu-t (2) country (16) us (840) organization (1)
+ gov (101) csor (3) nistalgorithm (4) hashalgs (2) 1
+ }
+
+ id-sha384 OBJECT IDENTIFIER ::= {
+ joint-iso-itu-t (2) country (16) us (840) organization (1)
+ gov (101) csor (3) nistalgorithm (4) hashalgs (2) 2
+ }
+
+
+
+
+
+
+
+Moriarty, et al. Informational [Page 64]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+ id-sha512 OBJECT IDENTIFIER ::= {
+ joint-iso-itu-t (2) country (16) us (840) organization (1)
+ gov (101) csor (3) nistalgorithm (4) hashalgs (2) 3
+ }
+
+ id-sha512-224 OBJECT IDENTIFIER ::= {
+ joint-iso-itu-t (2) country (16) us (840) organization (1)
+ gov (101) csor (3) nistalgorithm (4) hashalgs (2) 5
+ }
+
+ id-sha512-256 OBJECT IDENTIFIER ::= {
+ joint-iso-itu-t (2) country (16) us (840) organization (1)
+ gov (101) csor (3) nistalgorithm (4) hashalgs (2) 6
+ }
+
+ The parameters field associated with these OIDs in a value of type
+ AlgorithmIdentifier SHALL have a value of type NULL.
+
+ The parameters field associated with id-md2 and id-md5 in a value of
+ type AlgorithmIdentifier shall have a value of type NULL.
+
+ The parameters field associated with id-sha1, id-sha224, id-sha256,
+ id-sha384, id-sha512, id-sha512/224, and id-sha512/256 should
+ generally be omitted, but if present, it shall have a value of type
+ NULL.
+
+ This is to align with the definitions originally promulgated by NIST.
+ For the SHA algorithms, implementations MUST accept
+ AlgorithmIdentifier values both without parameters and with NULL
+ parameters.
+
+ Exception: When formatting the DigestInfoValue in EMSA-PKCS1-v1_5
+ (see Section 9.2), the parameters field associated with id-sha1,
+ id-sha224, id-sha256, id-sha384, id-sha512, id-sha512/224, and
+ id-sha512/256 shall have a value of type NULL. This is to maintain
+ compatibility with existing implementations and with the numeric
+ information values already published for EMSA-PKCS1-v1_5, which are
+ also reflected in IEEE 1363a [IEEE1363A].
+
+ Note: Version 1.5 of PKCS #1 also allowed for the use of MD4 in
+ signature schemes. The cryptanalysis of MD4 has progressed
+ significantly in the intervening years. For example, Dobbertin [MD4]
+ demonstrated how to find collisions for MD4 and that the first two
+ rounds of MD4 are not one-way [MD4FIRST]. Because of these results
+ and others (e.g., [MD4LAST]), MD4 is NOT RECOMMENDED.
+
+ Further advances have been made in the cryptanalysis of MD2 and MD5,
+ especially after the findings of Stevens et al. [PREFIX] on chosen-
+
+
+
+Moriarty, et al. Informational [Page 65]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+ prefix collisions on MD5. MD2 and MD5 should be considered
+ cryptographically broken and removed from existing applications.
+ This version of the standard supports MD2 and MD5 just for backwards-
+ compatibility reasons.
+
+ There have also been advances in the cryptanalysis of SHA-1.
+ Particularly, the results of Wang et al. [SHA1CRYPT] (which have
+ been independently verified by M. Cochran in his analysis [COCHRAN])
+ on using a differential path to find collisions in SHA-1, which
+ conclude that the security strength of the SHA-1 hashing algorithm is
+ significantly reduced. However, this reduction is not significant
+ enough to warrant the removal of SHA-1 from existing applications,
+ but its usage is only recommended for backwards-compatibility
+ reasons.
+
+ To address these concerns, only SHA-224, SHA-256, SHA-384, SHA-512,
+ SHA-512/224, and SHA-512/256 are RECOMMENDED for new applications.
+ As of today, the best (known) collision attacks against these hash
+ functions are generic attacks with complexity 2L/2, where L is the
+ bit length of the hash output. For the signature schemes in this
+ document, a collision attack is easily translated into a signature
+ forgery. Therefore, the value L / 2 should be at least equal to the
+ desired security level in bits of the signature scheme (a security
+ level of B bits means that the best attack has complexity 2B). The
+ same rule of thumb can be applied to RSAES-OAEP; it is RECOMMENDED
+ that the bit length of the seed (which is equal to the bit length of
+ the hash output) be twice the desired security level in bits.
+
+B.2. Mask Generation Functions
+
+ A 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. There may be restrictions on the length of the
+ input and output octet strings, but such bounds are generally very
+ large. Mask generation functions are deterministic; the octet string
+ output is completely determined by the input octet string. The
+ output of a mask generation function should be pseudorandom: Given
+ one part of the output but not the input, it should be infeasible to
+ predict another part of the output. The provable security of
+ RSAES-OAEP and RSASSA-PSS relies on the random nature of the output
+ of the mask generation function, which in turn relies on the random
+ nature of the underlying hash.
+
+ One mask generation function is given here: MGF1, which is based on a
+ hash function. MGF1 coincides with the mask generation functions
+ defined in IEEE 1363 [IEEE1363] and ANSI X9.44 [ANSIX944]. Future
+ versions of this document may define other mask generation functions.
+
+
+
+
+Moriarty, et al. Informational [Page 66]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+B.2.1. MGF1
+
+ MGF1 is a mask generation function based on a hash function.
+
+ MGF1 (mgfSeed, maskLen)
+
+ Options:
+
+ Hash hash function (hLen denotes the length in octets of
+ the hash function output)
+
+ Input:
+
+ mgfSeed seed from which mask is generated, an octet string
+ maskLen intended length in octets of the mask, at most 2^32 hLen
+
+ Output:
+
+ mask mask, an octet string of length maskLen
+
+ Error: "mask too long"
+
+ Steps:
+
+ 1. If maskLen > 2^32 hLen, output "mask too long" and stop.
+
+ 2. Let T be the empty octet string.
+
+ 3. For counter from 0 to \ceil (maskLen / hLen) - 1, do the
+ following:
+
+ A. Convert counter to an octet string C of length 4 octets (see
+ Section 4.1):
+
+ C = I2OSP (counter, 4) .
+
+ B. Concatenate the hash of the seed mgfSeed and C to the octet
+ string T:
+
+ T = T || Hash(mgfSeed || C) .
+
+ 4. Output the leading maskLen octets of T as the octet string mask.
+
+ The object identifier id-mgf1 identifies the MGF1 mask generation
+ function:
+
+ id-mgf1 OBJECT IDENTIFIER ::= { pkcs-1 8 }
+
+
+
+
+Moriarty, et al. Informational [Page 67]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+ The parameters field associated with this OID in a value of type
+ AlgorithmIdentifier shall have a value of type hashAlgorithm,
+ identifying the hash function on which MGF1 is based.
+
+Appendix C. ASN.1 Module
+
+ -- PKCS #1 v2.2 ASN.1 Module
+ -- Revised October 27, 2012
+
+ -- This module has been checked for conformance with the
+ -- ASN.1 standard by the OSS ASN.1 Tools
+
+ PKCS-1 {
+ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1)
+ modules(0) pkcs-1(1)
+ }
+
+ DEFINITIONS EXPLICIT TAGS ::=
+
+ BEGIN
+
+ -- EXPORTS ALL
+ -- All types and values defined in this module are exported for use
+ -- in other ASN.1 modules.
+
+ IMPORTS
+
+ id-sha224, id-sha256, id-sha384, id-sha512, id-sha512-224,
+ id-sha512-256
+ FROM NIST-SHA2 {
+ joint-iso-itu-t(2) country(16) us(840) organization(1)
+ gov(101) csor(3) nistalgorithm(4) hashAlgs(2)
+ };
+
+ -- ============================
+ -- Basic object identifiers
+ -- ============================
+
+ -- The DER encoding of this in hexadecimal is:
+ -- (0x)06 08
+ -- 2A 86 48 86 F7 0D 01 01
+ --
+ pkcs-1 OBJECT IDENTIFIER ::= {
+ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 1
+ }
+
+ --
+ -- When rsaEncryption is used in an AlgorithmIdentifier,
+
+
+
+Moriarty, et al. Informational [Page 68]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+ -- the parameters MUST be present and MUST be NULL.
+ --
+ rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1 }
+
+ --
+ -- When id-RSAES-OAEP is used in an AlgorithmIdentifier, the
+ -- parameters MUST be present and MUST be RSAES-OAEP-params.
+ --
+ id-RSAES-OAEP OBJECT IDENTIFIER ::= { pkcs-1 7 }
+
+ --
+ -- When id-pSpecified is used in an AlgorithmIdentifier, the
+ -- parameters MUST be an OCTET STRING.
+ --
+ id-pSpecified OBJECT IDENTIFIER ::= { pkcs-1 9 }
+
+ --
+ -- When id-RSASSA-PSS is used in an AlgorithmIdentifier, the
+ -- parameters MUST be present and MUST be RSASSA-PSS-params.
+ --
+ id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 }
+
+ --
+ -- When the following OIDs are used in an AlgorithmIdentifier,
+ -- the parameters MUST be present and MUST be NULL.
+ --
+ md2WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 2 }
+ md5WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 4 }
+ sha1WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 5 }
+ sha224WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 14 }
+ sha256WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 11 }
+ sha384WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 12 }
+ sha512WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 13 }
+ sha512-224WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 15 }
+ sha512-256WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 16 }
+
+ --
+ -- This OID really belongs in a module with the secsig OIDs.
+ --
+ id-sha1 OBJECT IDENTIFIER ::= {
+ iso(1) identified-organization(3) oiw(14) secsig(3) algorithms(2)
+ 26
+ }
+
+ --
+ -- OIDs for MD2 and MD5, allowed only in EMSA-PKCS1-v1_5.
+ --
+ id-md2 OBJECT IDENTIFIER ::= {
+
+
+
+Moriarty, et al. Informational [Page 69]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+ iso(1) member-body(2) us(840) rsadsi(113549) digestAlgorithm(2) 2
+ }
+
+ id-md5 OBJECT IDENTIFIER ::= {
+ iso(1) member-body(2) us(840) rsadsi(113549) digestAlgorithm(2) 5
+ }
+
+ --
+ -- When id-mgf1 is used in an AlgorithmIdentifier, the parameters
+ -- MUST be present and MUST be a HashAlgorithm, for example, sha1.
+ --
+ id-mgf1 OBJECT IDENTIFIER ::= { pkcs-1 8 }
+
+ -- ================
+ -- Useful types
+ -- ================
+
+ ALGORITHM-IDENTIFIER ::= CLASS {
+ &id OBJECT IDENTIFIER UNIQUE,
+ &Type OPTIONAL
+ }
+ WITH SYNTAX { OID &id [PARAMETERS &Type] }
+
+ -- Note: the parameter InfoObjectSet in the following definitions
+ -- allows a distinct information object set to be specified for sets
+ -- of algorithms such as:
+ -- DigestAlgorithms ALGORITHM-IDENTIFIER ::= {
+ -- { OID id-md2 PARAMETERS NULL }|
+ -- { OID id-md5 PARAMETERS NULL }|
+ -- { OID id-sha1 PARAMETERS NULL }
+ -- }
+ --
+
+ AlgorithmIdentifier { ALGORITHM-IDENTIFIER:InfoObjectSet } ::=
+ SEQUENCE {
+ algorithm
+ ALGORITHM-IDENTIFIER.&id({InfoObjectSet}),
+ parameters
+ ALGORITHM-IDENTIFIER.&Type({InfoObjectSet}{@.algorithm})
+ OPTIONAL
+ }
+
+ -- ==============
+ -- Algorithms
+ -- ==============
+
+ --
+ -- Allowed EME-OAEP and EMSA-PSS digest algorithms.
+
+
+
+Moriarty, et al. Informational [Page 70]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+ --
+ OAEP-PSSDigestAlgorithms ALGORITHM-IDENTIFIER ::= {
+ { OID id-sha1 PARAMETERS NULL }|
+ { OID id-sha224 PARAMETERS NULL }|
+ { OID id-sha256 PARAMETERS NULL }|
+ { OID id-sha384 PARAMETERS NULL }|
+ { OID id-sha512 PARAMETERS NULL }|
+ { OID id-sha512-224 PARAMETERS NULL }|
+ { OID id-sha512-256 PARAMETERS NULL },
+ ... -- Allows for future expansion --
+ }
+
+ --
+ -- Allowed EMSA-PKCS1-v1_5 digest algorithms.
+ --
+ PKCS1-v1-5DigestAlgorithms ALGORITHM-IDENTIFIER ::= {
+ { OID id-md2 PARAMETERS NULL }|
+ { OID id-md5 PARAMETERS NULL }|
+ { OID id-sha1 PARAMETERS NULL }|
+ { OID id-sha224 PARAMETERS NULL }|
+ { OID id-sha256 PARAMETERS NULL }|
+ { OID id-sha384 PARAMETERS NULL }|
+ { OID id-sha512 PARAMETERS NULL }|
+ { OID id-sha512-224 PARAMETERS NULL }|
+ { OID id-sha512-256 PARAMETERS NULL }
+ }
+
+ -- When id-md2 and id-md5 are used in an AlgorithmIdentifier, the
+ -- parameters field shall have a value of type NULL.
+
+ -- When id-sha1, id-sha224, id-sha256, id-sha384, id-sha512,
+ -- id-sha512-224, and id-sha512-256 are used in an
+ -- AlgorithmIdentifier, the parameters (which are optional) SHOULD be
+ -- omitted, but if present, they SHALL have a value of type NULL.
+ -- However, implementations MUST accept AlgorithmIdentifier values
+ -- both without parameters and with NULL parameters.
+
+ -- Exception: When formatting the DigestInfoValue in EMSA-PKCS1-v1_5
+ -- (see Section 9.2), the parameters field associated with id-sha1,
+ -- id-sha224, id-sha256, id-sha384, id-sha512, id-sha512-224, and
+ -- id-sha512-256 SHALL have a value of type NULL. This is to
+ -- maintain compatibility with existing implementations and with the
+ -- numeric information values already published for EMSA-PKCS1-v1_5,
+ -- which are also reflected in IEEE 1363a.
+
+ sha1 HashAlgorithm ::= {
+ algorithm id-sha1,
+ parameters SHA1Parameters : NULL
+
+
+
+Moriarty, et al. Informational [Page 71]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+ }
+
+ HashAlgorithm ::= AlgorithmIdentifier { {OAEP-PSSDigestAlgorithms} }
+
+ SHA1Parameters ::= NULL
+
+ --
+ -- Allowed mask generation function algorithms.
+ -- If the identifier is id-mgf1, the parameters are a HashAlgorithm.
+ --
+ PKCS1MGFAlgorithms ALGORITHM-IDENTIFIER ::= {
+ { OID id-mgf1 PARAMETERS HashAlgorithm },
+ ... -- Allows for future expansion --
+ }
+
+ --
+ -- Default AlgorithmIdentifier for id-RSAES-OAEP.maskGenAlgorithm and
+ -- id-RSASSA-PSS.maskGenAlgorithm.
+ --
+ mgf1SHA1 MaskGenAlgorithm ::= {
+ algorithm id-mgf1,
+ parameters HashAlgorithm : sha1
+ }
+
+ MaskGenAlgorithm ::= AlgorithmIdentifier { {PKCS1MGFAlgorithms} }
+
+ --
+ -- Allowed algorithms for pSourceAlgorithm.
+ --
+ PKCS1PSourceAlgorithms ALGORITHM-IDENTIFIER ::= {
+ { OID id-pSpecified PARAMETERS EncodingParameters },
+ ... -- Allows for future expansion --
+ }
+
+ EncodingParameters ::= OCTET STRING(SIZE(0..MAX))
+
+ --
+ -- This identifier means that the label L is an empty string, so the
+ -- digest of the empty string appears in the RSA block before
+ -- masking.
+ --
+
+ pSpecifiedEmpty PSourceAlgorithm ::= {
+ algorithm id-pSpecified,
+ parameters EncodingParameters : emptyString
+ }
+
+ PSourceAlgorithm ::= AlgorithmIdentifier { {PKCS1PSourceAlgorithms} }
+
+
+
+Moriarty, et al. Informational [Page 72]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+ emptyString EncodingParameters ::= ''H
+
+ --
+ -- Type identifier definitions for the PKCS #1 OIDs.
+ --
+ PKCS1Algorithms ALGORITHM-IDENTIFIER ::= {
+ { OID rsaEncryption PARAMETERS NULL } |
+ { OID md2WithRSAEncryption PARAMETERS NULL } |
+ { OID md5WithRSAEncryption PARAMETERS NULL } |
+ { OID sha1WithRSAEncryption PARAMETERS NULL } |
+ { OID sha224WithRSAEncryption PARAMETERS NULL } |
+ { OID sha256WithRSAEncryption PARAMETERS NULL } |
+ { OID sha384WithRSAEncryption PARAMETERS NULL } |
+ { OID sha512WithRSAEncryption PARAMETERS NULL } |
+ { OID sha512-224WithRSAEncryption PARAMETERS NULL } |
+ { OID sha512-256WithRSAEncryption PARAMETERS NULL } |
+ { OID id-RSAES-OAEP PARAMETERS RSAES-OAEP-params } |
+ PKCS1PSourceAlgorithms |
+ { OID id-RSASSA-PSS PARAMETERS RSASSA-PSS-params },
+ ... -- Allows for future expansion --
+ }
+
+ -- ===================
+ -- Main structures
+ -- ===================
+
+ RSAPublicKey ::= SEQUENCE {
+ modulus INTEGER, -- n
+ publicExponent INTEGER -- e
+ }
+
+ --
+ -- Representation of RSA private key with information for the CRT
+ -- algorithm.
+ --
+ RSAPrivateKey ::= SEQUENCE {
+ version Version,
+ modulus INTEGER, -- n
+ publicExponent INTEGER, -- e
+ privateExponent INTEGER, -- d
+ prime1 INTEGER, -- p
+ prime2 INTEGER, -- q
+ exponent1 INTEGER, -- d mod (p-1)
+ exponent2 INTEGER, -- d mod (q-1)
+ coefficient INTEGER, -- (inverse of q) mod p
+ otherPrimeInfos OtherPrimeInfos OPTIONAL
+ }
+
+
+
+
+Moriarty, et al. Informational [Page 73]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+ Version ::= INTEGER { two-prime(0), multi(1) }
+ (CONSTRAINED BY
+ {-- version MUST
+ be multi if otherPrimeInfos present --})
+
+ OtherPrimeInfos ::= SEQUENCE SIZE(1..MAX) OF OtherPrimeInfo
+
+
+ OtherPrimeInfo ::= SEQUENCE {
+ prime INTEGER, -- ri
+ exponent INTEGER, -- di
+ coefficient INTEGER -- ti
+ }
+
+ --
+ -- AlgorithmIdentifier.parameters for id-RSAES-OAEP.
+ -- Note that the tags in this Sequence are explicit.
+ --
+ RSAES-OAEP-params ::= SEQUENCE {
+ hashAlgorithm [0] HashAlgorithm DEFAULT sha1,
+ maskGenAlgorithm [1] MaskGenAlgorithm DEFAULT mgf1SHA1,
+ pSourceAlgorithm [2] PSourceAlgorithm DEFAULT pSpecifiedEmpty
+ }
+
+ --
+ -- Identifier for default RSAES-OAEP algorithm identifier.
+ -- The DER encoding of this is in hexadecimal:
+ -- (0x)30 0D
+ -- 06 09
+ -- 2A 86 48 86 F7 0D 01 01 07
+ -- 30 00
+ -- Notice that the DER encoding of default values is "empty".
+ --
+
+ rSAES-OAEP-Default-Identifier RSAES-AlgorithmIdentifier ::= {
+ algorithm id-RSAES-OAEP,
+ parameters RSAES-OAEP-params : {
+ hashAlgorithm sha1,
+ maskGenAlgorithm mgf1SHA1,
+ pSourceAlgorithm pSpecifiedEmpty
+ }
+ }
+
+ RSAES-AlgorithmIdentifier ::= AlgorithmIdentifier {
+ {PKCS1Algorithms}
+ }
+
+ --
+
+
+
+Moriarty, et al. Informational [Page 74]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+ -- AlgorithmIdentifier.parameters for id-RSASSA-PSS.
+ -- Note that the tags in this Sequence are explicit.
+ --
+ RSASSA-PSS-params ::= SEQUENCE {
+ hashAlgorithm [0] HashAlgorithm DEFAULT sha1,
+ maskGenAlgorithm [1] MaskGenAlgorithm DEFAULT mgf1SHA1,
+ saltLength [2] INTEGER DEFAULT 20,
+ trailerField [3] TrailerField DEFAULT trailerFieldBC
+ }
+
+ TrailerField ::= INTEGER { trailerFieldBC(1) }
+
+ --
+ -- Identifier for default RSASSA-PSS algorithm identifier
+ -- The DER encoding of this is in hexadecimal:
+ -- (0x)30 0D
+ -- 06 09
+ -- 2A 86 48 86 F7 0D 01 01 0A
+ -- 30 00
+ -- Notice that the DER encoding of default values is "empty".
+ --
+ rSASSA-PSS-Default-Identifier RSASSA-AlgorithmIdentifier ::= {
+ algorithm id-RSASSA-PSS,
+ parameters RSASSA-PSS-params : {
+ hashAlgorithm sha1,
+ maskGenAlgorithm mgf1SHA1,
+ saltLength 20,
+ trailerField trailerFieldBC
+ }
+ }
+
+ RSASSA-AlgorithmIdentifier ::= AlgorithmIdentifier {
+ {PKCS1Algorithms}
+ }
+
+ --
+ -- Syntax for the EMSA-PKCS1-v1_5 hash identifier.
+ --
+ DigestInfo ::= SEQUENCE {
+ digestAlgorithm DigestAlgorithm,
+ digest OCTET STRING
+ }
+
+ DigestAlgorithm ::= AlgorithmIdentifier {
+ {PKCS1-v1-5DigestAlgorithms}
+ }
+
+ END
+
+
+
+Moriarty, et al. Informational [Page 75]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+Appendix D. Revision History of PKCS #1
+
+ Versions 1.0 - 1.5:
+
+ Versions 1.0 - 1.3 were distributed to participants in RSA Data
+ Security, Inc.'s Public-Key Cryptography Standards meetings in
+ February and March 1991.
+
+ Version 1.4 was part of the June 3, 1991 initial public release of
+ PKCS. Version 1.4 was published as NIST/OSI Implementors'
+ Workshop document SEC-SIG-91-18.
+
+ Version 1.5 incorporated several editorial changes, including
+ updates to the references and the addition of a revision history.
+ The following substantive changes were made:
+
+ * Section 10: "MD4 with RSA" signature and verification processes
+ were added.
+
+ * Section 11: md4WithRSAEncryption object identifier was added.
+
+ Version 1.5 was republished as [RFC2313] (which was later
+ obsoleted by [RFC2437]).
+
+ Version 2.0:
+
+ Version 2.0 incorporated major editorial changes in terms of the
+ document structure and introduced the RSAES-OAEP encryption
+ scheme. This version continued to support the encryption and
+ signature processes in version 1.5, although the hash algorithm
+ MD4 was no longer allowed due to cryptanalytic advances in the
+ intervening years. Version 2.0 was republished as [RFC2437]
+ (which was later obsoleted by [RFC3447]).
+
+ Version 2.1:
+
+ Version 2.1 introduced multi-prime RSA and the RSASSA-PSS
+ signature scheme with appendix along with several editorial
+ improvements. This version continued to support the schemes in
+ version 2.0. Version 2.1 was republished as [RFC3447].
+
+
+
+
+
+
+
+
+
+
+
+Moriarty, et al. Informational [Page 76]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+ Version 2.2:
+
+ Version 2.2 updates the list of allowed hashing algorithms to
+ align them with FIPS 180-4 [SHS], therefore adding SHA-224,
+ SHA-512/224, and SHA-512/256. The following substantive changes
+ were made:
+
+ * Object identifiers for sha224WithRSAEncryption,
+ sha512-224WithRSAEncryption, and sha512-256WithRSAEncryption
+ were added.
+
+ * This version continues to support the schemes in version 2.1.
+
+Appendix E. About PKCS
+
+ The Public-Key Cryptography Standards are specifications produced by
+ RSA Laboratories in cooperation with secure systems developers
+ worldwide for the purpose of accelerating the deployment of public-
+ key cryptography. First published in 1991 as a result of meetings
+ with a small group of early adopters of public-key technology, the
+ PKCS documents have become widely referenced and implemented.
+ Contributions from the PKCS series have become part of many formal
+ and de facto standards, including ANSI X9 and IEEE P1363 documents,
+ PKIX, Secure Electronic Transaction (SET), S/MIME, SSL/TLS, and
+ Wireless Application Protocol (WAP) / WAP Transport Layer Security
+ (WTLS).
+
+ Further development of most PKCS documents occurs through the IETF.
+ Suggestions for improvement are welcome.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moriarty, et al. Informational [Page 77]
+
+RFC 8017 PKCS #1 v2.2 November 2016
+
+
+Acknowledgements
+
+ This document is based on a contribution of RSA Laboratories, the
+ research center of RSA Security Inc.
+
+Authors' Addresses
+
+ Kathleen M. Moriarty (editor)
+ EMC Corporation
+ 176 South Street
+ Hopkinton, MA 01748
+ United States of America
+
+ Email: kathleen.moriarty@emc.com
+
+
+ Burt Kaliski
+ Verisign
+ 12061 Bluemont Way
+ Reston, VA 20190
+ United States of America
+
+ Email: bkaliski@verisign.com
+ URI: http://verisignlabs.com
+
+
+ Jakob Jonsson
+ Subset AB
+ Munkbrogtan 4
+ Stockholm SE-11127
+ Sweden
+
+ Phone: +46 8 428 687 43
+ Email: jakob.jonsson@subset.se
+
+ Andreas Rusch
+ RSA
+ 345 Queen Street
+ Brisbane, QLD 4000
+ Australia
+
+ Email: andreas.rusch@rsa.com
+
+
+
+
+
+
+
+
+
+Moriarty, et al. Informational [Page 78]
+