diff options
Diffstat (limited to 'doc/rfc/rfc2437.txt')
| -rw-r--r-- | doc/rfc/rfc2437.txt | 2187 |
1 files changed, 2187 insertions, 0 deletions
diff --git a/doc/rfc/rfc2437.txt b/doc/rfc/rfc2437.txt new file mode 100644 index 0000000..54f6d5d --- /dev/null +++ b/doc/rfc/rfc2437.txt @@ -0,0 +1,2187 @@ + + + + + + +Network Working Group B. Kaliski +Request for Comments: 2437 J. Staddon +Obsoletes: 2313 RSA Laboratories +Category: Informational October 1998 + + + PKCS #1: RSA Cryptography Specifications + Version 2.0 + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1998). All Rights Reserved. + +Table of Contents + + 1. Introduction.....................................2 + 1.1 Overview.........................................3 + 2. Notation.........................................3 + 3. Key types........................................5 + 3.1 RSA public key...................................5 + 3.2 RSA private key..................................5 + 4. Data conversion primitives.......................6 + 4.1 I2OSP............................................6 + 4.2 OS2IP............................................7 + 5. Cryptographic primitives.........................8 + 5.1 Encryption and decryption primitives.............8 + 5.1.1 RSAEP............................................8 + 5.1.2 RSADP............................................9 + 5.2 Signature and verification primitives...........10 + 5.2.1 RSASP1..........................................10 + 5.2.2 RSAVP1..........................................11 + 6. Overview of schemes.............................11 + 7. Encryption schemes..............................12 + 7.1 RSAES-OAEP......................................13 + 7.1.1 Encryption operation............................13 + 7.1.2 Decryption operation............................14 + 7.2 RSAES-PKCS1-v1_5................................15 + 7.2.1 Encryption operation............................17 + 7.2.2 Decryption operation............................17 + 8. Signature schemes with appendix.................18 + 8.1 RSASSA-PKCS1-v1_5...............................19 + 8.1.1 Signature generation operation..................20 + + + +Kaliski & Staddon Informational [Page 1] + +RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 + + + 8.1.2 Signature verification operation................21 + 9. Encoding methods................................22 + 9.1 Encoding methods for encryption.................22 + 9.1.1 EME-OAEP........................................22 + 9.1.2 EME-PKCS1-v1_5..................................24 + 9.2 Encoding methods for signatures with appendix...26 + 9.2.1 EMSA-PKCS1-v1_5.................................26 + 10. Auxiliary Functions.............................27 + 10.1 Hash Functions..................................27 + 10.2 Mask Generation Functions.......................28 + 10.2.1 MGF1............................................28 + 11. ASN.1 syntax....................................29 + 11.1 Key representation..............................29 + 11.1.1 Public-key syntax...............................30 + 11.1.2 Private-key syntax..............................30 + 11.2 Scheme identification...........................31 + 11.2.1 Syntax for RSAES-OAEP...........................31 + 11.2.2 Syntax for RSAES-PKCS1-v1_5.....................32 + 11.2.3 Syntax for RSASSA-PKCS1-v1_5....................33 + 12 Patent Statement................................33 + 12.1 Patent statement for the RSA algorithm..........34 + 13. Revision history................................35 + 14. References......................................35 + Security Considerations.........................37 + Acknowledgements................................37 + Authors' Addresses..............................38 + Full Copyright Statement........................39 + +1. Introduction + + This memo is the successor to RFC 2313. This document provides + recommendations for the implementation of public-key cryptography + based on the RSA algorithm [18], covering the following aspects: + + -cryptographic primitives + -encryption schemes + -signature schemes with appendix + -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 draft standards + currently being developed by the ANSI X9F1 [1] and IEEE P1363 working + groups [14]. This document supersedes PKCS #1 version 1.5 [20]. + + + + +Kaliski & Staddon Informational [Page 2] + +RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 + + + Editor's note. It is expected that subsequent versions of PKCS #1 may + cover other aspects of the RSA algorithm such as key size, key + generation, key validation, and signature schemes with message + recovery. + +1.1 Overview + + The organization of this document is as follows: + + -Section 1 is an introduction. + -Section 2 defines some notation used in this document. + -Section 3 defines the RSA public and private key types. + -Sections 4 and 5 define several primitives, or basic mathematical + operations. Data conversion primitives are in Section 4, and + cryptographic primitives (encryption-decryption, + signature-verification) are in Section 5. + -Section 6, 7 and 8 deal with the encryption and signature schemes + in this document. Section 6 gives an overview. Section 7 defines + an OAEP-based [2] encryption scheme along with the method found + in PKCS #1 v1.5. Section 8 defines a signature scheme with + appendix; the method is identical to that of PKCS #1 v1.5. + -Section 9 defines the encoding methods for the encryption and + signature schemes in Sections 7 and 8. + -Section 10 defines the hash functions and the mask generation + function used in this document. + -Section 11 defines the ASN.1 syntax for the keys defined in + Section 3 and the schemes gives in Sections 7 and 8. + -Section 12 outlines the revision history of PKCS #1. + -Section 13 contains references to other publications and + standards. + +2. Notation + + (n, e) RSA public key + + c ciphertext representative, an integer between 0 and n-1 + + C ciphertext, an octet string + + d private exponent + + dP p's exponent, a positive integer such that: + e(dP)\equiv 1 (mod(p-1)) + + dQ q's exponent, a positive integer such that: + e(dQ)\equiv 1 (mod(q-1)) + + e public exponent + + + +Kaliski & Staddon Informational [Page 3] + +RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 + + + EM encoded message, an octet string + + emLen intended length in octets of an encoded message + + H hash value, an output of Hash + + Hash hash function + + hLen output length in octets of hash function Hash + + K RSA private key + + k length in octets of the modulus + + l intended length of octet string + + lcm(.,.) least common multiple of two + nonnegative integers + + m message representative, an integer between + 0 and n-1 + + M message, an octet string + + MGF mask generation function + + n modulus + + P encoding parameters, an octet string + + p,q prime factors of the modulus + + qInv CRT coefficient, a positive integer less + than p such: q(qInv)\equiv 1 (mod p) + + s signature representative, an integer + between 0 and n-1 + + S signature, an octet string + + x a nonnegative integer + + X an octet string corresponding to x + + \xor bitwise exclusive-or of two octet strings + + \lambda(n) lcm(p-1, q-1), where n = pq + + + + +Kaliski & Staddon Informational [Page 4] + +RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 + + + || concatenation operator + + ||.|| octet length operator + +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. + +3.1 RSA public key + + For the purposes of this document, an RSA public key consists of two + components: + + n, the modulus, a nonnegative integer + e, the public exponent, a nonnegative integer + + In a valid RSA public key, the modulus n is a product of two odd + primes p and q, and the public exponent e is an integer between 3 and + n-1 satisfying gcd (e, \lambda(n)) = 1, where \lambda(n) = lcm (p- + 1,q-1). A recommended syntax for interchanging RSA public keys + between implementations is given in Section 11.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 modulus, a nonnegative integer + d, the private exponent, a nonnegative integer + + 2. The second representation consists of a quintuple (p, q, dP, dQ, + qInv), where the components have the following meanings: + + p, the first factor, a nonnegative integer + q, the second factor, a nonnegative integer + dP, the first factor's exponent, a nonnegative integer + dQ, the second factor's exponent, a nonnegative integer + qInv, the CRT coefficient, a nonnegative integer + + In a valid RSA private key with the first representation, the modulus + n is the same as in the corresponding public key and is the product + of two odd primes p and q, and the private exponent d is a positive + + + +Kaliski & Staddon Informational [Page 5] + +RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 + + + integer less than n satisfying: + + ed \equiv 1 (mod \lambda(n)) + + where e is the corresponding public exponent and \lambda(n) is as + defined above. + + In a valid RSA private key with the second representation, the two + factors p and q are the prime factors of the modulus n, the exponents + dP and dQ are positive integers less than p and q respectively + satisfying + + e(dP)\equiv 1(mod(p-1)) + e(dQ)\equiv 1(mod(q-1)), + + and the CRT coefficient qInv is a positive integer less than p + satisfying: + + q(qInv)\equiv 1 (mod p). + + A recommended syntax for interchanging RSA private keys between + implementations, which includes components from both representations, + is given in Section 11.1.2; an implementation's internal + representation may differ. + +4. Data conversion primitives + + Two data conversion primitives are employed in the schemes defined in + this document: + + I2OSP: Integer-to-Octet-String primitive + 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, l) + + + + + +Kaliski & Staddon Informational [Page 6] + +RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 + + + Input: + x nonnegative integer to be converted + l intended length of the resulting octet string + + Output: + X corresponding octet string of length l; or + "integer too large" + + Steps: + + 1. If x>=256^l, output "integer too large" and stop. + + 2. Write the integer x in its unique l-digit representation base 256: + + x = x_{l-1}256^{l-1} + x_{l-2}256^{l-2} +... + x_1 256 + x_0 + + where 0 <= x_i < 256 (note that one or more leading digits will be + zero if x < 256^{l-1}). + + 3. Let the octet X_i have the value x_{l-i} for 1 <= i <= l. Output + the octet string: + + X = X_1 X_2 ... X_l. + +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_l be the octets of X from first to last, and + let x{l-i} have value X_i for 1<= i <= l. + + 2. Let x = x{l-1} 256^{l-1} + x_{l-2} 256^{l-2} +...+ x_1 256 + x_0. + + 3. Output x. + + + + + + + +Kaliski & Staddon Informational [Page 7] + +RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 + + +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 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. + + One pair of encryption and decryption primitives is employed in the + encryption schemes defined in this document and is specified here: + RSAEP/RSADP. RSAEP and RSADP involve the same mathematical operation, + with different keys as input. + + The primitives defined here are the same as in the draft IEEE P1363 + 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; + or "message representative out of range" + + Assumptions: public key (n, e) is valid + + Steps: + + + + +Kaliski & Staddon Informational [Page 8] + +RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 + + + 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) + -a quintuple (p, q, dP, dQ, qInv) + c ciphertext representative, an integer between 0 and n-1 + + Output: + m message representative, an integer between 0 and n-1; or + "ciphertext representative out of range" + + Assumptions: 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. If the first form (n, d) of K is used: + + 2.1 Let m = c^d mod n. Else, if the second form (p, q, dP, + dQ, qInv) of K is used: + + 2.2 Let m_1 = c^dP mod p. + + 2.3 Let m_2 = c^dQ mod q. + + 2.4 Let h = qInv ( m_1 - m_2 ) mod p. + + 2.5 Let m = m_2 + hq. + + 3. Output m. + + + + + + + + +Kaliski & Staddon Informational [Page 9] + +RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 + + +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: RSASP1/RSAVP1. + + The primitives defined here are the same as in the draft IEEE P1363 + 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) + + m message representative, an integer between 0 and n-1 + + Output: + s signature representative, an integer between 0 and + n-1, or "message representative out of range" + + Assumptions: + private key K 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. If the first form (n, d) of K is used: + + 2.1 Let s = m^d mod n. Else, if the second form (p, q, dP, + dQ, qInv) of K is used: + + + + +Kaliski & Staddon Informational [Page 10] + +RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 + + + 2.2 Let s_1 = m^dP mod p. + + 2.3 Let s_2 = m^dQ mod q. + + 2.4 Let h = qInv ( s_1 - s_2 ) mod p. + + 2.5 Let s = s_2 + hq. + + 3. Output S. + +5.2.2 RSAVP1 + + RSAVP1 ((n, e), s) + + Input: + (n, e) RSA public key + s signature representative, an integer between 0 and n-1 + + Output: + m message representative, an integer between 0 and n-1; + or "invalid" + + Assumptions: + public key (n, e) is valid + + Steps: + + 1. If the signature representative s is not between 0 and n-1, output + "invalid" 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 a key, + and 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 public + and private keys for a scheme operation. The specific additional + operations and other details are outside the scope of this document. + + + +Kaliski & Staddon Informational [Page 11] + +RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 + + + 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 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. + +7. Encryption schemes + + 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 public key, and the + decryption operation recovers the message from the ciphertext with + the recipient's corresponding 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 [21] 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 recommended for new applications; + RSAES-PKCS1-v1_5 is included only for compatibility with existing + applications, and is not recommended for new applications. + + The encryption schemes given here follow a general model similar to + that employed in IEEE P1363, by 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 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. + + + + + + + + +Kaliski & Staddon Informational [Page 12] + +RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 + + +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 (Section 9.1.1) EME-OAEP + is based on the method found in [2]. It is compatible with the IFES + scheme defined in the draft P1363 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-2- + 2hLen octets, where hLen is the length of the hash function output + for EME-OAEP and k is the length in octets of the recipient's RSA + modulus. Assuming that the hash function in EME-OAEP has appropriate + properties, and the key size is sufficiently large, RSAEP-OAEP + provides "plaintext-aware encryption," meaning that it is + computationally infeasible to obtain full or partial information + about a message from a ciphertext, and computationally infeasible to + generate a valid ciphertext without knowing the corresponding + message. Therefore, a chosen-ciphertext attack is ineffective + against a plaintext-aware encryption scheme such as RSAES-OAEP. + + Both the encryption and the decryption operations of RSAES-OAEP take + the value of the parameter string P as input. In this version of PKCS + #1, P is an octet string that is specified explicitly. See Section + 11.2.1 for the relevant ASN.1 syntax. We briefly note that to receive + the full security benefit of RSAES-OAEP, it should not be used in a + protocol involving RSAES-PKCS1-v1_5. It is possible that in a + protocol on which both encryption schemes are present, an adaptive + chosen ciphertext attack such as [4] would be useful. + + Both the encryption and the decryption operations of RSAES-OAEP take + the value of the parameter string P as input. In this version of PKCS + #1, P is an octet string that is specified explicitly. See Section + 11.2.1 for the relevant ASN.1 syntax. + +7.1.1 Encryption operation + + RSAES-OAEP-ENCRYPT ((n, e), M, P) + + Input: + (n, e) recipient's RSA public key + + M message to be encrypted, an octet string of length at + most k-2-2hLen, where k is the length in octets of the + modulus n and hLen is the length in octets of the hash + function output for EME-OAEP + + P encoding parameters, an octet string that may be empty + + + + + +Kaliski & Staddon Informational [Page 13] + +RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 + + + Output: + C ciphertext, an octet string of length k; or "message too + long" + + Assumptions: public key (n, e) is valid + + Steps: + + 1. Apply the EME-OAEP encoding operation (Section 9.1.1.2) to the + message M and the encoding parameters P to produce an encoded message + EM of length k-1 octets: + + EM = EME-OAEP-ENCODE (M, P, k-1) + + If the encoding operation outputs "message too long," then output + "message too long" and stop. + + 2. Convert the encoded message EM to an integer message + representative m: m = OS2IP (EM) + + 3. Apply the RSAEP encryption primitive (Section 5.1.1) to the public + key (n, e) and the message representative m to produce an integer + ciphertext representative c: + + c = RSAEP ((n, e), m) + + 4. Convert the ciphertext representative c to a ciphertext C of + length k octets: C = I2OSP (c, k) + + 5. Output the ciphertext C. + +7.1.2 Decryption operation + + RSAES-OAEP-DECRYPT (K, C, P) + + 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 modulus n + P encoding parameters, an octet string that may be empty + + Output: + M message, an octet string of length at most k-2-2hLen, + where hLen is the length in octets of the hash + function output for EME-OAEP; or "decryption error" + + + + + + +Kaliski & Staddon Informational [Page 14] + +RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 + + + Steps: + + 1. If the length of the ciphertext C is not k octets, output + "decryption error" and stop. + + 2. Convert the ciphertext C to an integer ciphertext representative + c: c = OS2IP (C). + + 3. Apply the RSADP decryption primitive (Section 5.1.2) to the + private key K and the ciphertext representative c to produce an + integer message representative m: + + m = RSADP (K, c) + + If RSADP outputs "ciphertext out of range," then output "decryption + error" and stop. + + 4. Convert the message representative m to an encoded message EM of + length k-1 octets: EM = I2OSP (m, k-1) + + If I2OSP outputs "integer too large," then output "decryption error" + and stop. + + 5. Apply the EME-OAEP decoding operation to the encoded message EM + and the encoding parameters P to recover a message M: + + M = EME-OAEP-DECODE (EM, P) + + If the decoding operation outputs "decoding error," then output + "decryption error" and stop. + + 6. Output the message M. + + Note. It is important that the error messages output in steps 4 and 5 + be the same, otherwise an adversary may be able to extract useful + information from the type of error message received. Error message + information is used to mount a chosen-ciphertext attack on PKCS #1 + v1.5 encrypted messages in [4]. + +7.2 RSAES-PKCS1-v1_5 + + RSAES-PKCS1-v1_5 combines the RSAEP and RSADP primitives with the + EME-PKCS1-v1_5 encoding method. It is the same as the encryption + scheme in PKCS #1 v1.5. RSAES-PKCS1-v1_5 can operate on messages of + length up to k-11 octets, although care should be taken to avoid + certain attacks on low-exponent RSA due to Coppersmith, et al. when + long messages are encrypted (see the third bullet in the notes below + and [7]). + + + +Kaliski & Staddon Informational [Page 15] + +RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 + + + RSAES-PKCS1-v1_5 does not provide "plaintext aware" encryption. In + particular, it is possible to generate valid 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 [4]. Therefore, if RSAES-PKCS1-v1_5 is to be used, + certain easily implemented countermeasures should be taken to thwart + the attack found in [4]. 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 can all be + effective countermeasures and don't involve changes to a PKCS #1 + v1.5-based protocol. These and other countermeasures are discussed in + [5]. + + Notes. The following passages describe some security recommendations + pertaining to the use of RSAES-PKCS1-v1_5. Recommendations from + version 1.5 of this document are included as well as new + recommendations motivated by cryptanalytic advances made in the + intervening years. + + -It is recommended that the pseudorandom octets in EME-PKCS1-v1_5 be + generated independently for each encryption process, especially if + the same data is input to more than one encryption process. Hastad's + results [13] are one motivation for this recommendation. + + -The padding string PS in EME-PKCS1-v1_5 is at least eight octets + long, which is a security condition for public-key operations that + prevents an attacker from recovering data by trying all possible + encryption blocks. + + -The pseudorandom octets can also help thwart an attack due to + Coppersmith et al. [7] 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 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 + RSAEP-OAEP scheme overcomes the attack. + + + + + + +Kaliski & Staddon Informational [Page 16] + +RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 + + +7.2.1 Encryption operation + + RSAES-PKCS1-V1_5-ENCRYPT ((n, e), M) + + Input: + (n, e) recipient's RSA public key + M message to be encrypted, an octet string of length at + most k-11 octets, where k is the length in octets of the + modulus n + + Output: + C ciphertext, an octet string of length k; or "message too + long" + + Steps: + + 1. Apply the EME-PKCS1-v1_5 encoding operation (Section 9.1.2.1) to + the message M to produce an encoded message EM of length k-1 octets: + + EM = EME-PKCS1-V1_5-ENCODE (M, k-1) + + If the encoding operation outputs "message too long," then output + "message too long" and stop. + + 2. Convert the encoded message EM to an integer message + representative m: m = OS2IP (EM) + + 3. Apply the RSAEP encryption primitive (Section 5.1.1) to the public + key (n, e) and the message representative m to produce an integer + ciphertext representative c: c = RSAEP ((n, e), m) + + 4. Convert the ciphertext representative c to a ciphertext C of + length k octets: C = I2OSP (c, k) + + 5. 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 modulus n + + Output: + M message, an octet string of length at most k-11; or + "decryption error" + + + +Kaliski & Staddon Informational [Page 17] + +RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 + + + Steps: + + 1. If the length of the ciphertext C is not k octets, output + "decryption error" and stop. + + 2. Convert the ciphertext C to an integer ciphertext representative + c: c = OS2IP (C). + + 3. Apply the RSADP decryption primitive to the 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 out of range," then output "decryption + error" and stop. + + 4. Convert the message representative m to an encoded message EM of + length k-1 octets: EM = I2OSP (m, k-1) + + If I2OSP outputs "integer too large," then output "decryption error" + and stop. + + 5. Apply the EME-PKCS1-v1_5 decoding operation to the encoded message + EM to recover a message M: M = EME-PKCS1-V1_5-DECODE (EM). + + If the decoding operation outputs "decoding error," then output + "decryption error" and stop. + + 6. Output the message M. + + Note. It is important that only one type of error message is output + by EME-PKCS1-v1_5, as ensured by steps 4 and 5. If this is not done, + then an adversary may be able to use information extracted form the + type of error message received to mount a chosen-ciphertext attack + such as the one found in [4]. + +8. Signature schemes with appendix + + 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 private key, and the signature verification operation + verifies the signature on the message with the signer's corresponding + 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. + + + + +Kaliski & Staddon Informational [Page 18] + +RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 + + + A signature scheme with appendix can be employed in a variety of + applications. For instance, X.509 [6] employs such a scheme to + authenticate the content of a certificate; the signature scheme with + appendix defined here would be a suitable signature algorithm in that + context. A related signature scheme could be employed in PKCS #7 + [21], 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. + + One signature scheme with appendix is specified in this document: + RSASSA-PKCS1-v1_5. + + The signature scheme with appendix given here follows a general model + similar to that employed in IEEE P1363, by 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 then + applied to the message representative to produce the signature. 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. The message encoding operation + is again applied to the message, and the result is compared to the + recovered octet string. If there is a match, the signature is + considered valid. (Note that this approach assumes that the signature + and verification primitives have the message-recovery form and the + encoding method is deterministic, as is the case for RSASP1/RSAVP1 + and EMSA-PKCS1-v1_5. The signature generation and verification + operations have a different form in P1363 for other primitives and + encoding methods.) + + Editor's note. RSA Laboratories is investigating the possibility of + including a scheme based on the PSS encoding methods specified in + [3], which would be recommended for new applications. + +8.1 RSASSA-PKCS1-v1_5 + + RSASSA-PKCS1-v1_5 combines the RSASP1 and RSAVP1 primitives with the + EME-PKCS1-v1_5 encoding method. It is compatible with the IFSSA + scheme defined in the draft P1363 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 P1363). + 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 message encoding method. + + + + + + +Kaliski & Staddon Informational [Page 19] + +RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 + + + Assuming that the hash function in EMSA-PKCS1-v1_5 has appropriate + properties and the key size is sufficiently large, RSASSA-PKCS1-v1_5 + provides secure signatures, meaning that it is computationally + infeasible to generate a signature without knowing the private key, + and computationally infeasible to find a message with a given + signature or two messages with the same signature. Also, in the + encoding method EMSA-PKCS1-v1_5, a hash function identifier is + embedded in the encoding. Because of this feature, an adversary must + invert or 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. + +8.1.1 Signature generation operation + + RSASSA-PKCS1-V1_5-SIGN (K, M) + Input: + K signer's RSA private ke + 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 modulus n; "message too long" or + "modulus too short" + Steps: + + 1. Apply the EMSA-PKCS1-v1_5 encoding operation (Section 9.2.1) to + the message M to produce an encoded message EM of length k-1 octets: + + EM = EMSA-PKCS1-V1_5-ENCODE (M, k-1) + + If the encoding operation outputs "message too long," then output + "message too long" and stop. If the encoding operation outputs + "intended encoded message length too short" then output "modulus too + short". + + 2. Convert the encoded message EM to an integer message + representative m: m = OS2IP (EM) + + 3. Apply the RSASP1 signature primitive (Section 5.2.1) to the + private key K and the message representative m to produce an integer + signature representative s: s = RSASP1 (K, m) + + 4. Convert the signature representative s to a signature S of length + k octets: S = I2OSP (s, k) + + 5. Output the signature S. + + + + + +Kaliski & Staddon Informational [Page 20] + +RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 + + +8.1.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 + S signature to be verified, an octet string of length k, + where k is the length in octets of the modulus n + + Output: "valid signature," "invalid signature," or "message too + long", or "modulus too short" + + Steps: + + 1. If the length of the signature S is not k octets, output "invalid + signature" and stop. + + 2. Convert the signature S to an integer signature representative s: + + s = OS2IP (S) + + 3. Apply the RSAVP1 verification primitive (Section 5.2.2) to the + public key (n, e) and the signature representative s to produce an + integer message representative m: + + m = RSAVP1 ((n, e), s) If RSAVP1 outputs "invalid" + then output "invalid signature" and stop. + + 4. Convert the message representative m to an encoded message EM of + length k-1 octets: EM = I2OSP (m, k-1) + + If I2OSP outputs "integer too large," then output "invalid signature" + and stop. + + 5. Apply the EMSA-PKCS1-v1_5 encoding operation (Section 9.2.1) to + the message M to produce a second encoded message EM' of length k-1 + octets: + + EM' = EMSA-PKCS1-V1_5-ENCODE (M, k-1) + + If the encoding operation outputs "message too long," then output + "message too long" and stop. If the encoding operation outputs + "intended encoded message length too short" then output "modulus too + short". + + + + + + +Kaliski & Staddon Informational [Page 21] + +RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 + + + 6. Compare the encoded message EM and the second encoded message EM'. + If they are the same, output "valid signature"; otherwise, output + "invalid signature." + +9. Encoding methods + + Encoding methods consist of operations that map between octet string + messages and integer message representatives. + + Two types of encoding method are considered in this document: + encoding methods for encryption, encoding methods for signatures with + appendix. + +9.1 Encoding methods for encryption + + An encoding method for encryption consists of an encoding operation + and a decoding operation. An encoding operation maps a message M to a + message representative EM of a specified length; the decoding + operation maps a message representative EM back to a message. The + encoding and decoding operations are inverses. + + The message representative EM will typically have some structure that + can be verified by the decoding operation; the decoding operation + will output "decoding error" if the structure is not present. The + encoding operation may also introduce some randomness, so that + different applications of the encoding operation to the same message + will produce different representatives. + + Two encoding methods for encryption are employed in the encryption + schemes and are specified here: EME-OAEP and EME-PKCS1-v1_5. + +9.1.1 EME-OAEP + + This encoding method is parameterized by the choice of hash function + and mask generation function. Suggested hash and mask generation + functions are given in Section 10. This encoding method is based on + the method found in [2]. + +9.1.1.1 Encoding operation + + EME-OAEP-ENCODE (M, P, emLen) + + Options: + Hash hash function (hLen denotes the length in octet of the + hash function output) + MGF mask generation function + + + + + +Kaliski & Staddon Informational [Page 22] + +RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 + + + Input: + M message to be encoded, an octet string of length at most + emLen-1-2hLen + P encoding parameters, an octet string + emLen intended length in octets of the encoded message, at least + 2hLen+1 + + Output: + EM encoded message, an octet string of length emLen; + "message too long" or "parameter string too long" + + Steps: + + 1. If the length of P is greater than the input limitation for the + hash function (2^61-1 octets for SHA-1) then output "parameter string + too long" and stop. + + 2. If ||M|| > emLen-2hLen-1 then output "message too long" and stop. + + 3. Generate an octet string PS consisting of emLen-||M||-2hLen-1 zero + octets. The length of PS may be 0. + + 4. Let pHash = Hash(P), an octet string of length hLen. + + 5. Concatenate pHash, PS, the message M, and other padding to form a + data block DB as: DB = pHash || PS || 01 || M + + 6. Generate a random octet string seed of length hLen. + + 7. Let dbMask = MGF(seed, emLen-hLen). + + 8. Let maskedDB = DB \xor dbMask. + + 9. Let seedMask = MGF(maskedDB, hLen). + + 10. Let maskedSeed = seed \xor seedMask. + + 11. Let EM = maskedSeed || maskedDB. + + 12. Output EM. + +9.1.1.2 Decoding operation EME-OAEP-DECODE (EM, P) + + Options: + Hash hash function (hLen denotes the length in octet of the hash + function output) + + MGF mask generation function + + + +Kaliski & Staddon Informational [Page 23] + +RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 + + + Input: + + EM encoded message, an octet string of length at least 2hLen+1 + P encoding parameters, an octet string + + Output: + M recovered message, an octet string of length at most + ||EM||-1-2hLen; or "decoding error" + + Steps: + + 1. If the length of P is greater than the input limitation for the + hash function (2^61-1 octets for SHA-1) then output "parameter string + too long" and stop. + + 2. If ||EM|| < 2hLen+1, then output "decoding error" and stop. + + 3. Let maskedSeed be the first hLen octets of EM and let maskedDB be + the remaining ||EM|| - hLen octets. + + 4. Let seedMask = MGF(maskedDB, hLen). + + 5. Let seed = maskedSeed \xor seedMask. + + 6. Let dbMask = MGF(seed, ||EM|| - hLen). + + 7. Let DB = maskedDB \xor dbMask. + + 8. Let pHash = Hash(P), an octet string of length hLen. + + 9. Separate DB into an octet string pHash' consisting of the first + hLen octets of DB, a (possibly empty) octet string PS consisting of + consecutive zero octets following pHash', and a message M as: + + DB = pHash' || PS || 01 || M + + If there is no 01 octet to separate PS from M, output "decoding + error" and stop. + + 10. If pHash' does not equal pHash, output "decoding error" and stop. + + 11. Output M. + +9.1.2 EME-PKCS1-v1_5 + + This encoding method is the same as in PKCS #1 v1.5, Section 8: + Encryption Process. + + + + +Kaliski & Staddon Informational [Page 24] + +RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 + + +9.1.2.1 Encoding operation + + EME-PKCS1-V1_5-ENCODE (M, emLen) + + Input: + M message to be encoded, an octet string of length at most + emLen-10 + emLen intended length in octets of the encoded message + + Output: + EM encoded message, an octet string of length emLen; or + "message too long" + + Steps: + + 1. If the length of the message M is greater than emLen - 10 octets, + output "message too long" and stop. + + 2. Generate an octet string PS of length emLen-||M||-2 consisting of + pseudorandomly generated nonzero octets. The length of PS will be at + least 8 octets. + + 3. Concatenate PS, the message M, and other padding to form the + encoded message EM as: + + EM = 02 || PS || 00 || M + + 4. Output EM. + +9.1.2.2 Decoding operation + + EME-PKCS1-V1_5-DECODE (EM) + + Input: + EM encoded message, an octet string of length at least 10 + + Output: + M recovered message, an octet string of length at most + ||EM||-10; or "decoding error" + + Steps: + + 1. If the length of the encoded message EM is less than 10, output + "decoding error" and stop. + + 2. Separate the encoded message EM into an octet string PS consisting + of nonzero octets and a message M as: EM = 02 || PS || 00 || M. + + + + +Kaliski & Staddon Informational [Page 25] + +RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 + + + If the first octet of EM is not 02, or if there is no 00 octet to + separate PS from M, output "decoding error" and stop. + + 3. If the length of PS is less than 8 octets, output "decoding error" + and stop. + + 4. Output M. + +9.2 Encoding methods for signatures with appendix + + An encoding method for signatures with appendix, for the purposes of + this document, consists of an encoding operation. An encoding + operation maps a message M to a message representative EM of a + specified length. (In future versions of this document, encoding + methods may be added that also include a decoding operation.) + + One encoding method for signatures with appendix is employed in the + encryption schemes and is specified here: EMSA-PKCS1-v1_5. + +9.2.1 EMSA-PKCS1-v1_5 + + This encoding method only has an encoding operation. + + EMSA-PKCS1-v1_5-ENCODE (M, emLen) + + Option: + Hash hash function (hLen denotes the length in octet of the hash + function output) + + Input: + M message to be encoded + emLen intended length in octets of the encoded message, at least + ||T|| + 10, where T is the DER encoding of a certain value + computed during the encoding operation + + Output: + EM encoded message, an octet string of length emLen; or "message + too long" or "intended encoded message length too short" + + 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," then output "message + too long". + + + +Kaliski & Staddon Informational [Page 26] + +RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 + + + 2. Encode the algorithm ID for the hash function and the hash value + into an ASN.1 value of type DigestInfo (see Section 11) with the + Distinguished Encoding Rules (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. + + 3. If emLen is less than ||T|| + 10 then output "intended encoded + message length too short". + + 4. Generate an octet string PS consisting of emLen-||T||-2 octets + with value FF (hexadecimal). 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 = 01 || PS || 00 || T + + 6. Output EM. + +10. Auxiliary Functions + + This section specifies the hash functions and the mask generation + functions that are mentioned in the encoding methods (Section 9). + +10.1 Hash Functions + + Hash functions are used in the operations contained in Sections 7, 8 + 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, 8 and 9 + should 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. The + property of collision resistance is especially desirable for RSASSA- + PKCS1-v1_5, as it makes it infeasible to forge signatures. In + addition to the requirements, the hash function should yield a mask + generation function (Section 10.2) with pseudorandom output. + + + + + + +Kaliski & Staddon Informational [Page 27] + +RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 + + + Three hash functions are recommended for the encoding methods in this + document: MD2 [15], MD5 [17], and SHA-1 [16]. For the EME-OAEP + encoding method, only SHA-1 is recommended. For the EMSA-PKCS1-v1_5 + encoding method, SHA-1 is recommended for new applications. MD2 and + MD5 are recommended only for compatibility with existing applications + based on PKCS #1 v1.5. + + The hash functions themselves are not defined here; readers are + referred to the appropriate references ([15], [17] and [16]). + + Note. Version 1.5 of this document also allowed for the use of MD4 in + signature schemes. The cryptanalysis of MD4 has progressed + significantly in the intervening years. For example, Dobbertin [10] + demonstrated how to find collisions for MD4 and that the first two + rounds of MD4 are not one-way [11]. Because of these results and + others (e.g. [9]), MD4 is no longer recommended. There have also been + advances in the cryptanalysis of MD2 and MD5, although not enough to + warrant removal from existing applications. Rogier and Chauvaud [19] + demonstrated how to find collisions in a modified version of MD2. No + one has demonstrated how to find collisions for the full MD5 + algorithm, although partial results have been found (e.g. [8]). For + new applications, to address these concerns, SHA-1 is preferred. + +10.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, that is, if the + seed to the function is unknown, it should be infeasible to + distinguish the output from a truly random string. The plaintext- + awareness of RSAES-OAEP 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 recommended for the encoding methods + in this document, and is defined here: MGF1, which is based on a hash + function. Future versions of this document may define other mask + generation functions. + +10.2.1 MGF1 + + MGF1 is a Mask Generation Function based on a hash function. + + MGF1 (Z, l) + + + +Kaliski & Staddon Informational [Page 28] + +RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 + + + Options: + Hash hash function (hLen denotes the length in octets of the hash + function output) + + Input: + Z seed from which mask is generated, an octet string + l intended length in octets of the mask, at most 2^32(hLen) + + Output: + mask mask, an octet string of length l; or "mask too long" + + Steps: + + 1.If l > 2^32(hLen), output "mask too long" and stop. + + 2.Let T be the empty octet string. + + 3.For counter from 0 to \lceil{l / hLen}\rceil-1, do the following: + + a.Convert counter to an octet string C of length 4 with the primitive + I2OSP: C = I2OSP (counter, 4) + + b.Concatenate the hash of the seed Z and C to the octet string T: T = + T || Hash (Z || C) + + 4.Output the leading l octets of T as the octet string mask. + +11. ASN.1 syntax + +11.1 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 [22], and PKCS #12 [23]. + + The object identifier rsaEncryption identifies RSA public and private + keys as defined in Sections 11.1.1 and 11.1.2. The parameters field + associated with this OID in an AlgorithmIdentifier shall have type + NULL. + + rsaEncryption OBJECT IDENTIFIER ::= {pkcs-1 1} + + All of the definitions in this section are the same as in PKCS #1 + v1.5. + + + + + + +Kaliski & Staddon Informational [Page 29] + +RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 + + +11.1.1 Public-key syntax + + An RSA public key should be represented with the ASN.1 type + RSAPublicKey: + + RSAPublicKey::=SEQUENCE{ + modulus INTEGER, -- n + publicExponent INTEGER -- e } + + (This type is specified in X.509 and is retained here for + compatibility.) + + The fields of type RSAPublicKey have the following meanings: + -modulus is the modulus n. + -publicExponent is the public exponent e. + +11.1.2 Private-key syntax + + An RSA private key should be represented with 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 } + + Version ::= INTEGER + + The fields of type RSAPrivateKey have the following meanings: + + -version is the version number, for compatibility with future + revisions of this document. It shall be 0 for this version of the + document. + -modulus is the modulus n. + -publicExponent is the public exponent e. + -privateExponent is the private exponent d. + -prime1 is the prime factor p of n. + -prime2 is the prime factor q of n. + -exponent1 is d mod (p-1). + -exponent2 is d mod (q-1). + -coefficient is the Chinese Remainder Theorem coefficient q-1 mod p. + + + + +Kaliski & Staddon Informational [Page 30] + +RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 + + +11.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. + +11.2.1 Syntax for 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 an + AlgorithmIdentifier shall have type RSAEP-OAEP-params: + + RSAES-OAEP-params ::= SEQUENCE { + hashFunc [0] AlgorithmIdentifier {{oaepDigestAlgorithms}} + DEFAULT sha1Identifier, + maskGenFunc [1] AlgorithmIdentifier {{pkcs1MGFAlgorithms}} + DEFAULT mgf1SHA1Identifier, + pSourceFunc [2] AlgorithmIdentifier + {{pkcs1pSourceAlgorithms}} + DEFAULT pSpecifiedEmptyIdentifier } + + The fields of type RSAES-OAEP-params have the following meanings: + + -hashFunc identifies the hash function. It shall be an algorithm ID + with an OID in the set oaepDigestAlgorithms, which for this version + shall consist of id-sha1, identifying the SHA-1 hash function. The + parameters field for id-sha1 shall have type NULL. + + oaepDigestAlgorithms ALGORITHM-IDENTIFIER ::= { + {NULL IDENTIFIED BY id-sha1} } + + id-sha1 OBJECT IDENTIFIER ::= + {iso(1) identified-organization(3) oiw(14) secsig(3) + algorithms(2) 26} + + + The default hash function is SHA-1: + sha1Identifier ::= AlgorithmIdentifier {id-sha1, NULL} + + -maskGenFunc 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 Section 10.2.1). The parameters field for + + + +Kaliski & Staddon Informational [Page 31] + +RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 + + + id-mgf1 shall have type AlgorithmIdentifier, identifying the hash + function on which MGF1 is based, where the OID for the hash function + shall be in the set oaepDigestAlgorithms. + + pkcs1MGFAlgorithms ALGORITHM-IDENTIFIER ::= { + {AlgorithmIdentifier {{oaepDigestAlgorithms}} IDENTIFIED + BY id-mgf1} } + + id-mgf1 OBJECT IDENTIFIER ::= {pkcs-1 8} + + The default mask generation function is MGF1 with SHA-1: + + mgf1SHA1Identifier ::= AlgorithmIdentifier { + id-mgf1, sha1Identifier } + + -pSourceFunc identifies the source (and possibly the value) of the + encoding parameters P. 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 encoding parameters are specified + explicitly. The parameters field for id-pSpecified shall have type + OCTET STRING, containing the encoding parameters. + + pkcs1pSourceAlgorithms ALGORITHM-IDENTIFIER ::= { + {OCTET STRING IDENTIFIED BY id-pSpecified} } + + id-pSpecified OBJECT IDENTIFIER ::= {pkcs-1 9} + + The default encoding parameters is an empty string (so that pHash in + EME-OAEP will contain the hash of the empty string): + + pSpecifiedEmptyIdentifier ::= AlgorithmIdentifier { + id-pSpecified, OCTET STRING SIZE (0) } + + 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 ::= AlgorithmIdentifier { + id-RSAES-OAEP, + {sha1Identifier, + mgf1SHA1Identifier, + pSpecifiedEmptyIdentifier } } + +11.2.2 Syntax for RSAES-PKCS1-v1_5 + + The object identifier rsaEncryption (Section 11.1) identifies the + RSAES-PKCS1-v1_5 encryption scheme. The parameters field associated + with this OID in an AlgorithmIdentifier shall have type NULL. This is + the same as in PKCS #1 v1.5. + + + +Kaliski & Staddon Informational [Page 32] + +RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 + + + RsaEncryption OBJECT IDENTIFIER ::= {PKCS-1 1} + +11.2.3 Syntax for RSASSA-PKCS1-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 or SHA-1. 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 an AlgorithmIdentifier shall have type + NULL. + + If the hash function to be used is MD2, then the OID should be: + + md2WithRSAEncryption ::= {PKCS-1 2} + + If the hash function to be used is MD5, then the OID should be: + + md5WithRSAEncryption ::= {PKCS-1 4} + + If the hash function to be used is SHA-1, then the OID should be: + + sha1WithRSAEncryption ::= {pkcs-1 5} + + In the digestInfo type mentioned in Section 9.2.1 the OIDS for the + digest algorithm are the following: + + id-SHA1 OBJECT IDENTIFIER ::= + {iso(1) identified-organization(3) oiw(14) secsig(3) + algorithms(2) 26 } + + md2 OBJECT IDENTIFIER ::= + {iso(1) member-body(2) US(840) rsadsi(113549) + digestAlgorithm(2) 2} + + md5 OBJECT IDENTIFIER ::= + {iso(1) member-body(2) US(840) rsadsi(113549) + digestAlgorithm(2) 5} + + The parameters field of the digest algorithm has ASN.1 type NULL for + these OIDs. + +12. Patent statement + + The Internet Standards Process as defined in RFC 1310 requires a + written statement from the Patent holder that a license will be made + available to applicants under reasonable terms and conditions prior + to approving a specification as a Proposed, Draft or Internet + Standard. + + + +Kaliski & Staddon Informational [Page 33] + +RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 + + + The Internet Society, Internet Architecture Board, Internet + Engineering Steering Group and the Corporation for National Research + Initiatives take no position on the validity or scope of the + following patents and patent applications, nor on the appropriateness + of the terms of the assurance. The Internet Society and other groups + mentioned above have not made any determination as to any other + intellectual property rights which may apply to the practice of this + standard. Any further consideration of these matters is the user's + responsibility. + +12.1 Patent statement for the RSA algorithm + + The Massachusetts Institute of Technology has granted RSA Data + Security, Inc., exclusive sub-licensing rights to the following + patent issued in the United States: + + Cryptographic Communications System and Method ("RSA"), No. 4,405,829 + + RSA Data Security, Inc. has provided the following statement with + regard to this patent: + + It is RSA's business practice to make licenses to its patents + available on reasonable and nondiscriminatory terms. Accordingly, RSA + is willing, upon request, to grant non-exclusive licenses to such + patent on reasonable and non-discriminatory terms and conditions to + those who respect RSA's intellectual property rights and subject to + RSA's then current royalty rate for the patent licensed. The royalty + rate for the RSA patent is presently set at 2% of the licensee's + selling price for each product covered by the patent. Any requests + for license information may be directed to: + + Director of Licensing + RSA Data Security, Inc. + 2955 Campus Drive + Suite 400 + San Mateo, CA 94403 + + A license under RSA's patent(s) does not include any rights to know- + how or other technical information or license under other + intellectual property rights. Such license does not extend to any + activities which constitute infringement or inducement thereto. A + licensee must make his own determination as to whether a license is + necessary under patents of others. + + + + + + + + +Kaliski & Staddon Informational [Page 34] + +RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 + + +13. Revision history + + Versions 1.0-1.3 + + 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 + + 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 + + Version 1.5 incorporates 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 2.0 [DRAFT] + + Version 2.0 incorporates major editorial changes in terms of the + document structure, and introduces the RSAEP-OAEP encryption scheme. + This version continues to support the encryption and signature + processes in version 1.5, although the hash algorithm MD4 is no + longer allowed due to cryptanalytic advances in the intervening + years. + +14. References + + [1] ANSI, ANSI X9.44: Key Management Using Reversible Public Key + Cryptography for the Financial Services Industry. Work in + Progress. + + [2] M. Bellare and P. Rogaway. Optimal Asymmetric Encryption - How to + Encrypt with RSA. In Advances in Cryptology-Eurocrypt '94, pp. + 92-111, Springer-Verlag, 1994. + + [3] M. Bellare and P. Rogaway. The Exact Security of Digital + Signatures - How to Sign with RSA and Rabin. In Advances in + Cryptology-Eurocrypt '96, pp. 399-416, Springer-Verlag, 1996. + + + + +Kaliski & Staddon Informational [Page 35] + +RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 + + + [4] D. Bleichenbacher. Chosen Ciphertext Attacks against Protocols + Based on the RSA Encryption Standard PKCS #1. To appear in + Advances in Cryptology-Crypto '98. + + [5] D. Bleichenbacher, B. Kaliski and J. Staddon. Recent Results on + PKCS #1: RSA Encryption Standard. RSA Laboratories' Bulletin, + Number 7, June 24, 1998. + + [6] CCITT. Recommendation X.509: The Directory-Authentication + Framework. 1988. + + [7] D. Coppersmith, M. Franklin, J. Patarin and M. Reiter. Low- + Exponent RSA with Related Messages. In Advances in Cryptology- + Eurocrypt '96, pp. 1-9, Springer-Verlag, 1996 + + [8] B. Den Boer and Bosselaers. Collisions for the Compression + Function of MD5. In Advances in Cryptology-Eurocrypt '93, pp + 293-304, Springer-Verlag, 1994. + + [9] B. den Boer, and A. Bosselaers. An Attack on the Last Two Rounds + of MD4. In Advances in Cryptology-Crypto '91, pp.194-203, + Springer-Verlag, 1992. + + [10] H. Dobbertin. Cryptanalysis of MD4. Fast Software Encryption. + Lecture Notes in Computer Science, Springer-Verlag 1996, pp. + 55-72. + + [11] H. Dobbertin. Cryptanalysis of MD5 Compress. Presented at the + rump session of Eurocrypt `96, May 14, 1996 + + [12] H. Dobbertin.The First Two Rounds of MD4 are Not One-Way. Fast + Software Encryption. Lecture Notes in Computer Science, + Springer-Verlag 1998, pp. 284-292. + + [13] J. Hastad. Solving Simultaneous Modular Equations of Low Degree. + SIAM Journal of Computing, 17, 1988, pp. 336-341. + + [14] IEEE. IEEE P1363: Standard Specifications for Public Key + Cryptography. Draft Version 4. + + [15] Kaliski, B., "The MD2 Message-Digest Algorithm", RFC 1319, April + 1992. + + [16] National Institute of Standards and Technology (NIST). FIPS + Publication 180-1: Secure Hash Standard. April 1994. + + [17] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April + 1992. + + + +Kaliski & Staddon Informational [Page 36] + +RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 + + + [18] R. Rivest, A. Shamir and L. Adleman. A Method for Obtaining + Digital Signatures and Public-Key Cryptosystems. Communications + of the ACM, 21(2), pp. 120-126, February 1978. + + [19] N. Rogier and P. Chauvaud. The Compression Function of MD2 is + not Collision Free. Presented at Selected Areas of Cryptography + `95. Carleton University, Ottawa, Canada. May 18-19, 1995. + + [20] RSA Laboratories. PKCS #1: RSA Encryption Standard. Version 1.5, + November 1993. + + [21] RSA Laboratories. PKCS #7: Cryptographic Message Syntax + Standard. Version 1.5, November 1993. + + [22] RSA Laboratories. PKCS #8: Private-Key Information Syntax + Standard. Version 1.2, November 1993. + + [23] RSA Laboratories. PKCS #12: Personal Information Exchange Syntax + Standard. Version 1.0, Work in Progress, April 1997. + +Security Considerations + + Security issues are discussed throughout this memo. + +Acknowledgements + + This document is based on a contribution of RSA Laboratories, a + division of RSA Data Security, Inc. Any substantial use of the text + from this document must acknowledge RSA Data Security, Inc. RSA Data + Security, Inc. requests that all material mentioning or referencing + this document identify this as "RSA Data Security, Inc. PKCS #1 + v2.0". + + + + + + + + + + + + + + + + + + + +Kaliski & Staddon Informational [Page 37] + +RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 + + +Authors' Addresses + + Burt Kaliski + RSA Laboratories East + 20 Crosby Drive + Bedford, MA 01730 + + Phone: (617) 687-7000 + EMail: burt@rsa.com + + + Jessica Staddon + RSA Laboratories West + 2955 Campus Drive + Suite 400 + San Mateo, CA 94403 + + Phone: (650) 295-7600 + EMail: jstaddon@rsa.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kaliski & Staddon Informational [Page 38] + +RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 + + +Full Copyright Statement + + Copyright (C) The Internet Society (1998). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + +Kaliski & Staddon Informational [Page 39] + |