GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc2437

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:
  1. cryptographic primitives
  2. encryption schemes
  3. signature schemes with appendix
  4. 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:
  1. Section 1 is an introduction.
  2. Section 2 defines some notation used in this document.
  3. Section 3 defines the RSA public and private key types.
  4. 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.
  1. 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.
  1. 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.
  1. 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:
  1. 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:
  1. 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}
  1. 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 }
  1. 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.
  1. 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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc2437.txt · Last modified: 1998/10/15 22:33 (external edit)