RFC 2437

PKCS #1: RSA Cryptography Specifications Version 2.0

📅 published October 1998, from ietf

PKCS #1: RSA Cryptography Specifications Version 2.0 🎀

Okay bestie, this is RFC 2437 💖 It's a document from the Network Working Group, written by B. Kaliski and J. Staddon of RSA Laboratories. It's filed as Informational and dated October 1998. It obsoletes RFC 2313, and the header doesn't list any RFCs it updates ✨

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 (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
   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 🌸

Okay so this memo is the successor to RFC 2313 💅 It gives recommendations for implementing public-key cryptography based on the RSA algorithm [18], and it covers these aspects:

  • cryptographic primitives
  • encryption schemes
  • signature schemes with appendix
  • ASN.1 syntax for representing keys and for identifying the schemes

The recommendations are meant for general use within computer and communications systems, so they include a fair amount of flexibility 🦋 Application standards built on these specs may add more constraints. The recommendations are also meant to be compatible with draft standards that the ANSI X9F1 [1] and IEEE P1363 working groups [14] are currently developing. This document supersedes PKCS #1 version 1.5 [20] ✨

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 🧚

Here's how this document is laid out 🗺️

  • 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 🍓

Here's the notation cheat sheet, copied exactly so nothing gets lost in translation 🫶

   (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
   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
   ||            concatenation operator

   ||.||         octet length operator

3. Key types 🔑

Two key types get used in the primitives and schemes in this document: the RSA public key and the 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 has 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 swapping RSA public keys between implementations is given in Section 11.1.1. An implementation's internal representation may be different ✨

3.2. RSA private key 🌈

For the purposes of this document, an RSA private key can have either of two representations 💅

  1. The first representation is the pair (n, d), where the components have these meanings:
    • n, the modulus, a nonnegative integer
    • d, the private exponent, a nonnegative integer
  2. The second representation is a quintuple (p, q, dP, dQ, qInv), where the components have these 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. The private exponent d is a positive integer less than n satisfying:

ed \equiv 1 (mod \lambda(n))

Here 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 swapping RSA private keys between implementations, which includes components from both representations, is given in Section 11.1.2. An implementation's internal representation may be different 🫧

4. Data conversion primitives 🎀

Two data conversion primitives get used in the schemes 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 ✨

Okay bestie, I2OSP takes a plain nonnegative integer and turns it into an octet string of whatever length you ask for 🧵🔢 It's giving pure math and I'm obsessed. If the number is too big to fit in that many octets, it just says "integer too large" and bounces 🙅‍♀️

I2OSP (x, l)
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 is the reverse glow-up 💜 It takes an octet string and turns it back into a nonnegative integer, reading the octets from first to last.

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.

5. Cryptographic primitives 🔐

Okay so cryptographic primitives are the basic math moves that fancier cryptographic schemes get built out of 🧱 They're meant to be implemented in hardware or as software modules, and on their own they don't give you security. The scheme is what makes the security happen ✨

This document specifies four primitives, and they come in pairs: encryption and decryption, and signature and verification 👯‍♀️

The specs assume the inputs already meet certain conditions, especially that public and private keys are valid. Keys are the main character here 🔑

5.1 Encryption and decryption primitives 💖

An encryption primitive takes a message representative and, under the control of a public key, produces a ciphertext representative. A decryption primitive goes the other way: under the control of the matching private key, it recovers the message representative from the ciphertext representative 🌸

The encryption schemes in this document use one pair of these primitives, RSAEP/RSADP. They both do the same mathematical operation, just with different keys going in 🍓

These primitives are the same as in the draft IEEE P1363 and are compatible with PKCS #1 v1.5 🎀

The main math in each one 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:

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.

5.2 Signature and verification primitives 🖋️

A signature primitive takes a message representative and, under the control of a private key, produces a signature representative. A verification primitive recovers the message representative from the signature representative, under the control of the matching public key 🦢

The signature schemes here use one pair, RSASP1/RSAVP1 ✨

These are the same as in the draft IEEE P1363 and compatible with PKCS #1 v1.5 💜

Same vibe as before: the main operation is exponentiation, just like the encryption and decryption primitives in Section 5.1. RSASP1 and RSAVP1 are basically RSADP and RSAEP with different names for their inputs and outputs. They're kept separate because they're meant for different jobs 👑

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:

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 is the combo move: it puts cryptographic primitives together with other techniques to hit a specific security goal 🎯 This document specifies two types: encryption schemes and signature schemes with appendix 💕

The schemes here are pretty focused. They only do steps that process data with a key, and they don't cover getting or validating that key. So along with the scheme operations, an application will usually also handle key management, which is how parties pick the public and private keys they use. The specific extra operations and details are out of scope for this document 🫶

Just like the primitives in Section 5, the scheme specs assume the inputs meet certain conditions, especially valid public and private keys. If a key is invalid, how an implementation behaves is unspecified, and the impact depends on the application 😬 There are a few ways to deal with key validation: the application can validate keys explicitly, key validation can happen within the public-key infrastructure, or liability for operations done with an invalid key can be assigned to the party who generated that key ⚖️

7. Encryption schemes 🔒

An encryption scheme has an encryption operation and a decryption operation. The encryption operation makes a ciphertext from a message using the recipient's public key. The decryption operation gets the message back from the ciphertext using the recipient's matching private key 🎀

Encryption schemes are pretty versatile. A classic use is a key establishment protocol, where the message carries key material that needs to get from one party to another privately. For example, PKCS #7 [21] uses this kind of protocol to send a content-encryption key from a sender to a recipient, and the encryption schemes defined here would be solid key-encryption algorithms in that setup 🗝️

This document specifies two encryption schemes: 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 it is not recommended for new applications 💅

The encryption schemes follow a general model similar to the one used in IEEE P1363. They combine encryption and decryption primitives with an encoding method. In encryption, the message gets encoded and then converted into an integer message representative, and the encryption primitive turns that into the ciphertext. Decryption reverses it: the decryption primitive recovers a message representative from the ciphertext, which gets converted back into an octet string encoded message. Then a message decoding operation runs on the encoded message to recover the message and check that the decryption was correct ✅

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

Okay bestie, this is where RSAES-OAEP actually encrypts stuff 🔐✨ The signature is:

RSAES-OAEP-ENCRYPT ((n, e), M, P)

Here's what goes in 🎀

  • (n, e): the recipient's RSA public key 🔑
  • M: the 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

And what comes out 💅

  • C: the ciphertext, an octet string of length k, or "message too long"

We're assuming the public key (n, e) is valid, no cap 🫶

Now the steps, periodt 🦋

  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. Done and dusted 🌸

7.1.2 Decryption operation

The decryption side is giving careful and paranoid, in the best way 🙈 The signature is:

RSAES-OAEP-DECRYPT (K, C, P)

Inputs 🧚

  • K: the recipient's RSA private key
  • C: the 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

Outputs 💜

  • M: the 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"

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]. 🚨 This is the kind of detail that matters, bestie, so don't skip it 💀

7.2 RSAES-PKCS1-v1_5

Okay, this one is the older sibling 🧁 RSAES-PKCS1-v1_5 combines the RSAEP and RSADP primitives with the EME-PKCS1-v1_5 encoding method. It's the same as the encryption scheme in PKCS #1 v1.5. It 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]). 🙃

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. 👀

7.2.1 Encryption operation

The signature is:

RSAES-PKCS1-V1_5-ENCRYPT ((n, e), M)

Inputs 🧚

  • (n, e): the recipient's RSA public key
  • M: the 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: the 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

The signature is:

RSAES-PKCS1-V1_5-DECRYPT (K, C)

Inputs 🧚

  • K: the recipient's RSA private key
  • C: the ciphertext to be decrypted, an octet string of length k, where k is the length in octets of the modulus n

Output 💜

  • M: the message, an octet string of length at most k-11; or "decryption error"

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 from 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. 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. 🖊️

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, and 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

okay bestie, RSASSA-PKCS1-v1_5 is the glam combo 💅 It mixes the RSASP1 and RSAVP1 primitives with the EME-PKCS1-v1_5 encoding method. It's compatible with the IFSSA scheme from 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 P1363 doesn't define, so it's a little bit of a plus-one 🌸). Depending on the hash function under the message encoding method, the messages it can handle are either unrestricted or capped by a really huge number ✨

Assuming the hash function in EMSA-PKCS1-v1_5 has the right properties and the key is big enough, RSASSA-PKCS1-v1_5 gives you secure signatures 🔒 That means it's computationally infeasible to make a signature without the private key, and computationally infeasible to find a message that goes with a given signature, or two messages that share one. The encoding method also embeds a hash function identifier, which is so iconic 👑 Because of that, an attacker has to invert or find collisions for the exact hash function being used. Attacking a different hash than the one the signer picked gets them nothing, periodt 💀

8.1.1. Signature generation operation

Here's the signing function:

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, in order, no skipping 🎀

  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".

  1. Convert the encoded message EM to an integer message representative m: m = OS2IP (EM)
  2. 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)
  3. Convert the signature representative s to a signature S of length k octets: S = I2OSP (s, k)
  4. Output the signature S. ✨

8.1.2. Signature verification operation

Now the checking function 🦋

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.
  1. 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.

  1. 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".

  1. 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 are the operations that map between octet string messages and integer message representatives. It's basically the translator between human-readable bytes and the big numbers the math actually runs on 🔥

Two types of encoding method show up in this document: encoding methods for encryption, and encoding methods for signatures with appendix.

9.1. Encoding methods for encryption

An encoding method for encryption has an encoding operation and a decoding operation. The encoding operation maps a message M to a message representative EM of a specified length, and the decoding operation maps a message representative EM back to a message. The two are inverses of each other, so they undo each other perfectly 🌈

The message representative EM will typically have some structure the decoding operation can verify. If that structure isn't there, the decoding operation will output "decoding error" 🙈 The encoding operation may also add some randomness, so running it on the same message twice can give you different representatives. Very main character energy 🦋

Two encoding methods for encryption get used 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 in Section 10. The method is based on the one found in [2].

9.1.1.1. Encoding operation

Here's the signature of the encoding function:

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
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, bestie 💅

  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
  1. Generate a random octet string seed of length hLen.
  2. Let dbMask = MGF(seed, emLen-hLen).
  3. Let maskedDB = DB \xor dbMask.
  4. Let seedMask = MGF(maskedDB, hLen).
  5. Let maskedSeed = seed \xor seedMask.
  6. Let EM = maskedSeed || maskedDB.
  7. Output EM. 🎀

9.1.1.2. Decoding operation EME-OAEP-DECODE (EM, P)

Here's the decoding function signature:

EME-OAEP-DECODE (EM, P)

Options:
Hash      hash function (hLen denotes the length in octet of the hash
          function output)

MGF       mask generation function
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.

  1. If pHash' does not equal pHash, output "decoding error" and stop.
  2. 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. Classic, and it's still giving 👑

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
  1. 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

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.

  1. If the length of PS is less than 8 octets, output "decoding error" and stop.
  2. Output M. 🫶

9.2. Encoding methods for signatures with appendix

An encoding method for signatures with appendix, for the purposes of this document, has an encoding operation. That 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 🌸

okay so this encoding method is lowkey the simplest one ever 💅 it only has an encoding operation, no decoding, no cap. you just take the message, hash it, wrap that hash in a little DigestInfo box, and pad the whole thing out till it's the right size 🎀

EMSA-PKCS1-v1_5-ENCODE (M, emLen)

  • Option: Hash, the hash function. hLen is the length in octets of its output.
  • Input: M, the message to be encoded. emLen, the intended length in octets of the encoded message. It has to be at least ||T|| + 10, where T is the DER encoding of a value that gets computed during the encoding operation.
  • Output: EM, the encoded message, an octet string of length emLen. Or else "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".

  1. 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. (the first field is the "who" and the second is the "what" 🧚)

  1. If emLen is less than ||T|| + 10 then output "intended encoded message length too short".
  2. 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.
  3. Concatenate PS, the DER encoding T, and other padding to form the encoded message EM as: EM = 01 || PS || 00 || T
  4. Output EM. ✨

10. Auxiliary Functions 🦋

okay this part is the helper squad! it specifies the hash functions and the mask generation functions that the encoding methods in Section 9 keep calling on 💖

10.1 Hash Functions 🍓

hash functions are used in the operations in Sections 7, 8 and 9. they're deterministic, meaning the output is totally determined by the input 🔮 they take octet strings of any variable length and spit out fixed length octet strings. the hash functions used in those operations SHOULD be collision resistant, which means it's infeasible to find two distinct inputs that give the same output. a collision resistant hash also has the very iconic property of being one-way: given an output, it's infeasible to find an input whose hash is that output. collision resistance is especially desirable for RSASSA-PKCS1-v1_5, because it makes it infeasible to forge signatures 🙈 on top of all that, the hash function SHOULD yield a mask generation function (Section 10.2) with pseudorandom output.

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 aren't defined here, so go read the 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 that desired length. there may be restrictions on the input and output lengths, but those bounds are generally super huge 🌈 mask generation functions are deterministic too: the octet string output is completely determined by the input octet string. the output SHOULD be pseudorandom, which means that if the seed is unknown, it SHOULD be infeasible to tell the output apart 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 it's defined right here: MGF1, which is based on a hash function. future versions of this document MAY define other mask generation functions 🔮

10.2.1 MGF1

ok wait this one is actually the ICONIC one 👑 MGF1 is a Mask Generation Function based on a hash function.

MGF1 (Z, l)

  • Options: Hash, the hash function. hLen is the length in octets of its output.
  • Input: Z, the seed the mask is generated from, an octet string. l, the intended length in octets of the mask, at most 2^32(hLen).
  • Output: mask, the mask, an octet string of length l. Or else "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)

  1. Output the leading l octets of T as the octet string mask. 🎀

11. ASN.1 syntax 💜

ASN.1 is where we get the official names and boxes for all the keys and scheme IDs 🧚

11.1 Key representation 🔑

this section defines the 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 🫶

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 kept here for compatibility, so it's giving backwards-compatible energy 💅)

the fields of type RSAPublicKey have these 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 the ASN.1 type RSAPrivateKey:

RSAPrivateKey ::= SEQUENCE {
  version Version,
  modulus INTEGER, -- n
  publicExponent INTEGER, -- e
  privateExponent INTEGER, -- d
  prime1 INTEGER, -- p
  prime2 INTEGER, -- q
  exponent1 INTEGER, -- d mod (p-1)
  exponent2 INTEGER, -- d mod (q-1)
  coefficient INTEGER -- (inverse of q) mod p }

Version ::= INTEGER

the fields of type RSAPrivateKey have these 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.

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 these 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 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 this 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. 🌈

RsaEncryption   OBJECT IDENTIFIER ::= {PKCS-1 1}

11.2.3 Syntax for RSASSA-PKCS1-v1_5 🎀

okay bestie, so the RSASSA-PKCS1-v1_5 OID (object identifier) depends on which hash you picked: MD2, MD5, or SHA-1 🔥. Heads up, if you use MD2 or MD5, the OID is exactly the same as in PKCS #1 v1.5, so nothing new to learn there ✨. For every one of these OIDs, the parameters field in the AlgorithmIdentifier shall have type NULL 💅.

If the hash is MD2, the OID should be:

md2WithRSAEncryption ::= {PKCS-1 2}

If the hash is MD5, the OID should be:

md5WithRSAEncryption ::= {PKCS-1 4}

If the hash is SHA-1, the OID should be:

sha1WithRSAEncryption ::= {pkcs-1 5}

Now, for the digestInfo type from Section 9.2.1, the digest algorithm OIDs are these 🦋:

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}

And yes, the parameters field of the digest algorithm has ASN.1 type NULL for these OIDs 🧚

12. Patent statement 📜

Quick legal moment, bestie 🫶. The Internet Standards Process, as defined in RFC 1310, needs a written statement from the Patent holder saying a license will be available to applicants on reasonable terms and conditions before a specification gets approved as a Proposed, Draft or Internet Standard.

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 patents and patent applications below, or on whether the terms of the assurance are appropriate. The Internet Society and the other groups above haven't made any determination about other intellectual property rights that might apply to practicing 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 given the following statement about 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.

13. Revision history 🌸

Here's the glow-up timeline of this doc 🦋

Versions 1.0-1.3

Versions 1.0-1.3 were shared with 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. It was published as NIST/OSI Implementors' Workshop document SEC-SIG-91-18 ✨.

Version 1.5

Version 1.5 brought several editorial changes, including updated references and a new revision history section. The substantive changes were:

  • 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 is a major editorial overhaul of the document structure, and it introduces the RSAEP-OAEP encryption scheme 🔥. It keeps supporting the encryption and signature processes from version 1.5, but the hash algorithm MD4 is no longer allowed, because of cryptanalytic advances in the years since 💀.

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.

[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.

[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. Read the whole thing, bestie, because security is not optional 🔐.

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".

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

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. 🦋

📦 where this page comes from