idnits 2.17.1 draft-moriarty-pkcs1-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1880 has weird spacing: '... emBits maxi...' == Line 1945 has weird spacing: '... emBits maxi...' == Line 2011 has weird spacing: '... emLen int...' == Line 2505 has weird spacing: '...gorithm id-s...' == Line 2530 has weird spacing: '...gorithm id-m...' == (16 more instances...) == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (September 5, 2016) is 2789 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 3283 -- Looks like a reference, but probably isn't: '1' on line 3284 -- Looks like a reference, but probably isn't: '2' on line 3285 -- Looks like a reference, but probably isn't: '3' on line 3286 -- Obsolete informational reference (is this intentional?): RFC 1319 (Obsoleted by RFC 6149) -- Obsolete informational reference (is this intentional?): RFC 2437 (Obsoleted by RFC 3447) -- Obsolete informational reference (is this intentional?): RFC 5208 (Obsoleted by RFC 5958) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Moriarty, Ed. 3 Internet-Draft EMC Corporation 4 Obsoletes: 3447 (if approved) B. Kaliski 5 Intended status: Informational Verisign 6 Expires: March 9, 2017 J. Jonsson 7 Subset AB 8 A. Rusch 9 RSA 10 September 5, 2016 12 PKCS #1 Version 2.2: RSA Cryptography Specifications 13 draft-moriarty-pkcs1-03 15 Abstract 17 This document represents a republication of PKCS #1 v2.2 from RSA 18 Laboratories' Public-Key Cryptography Standards (PKCS) series. By 19 publishing this RFC, change control is transferred to the IETF. 21 This document also obsoletes RFC 3447. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on March 9, 2017. 40 Copyright Notice 42 Copyright (c) 2016 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 59 2. Notation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Key types . . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 3.1. RSA public key . . . . . . . . . . . . . . . . . . . . . 7 62 3.2. RSA private key . . . . . . . . . . . . . . . . . . . . . 8 63 4. Data conversion primitives . . . . . . . . . . . . . . . . . 9 64 4.1. I2OSP . . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 4.2. OS2IP . . . . . . . . . . . . . . . . . . . . . . . . . . 11 66 5. Cryptographic primitives . . . . . . . . . . . . . . . . . . 11 67 5.1. Encryption and decryption primitives . . . . . . . . . . 11 68 5.1.1. RSAEP . . . . . . . . . . . . . . . . . . . . . . . . 12 69 5.1.2. RSADP . . . . . . . . . . . . . . . . . . . . . . . . 12 70 5.2. Signature and verification primitives . . . . . . . . . . 13 71 5.2.1. RSASP1 . . . . . . . . . . . . . . . . . . . . . . . 14 72 5.2.2. RSAVP1 . . . . . . . . . . . . . . . . . . . . . . . 15 73 6. Overview of schemes . . . . . . . . . . . . . . . . . . . . . 16 74 7. Encryption schemes . . . . . . . . . . . . . . . . . . . . . 17 75 7.1. RSAES-OAEP . . . . . . . . . . . . . . . . . . . . . . . 17 76 7.1.1. Encryption operation . . . . . . . . . . . . . . . . 20 77 7.1.2. Decryption operation . . . . . . . . . . . . . . . . 23 78 7.2. RSAES-PKCS1-v1_5 . . . . . . . . . . . . . . . . . . . . 25 79 7.2.1. Encryption operation . . . . . . . . . . . . . . . . 26 80 7.2.2. Decryption Operation . . . . . . . . . . . . . . . . 28 81 8. Signature scheme with appendix . . . . . . . . . . . . . . . 29 82 8.1. RSASSA-PSS . . . . . . . . . . . . . . . . . . . . . . . 30 83 8.1.1. Signature generation operation . . . . . . . . . . . 31 84 8.1.2. Signature verification operation . . . . . . . . . . 32 85 8.2. RSASSA-PKCS1-v1_5 . . . . . . . . . . . . . . . . . . . . 33 86 8.2.1. Signature generation operation . . . . . . . . . . . 35 87 8.2.2. Signature verification operation . . . . . . . . . . 36 88 9. Encoding methods for signatures with appendix . . . . . . . . 37 89 9.1. EMSA-PSS . . . . . . . . . . . . . . . . . . . . . . . . 38 90 9.1.1. Encoding operation . . . . . . . . . . . . . . . . . 40 91 9.1.2. Verification operation . . . . . . . . . . . . . . . 41 92 9.2. EMSA-PKCS1-v1_5 . . . . . . . . . . . . . . . . . . . . . 43 93 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 94 11. Security Considerations . . . . . . . . . . . . . . . . . . . 45 95 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 96 12.1. Normative References . . . . . . . . . . . . . . . . . . 45 97 12.2. Informative References . . . . . . . . . . . . . . . . . 45 98 Appendix A. ASN.1 syntax . . . . . . . . . . . . . . . . . . . . 50 99 A.1. RSA key representation . . . . . . . . . . . . . . . . . 50 100 A.1.1. RSA public key syntax . . . . . . . . . . . . . . . . 50 101 A.1.2. RSA private key syntax . . . . . . . . . . . . . . . 51 102 A.2. Scheme identification . . . . . . . . . . . . . . . . . . 52 103 A.2.1. RSAES-OAEP . . . . . . . . . . . . . . . . . . . . . 53 104 A.2.2. RSAES-PKCS-v1_5 . . . . . . . . . . . . . . . . . . . 55 105 A.2.3. RSASSA-PSS . . . . . . . . . . . . . . . . . . . . . 55 106 A.2.4. RSASSA-PKCS-v1_5 . . . . . . . . . . . . . . . . . . 57 107 Appendix B. Supporting techniques . . . . . . . . . . . . . . . 58 108 B.1. Hash functions . . . . . . . . . . . . . . . . . . . . . 58 109 B.2. Mask generation functions . . . . . . . . . . . . . . . . 62 110 B.2.1. MGF1 . . . . . . . . . . . . . . . . . . . . . . . . 62 111 Appendix C. ASN.1 module . . . . . . . . . . . . . . . . . . . . 63 112 Appendix D. Intellectual property considerations . . . . . . . . 71 113 Appendix E. Revision history . . . . . . . . . . . . . . . . . . 72 114 Appendix F. About PKCS . . . . . . . . . . . . . . . . . . . . . 73 115 Appendix G. Acknowledgements . . . . . . . . . . . . . . . . . . 73 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 73 118 1. Introduction 120 This document provides recommendations for the implementation of 121 public-key cryptography based on the RSA algorithm [RSA], covering 122 the following aspects: 124 o Cryptographic primitives 126 o Encryption schemes 128 o Signature schemes with appendix 130 o ASN.1 syntax for representing keys and for identifying the schemes 132 The recommendations are intended for general application within 133 computer and communications systems, and as such include a fair 134 amount of flexibility. It is expected that application standards 135 based on these specifications may include additional constraints. 136 The recommendations are intended to be compatible with the standards 137 IEEE 1363-2000 [IEEE1363], IEEE 1363a-2004 [IEEE1363A], and ANSI 138 X9.44-2007 [ANSIX944]. 140 This document supersedes PKCS #1 version 2.1 [PKCS1_21] but includes 141 compatible techniques. 143 The organization of this document is as follows: 145 o Section 1 is an introduction. 147 o Section 2 defines some notation used in this document. 149 o Section 3 defines the RSA public and private key types. 151 o Sections 4 and 5 define several primitives, or basic mathematical 152 operations. Data conversion primitives are in Section 4, and 153 cryptographic primitives (encryption-decryption, signature- 154 verification) are in Section 5. 156 o Sections 6, 7, and 8 deal with the encryption and signature 157 schemes in this document. Section 6 gives an overview. Along 158 with the methods found in PKCS #1 v1.5, Section 7 defines an OAEP- 159 based [OAEP] encryption scheme and Section 8 defines a PSS-based 160 [RSARABIN][PSS] signature scheme with appendix. 162 o Section 9 defines the encoding methods for the signature schemes 163 in Section 8. 165 o Appendix A defines the ASN.1 syntax for the keys defined in 166 Section 3 and the schemes in Sections 7 and 8. 168 o Appendix B defines the hash functions and the mask generation 169 function used in this document, including ASN.1 syntax for the 170 techniques. 172 o Appendix C gives an ASN.1 module. 174 o Appendices D, E, and F cover intellectual property issues, outline 175 the revision history of PKCS #1, and provide general information 176 about the Public-Key Cryptography Standards. 178 1.1. Requirements Language 180 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 181 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 182 document are to be interpreted as described in [RFC2119]. 184 2. Notation 186 The notation in this document includes: 188 c ciphertext representative, an integer between 0 and 189 n-1 191 C ciphertext, an octet string 192 d RSA private exponent 194 d_i additional factor r_i's CRT exponent, a positive 195 integer such that 197 e * d_i == 1 (mod (r_i-1)), i = 3, ..., u 199 dP p's CRT exponent, a positive integer such that 201 e * dP == 1 (mod (p-1)) 203 dQ q's CRT exponent, a positive integer such that 205 e * dQ == 1 (mod (q-1)) 207 e RSA public exponent 209 EM encoded message, an octet string 211 emBits (intended) length in bits of an encoded message EM 213 emLen (intended) length in octets of an encoded message 214 EM 216 GCD(. , .) greatest common divisor of two nonnegative integers 218 Hash hash function 220 hLen output length in octets of hash function Hash 222 k length in octets of the RSA modulus n 224 K RSA private key 226 L optional RSAES-OAEP label, an octet string 228 LCM(., ..., .) least common multiple of a list of nonnegative 229 integers 231 m message representative, an integer between 0 and 232 n-1 234 M message, an octet string 236 mask MGF output, an octet string 238 maskLen (intended) length of the octet string mask 239 MGF mask generation function 241 mgfSeed seed from which mask is generated, an octet string 243 mLen length in octets of a message M 245 n RSA modulus, n = r_1 * r_2 * ... * r_u , u >= 2 247 (n, e) RSA public key 249 p, q first two prime factors of the RSA modulus n 251 qInv CRT coefficient, a positive integer less than 252 p such that q * qInv == 1 (mod p) 254 r_i prime factors of the RSA modulus n, including 255 r_1 = p, r_2 = q, and additional factors if any 257 s signature representative, an integer between 0 and 258 n-1 260 S signature, an octet string 262 sLen length in octets of the EMSA-PSS salt 264 t_i additional prime factor r_i's CRT coefficient, a 265 positive integer less than r_i such that 267 r_1 * r_2 * ... * r_(i-1) * t_i == 1 (mod r_i) , 269 i = 3, ... , u 271 u number of prime factors of the RSA modulus, u >= 2 273 x a nonnegative integer 275 X an octet string corresponding to x 277 xLen (intended) length of the octet string X 279 0x indicator of hexadecimal representation of an octet 280 or an octet string; "0x48" denotes the octet with 281 hexadecimal value 48; "(0x)48 09 0e" denotes the 282 string of three consecutive octets with hexadecimal 283 value 48, 09, and 0e, respectively 285 \lambda(n) LCM(r_1-1, r_2-1, ... , r_u-1) 286 \xor bit-wise exclusive-or of two octet strings 288 \ceil(.) ceiling function; \ceil(x) is the smallest integer 289 larger than or equal to the real number x 291 || concatenation operator 293 == congruence symbol; a == b (mod n) means that the 294 integer n divides the integer a - b 296 Note. The CRT can be applied in a non-recursive as well as a 297 recursive way. In this document a recursive approach following 298 Garner's algorithm [GARNER] is used. See also Note 1 in Section 3.2. 300 3. Key types 302 Two key types are employed in the primitives and schemes defined in 303 this document: RSA public key and RSA private key. Together, an RSA 304 public key and an RSA private key form an RSA key pair. 306 This specification supports so-called "multi-prime" RSA where the 307 modulus may have more than two prime factors. The benefit of multi- 308 prime RSA is lower computational cost for the decryption and 309 signature primitives, provided that the CRT (Chinese Remainder 310 Theorem) is used. Better performance can be achieved on single 311 processor platforms, but to a greater extent on multiprocessor 312 platforms, where the modular exponentiations involved can be done in 313 parallel. 315 For a discussion on how multi-prime affects the security of the RSA 316 cryptosystem, the reader is referred to [SILVERMAN]. 318 3.1. RSA public key 320 For the purposes of this document, an RSA public key consists of two 321 components: 323 n the RSA modulus, a positive integer 324 e the RSA public exponent, a positive integer 326 In a valid RSA public key, the RSA modulus n is a product of u 327 distinct odd primes r_i, i = 1, 2, ..., u, where u >= 2, and the RSA 328 public exponent e is an integer between 3 and n - 1 satisfying GCD(e, 329 \lambda(n)) = 1, where \lambda(n) = LCM(r_1 - 1, ..., r_u - 1). By 330 convention, the first two primes r_1 and r_2 may also be denoted p 331 and q respectively. 333 A recommended syntax for interchanging RSA public keys between 334 implementations is given in Appendix A.1.1; an implementation's 335 internal representation may differ. 337 3.2. RSA private key 339 For the purposes of this document, an RSA private key may have either 340 of two representations. 342 1. The first representation consists of the pair (n, d), where 343 the components have the following meanings: 345 n the RSA modulus, a positive integer 346 d the RSA private exponent, a positive integer 348 2. The second representation consists of a quintuple (p, q, dP, 349 dQ, qInv) and a (possibly empty) sequence of triplets (r_i, d_i, 350 t_i), i = 3, ..., u, one for each prime not in the quintuple, 351 where the components have the following meanings: 353 p the first factor, a positive integer 354 q the second factor, a positive integer 355 dP the first factor's CRT exponent, a positive integer 356 dQ the second factor's CRT exponent, a positive integer 357 qInv the (first) CRT coefficient, a positive integer 358 r_i the i-th factor, a positive integer 359 d_i the i-th factor's CRT exponent, a positive integer 360 t_i the i-th factor's CRT coefficient, a positive integer 362 In a valid RSA private key with the first representation, the RSA 363 modulus n is the same as in the corresponding RSA public key and is 364 the product of u distinct odd primes r_i, i = 1, 2, ..., u, where u 365 >= 2. The RSA private exponent d is a positive integer less than n 366 satisfying 368 e * d == 1 (mod \lambda(n)), 370 where e is the corresponding RSA public exponent and \lambda(n) is 371 defined as in Section 3.1. 373 In a valid RSA private key with the second representation, the two 374 factors p and q are the first two prime factors of the RSA modulus n 375 (i.e., r_1 and r_2), the CRT exponents dP and dQ are positive 376 integers less than p and q respectively satisfying 378 e * dP == 1 (mod (p-1)) 380 e * dQ == 1 (mod (q-1)) , 382 and the CRT coefficient qInv is a positive integer less than p 383 satisfying 385 q * qInv == 1 (mod p). 387 If u > 2, the representation will include one or more triplets (r_i, 388 d_i, t_i), i = 3, ..., u. The factors r_i are the additional prime 389 factors of the RSA modulus n. Each CRT exponent d_i (i = 3, ..., u) 390 satisfies 392 e * d_i == 1 (mod (r_i - 1)). 394 Each CRT coefficient t_i (i = 3, ..., u) is a positive integer less 395 than r_i satisfying 397 R_i * t_i == 1 (mod r_i) , 399 where R_i = r_1 * r_2 * ... * r_(i-1). 401 A recommended syntax for interchanging RSA private keys between 402 implementations, which includes components from both representations, 403 is given in Appendix A.1.2; an implementation's internal 404 representation may differ. 406 Notes. 408 1. The definition of the CRT coefficients here and the formulas that 409 use them in the primitives in Section 5 generally follow Garner's 410 algorithm [GARNER] (see also Algorithm 14.71 in [HANDBOOK]). 411 However, for compatibility with the representations of RSA 412 private keys in PKCS #1 v2.0 and previous versions, the roles of 413 p and q are reversed compared to the rest of the primes. Thus, 414 the first CRT coefficient, qInv, is defined as the inverse of q 415 mod p, rather than as the inverse of R_1 mod r_2, i.e., of p mod 416 q. 418 2. Quisquater and Couvreur [FASTDEC] observed the benefit of 419 applying the Chinese Remainder Theorem to RSA operations. 421 4. Data conversion primitives 423 Two data conversion primitives are employed in the schemes defined in 424 this document: 426 o I2OSP - Integer-to-Octet-String primitive 428 o OS2IP - Octet-String-to-Integer primitive 429 For the purposes of this document, and consistent with ASN.1 syntax, 430 an octet string is an ordered sequence of octets (eight-bit bytes). 431 The sequence is indexed from first (conventionally, leftmost) to last 432 (rightmost). For purposes of conversion to and from integers, the 433 first octet is considered the most significant in the following 434 conversion primitives. 436 4.1. I2OSP 438 I2OSP converts a nonnegative integer to an octet string of a 439 specified length. 441 I2OSP (x, xLen) 443 Input: 445 x nonnegative integer to be converted 447 xLen intended length of the resulting octet string 449 Output: 451 X corresponding octet string of length xLen 453 Error: "integer too large" 455 Steps: 457 1. If x >= 256^xLen, output "integer too large" and stop. 459 2. Write the integer x in its unique xLen-digit representation in 460 base 256: 462 x = x_(xLen-1) 256^(xLen-1) + x_(xLen-2) 256^(xLen-2) + ... 463 + x_1 256 + x_0, 465 where 0 <= x_i < 256 (note that one or more leading digits 466 will be zero if x is less than 256^(xLen-1)). 468 3. Let the octet X_i have the integer value x_(xLen-i) for 1 <= i 469 <= xLen. Output the octet string 471 X = X_1 X_2 ... X_xLen. 473 4.2. OS2IP 475 OS2IP converts an octet string to a nonnegative integer. 477 OS2IP (X) 479 Input: X octet string to be converted 481 Output: x corresponding nonnegative integer 483 Steps: 485 1. Let X_1 X_2 ... X_xLen be the octets of X from first to last, 486 and let x_(xLen-i) be the integer value of the octet X_i for 1 487 <= i <= xLen. 489 2. Let x = x_(xLen-1) 256^(xLen-1) + x_(xLen-2) 256^(xLen-2) + 490 ... + x_1 256 + x_0. 492 3. Output x. 494 5. Cryptographic primitives 496 Cryptographic primitives are basic mathematical operations on which 497 cryptographic schemes can be built. They are intended for 498 implementation in hardware or as software modules, and are not 499 intended to provide security apart from a scheme. 501 Four types of primitive are specified in this document, organized in 502 pairs: encryption and decryption; and signature and verification. 504 The specifications of the primitives assume that certain conditions 505 are met by the inputs, in particular that RSA public and private keys 506 are valid. 508 5.1. Encryption and decryption primitives 510 An encryption primitive produces a ciphertext representative from a 511 message representative under the control of a public key, and a 512 decryption primitive recovers the message representative from the 513 ciphertext representative under the control of the corresponding 514 private key. 516 One pair of encryption and decryption primitives is employed in the 517 encryption schemes defined in this document and is specified here: 518 RSAEP/RSADP. RSAEP and RSADP involve the same mathematical 519 operation, with different keys as input. The primitives defined here 520 are the same as IFEP-RSA/IFDP-RSA in IEEE 1363-2000 [IEEE1363] 521 (except that support for multi-prime RSA has been added) and are 522 compatible with PKCS #1 v1.5. 524 The main mathematical operation in each primitive is exponentiation. 526 5.1.1. RSAEP 528 RSAEP ((n, e), m) 530 Input: 532 (n, e) RSA public key 534 m message representative, an integer between 0 and n - 1 536 Output: c ciphertext representative, an integer between 0 and n - 1 538 Error: "message representative out of range" 540 Assumption: RSA public key (n, e) is valid 542 Steps: 544 1. If the message representative m is not between 0 and n - 1, 545 output "message representative out of range" and stop. 547 2. Let c = m^e mod n. 549 3. Output c. 551 5.1.2. RSADP 553 RSADP (K, c) 555 Input: 557 K RSA private key, where K has one of the following forms: 559 + a pair (n, d) 561 + a quintuple (p, q, dP, dQ, qInv) and a possibly empty 562 sequence of triplets (r_i, d_i, t_i), i = 3, ..., u 564 c ciphertext representative, an integer between 0 and n - 1 566 Output: m message representative, an integer between 0 and n - 1 568 Error: "ciphertext representative out of range" 569 Assumption: RSA private key K is valid 571 Steps: 573 1. If the ciphertext representative c is not between 0 and n - 1, 574 output "ciphertext representative out of range" and stop. 576 2. The message representative m is computed as follows. 578 a. If the first form (n, d) of K is used, let m = c^d mod n. 580 b. If the second form (p, q, dP, dQ, qInv) and (r_i, d_i, 581 t_i) of K is used, proceed as follows: 583 i. Let m_1 = c^dP mod p and m_2 = c^dQ mod q. 585 ii. If u > 2, let m_i = c^(d_i) mod r_i, i = 3, ..., 586 u. 588 iii. Let h = (m_1 - m_2) * qInv mod p. 590 iv. Let m = m_2 + q * h. 592 v. If u > 2, let R = r_1 and for i = 3 to u do 594 1. Let R = R * r_(i-1). 596 2. Let h = (m_i - m) * t_i mod r_i. 598 3. Let m = m + R * h. 600 3. Output m. 602 Note. Step 2.b can be rewritten as a single loop, provided that one 603 reverses the order of p and q. For consistency with PKCS #1 v2.0, 604 however, the first two primes p and q are treated separately from the 605 additional primes. 607 5.2. Signature and verification primitives 609 A signature primitive produces a signature representative from a 610 message representative under the control of a private key, and a 611 verification primitive recovers the message representative from the 612 signature representative under the control of the corresponding 613 public key. One pair of signature and verification primitives is 614 employed in the signature schemes defined in this document and is 615 specified here: RSASP1/RSAVP1. 617 The primitives defined here are the same as IFSP-RSA1/IFVP-RSA1 in 618 IEEE 1363-2000 [IEEE1363] (except that support for multi-prime RSA 619 has been added) and are compatible with PKCS #1 v1.5. 621 The main mathematical operation in each primitive is exponentiation, 622 as in the encryption and decryption primitives of Section 5.1. 623 RSASP1 and RSAVP1 are the same as RSADP and RSAEP except for the 624 names of their input and output arguments; they are distinguished as 625 they are intended for different purposes. 627 5.2.1. RSASP1 629 RSASP1 (K, m) 631 Input: 633 K RSA private key, where K has one of the following forms: 634 - a pair (n, d) 635 - a quintuple (p, q, dP, dQ, qInv) and a (possibly empty) 636 sequence of triplets (r_i, d_i, t_i), i = 3, ..., u 637 m message representative, an integer between 0 and n - 1 639 Output: 641 s signature representative, an integer between 0 and n - 1 643 Error: "message representative out of range" 645 Assumption: RSA private key K is valid 647 Steps: 649 1. If the message representative m is not between 0 and n - 1, 650 output "message representative out of range" and stop. 652 2. The signature representative s is computed as follows. 654 a. If the first form (n, d) of K is used, let s = m^d mod n. 656 b. If the second form (p, q, dP, dQ, qInv) and (r_i, d_i, 657 t_i) of K is used, proceed as follows: 659 1. Let s_1 = m^dP mod p and s_2 = m^dQ mod q. 661 2. If u > 2, let s_i = m^(d_i) mod r_i, i = 3, ..., u. 663 3. Let h = (s_1 - s_2) * qInv mod p. 665 4. Let s = s_2 + q * h. 667 5. If u > 2, let R = r_1 and for i = 3 to u do 669 a. Let R = R * r_(i-1). 671 b. Let h = (s_i - s) * t_i mod r_i. 673 c. Let s = s + R * h. 675 3. Output s. 677 Note. Step 2.b can be rewritten as a single loop, provided that one 678 reverses the order of p and q. For consistency with PKCS #1 v2.0, 679 however, the first two primes p and q are treated separately from the 680 additional primes. 682 5.2.2. RSAVP1 684 RSAVP1 ((n, e), s) 686 Input: 688 (n, e) RSA public key 690 s signature representative, an integer between 0 and n - 1 692 Output: 694 m message representative, an integer between 0 and n - 1 696 Error: "signature representative out of range" 698 Assumption: RSA public key (n, e) is valid 700 Steps: 702 1. If the signature representative s is not between 0 and n - 1, 703 output "signature representative out of range" and stop. 705 2. Let m = s^e mod n. 707 3. Output m. 709 6. Overview of schemes 711 A scheme combines cryptographic primitives and other techniques to 712 achieve a particular security goal. Two types of scheme are 713 specified in this document: encryption schemes and signature schemes 714 with appendix. 716 The schemes specified in this document are limited in scope in that 717 their operations consist only of steps to process data with an RSA 718 public or private key, and do not include steps for obtaining or 719 validating the key. Thus, in addition to the scheme operations, an 720 application will typically include key management operations by which 721 parties may select RSA public and private keys for a scheme 722 operation. The specific additional operations and other details are 723 outside the scope of this document. 725 As was the case for the cryptographic primitives (Section 5), the 726 specifications of scheme operations assume that certain conditions 727 are met by the inputs, in particular that RSA public and private keys 728 are valid. The behavior of an implementation is thus unspecified 729 when a key is invalid. The impact of such unspecified behavior 730 depends on the application. Possible means of addressing key 731 validation include explicit key validation by the application; key 732 validation within the public-key infrastructure; and assignment of 733 liability for operations performed with an invalid key to the party 734 who generated the key. 736 A generally good cryptographic practice is to employ a given RSA key 737 pair in only one scheme. This avoids the risk that vulnerability in 738 one scheme may compromise the security of the other, and may be 739 essential to maintain provable security. While RSAES-PKCS1-v1_5 740 (Section 7.2) and RSASSA-PKCS1-v1_5 (Section 8.2) have traditionally 741 been employed together without any known bad interactions (indeed, 742 this is the model introduced by PKCS #1 v1.5), such a combined use of 743 an RSA key pair is NOT RECOMMENDED for new applications. 745 To illustrate the risks related to the employment of an RSA key pair 746 in more than one scheme, suppose an RSA key pair is employed in both 747 RSAES-OAEP (Section 7.1) and RSAES-PKCS1-v1_5. Although RSAES-OAEP 748 by itself would resist attack, an opponent might be able to exploit a 749 weakness in the implementation of RSAES-PKCS1-v1_5 to recover 750 messages encrypted with either scheme. As another example, suppose 751 an RSA key pair is employed in both RSASSA-PSS (Section 8.1) and 752 RSASSA-PKCS1-v1_5. Then the security proof for RSASSA-PSS would no 753 longer be sufficient since the proof does not account for the 754 possibility that signatures might be generated with a second scheme. 755 Similar considerations may apply if an RSA key pair is employed in 756 one of the schemes defined here and in a variant defined elsewhere. 758 7. Encryption schemes 760 For the purposes of this document, an encryption scheme consists of 761 an encryption operation and a decryption operation, where the 762 encryption operation produces a ciphertext from a message with a 763 recipient's RSA public key, and the decryption operation recovers the 764 message from the ciphertext with the recipient's corresponding RSA 765 private key. 767 An encryption scheme can be employed in a variety of applications. A 768 typical application is a key establishment protocol, where the 769 message contains key material to be delivered confidentially from one 770 party to another. For instance, PKCS #7 [RFC2315] employs such a 771 protocol to deliver a content-encryption key from a sender to a 772 recipient; the encryption schemes defined here would be suitable key- 773 encryption algorithms in that context. 775 Two encryption schemes are specified in this document: RSAES-OAEP and 776 RSAES-PKCS1-v1_5. RSAES-OAEP is REQUIRED to be supported for new 777 applications; RSAES-PKCS1-v1_5 is included only for compatibility 778 with existing applications. 780 The encryption schemes given here follow a general model similar to 781 that employed in IEEE 1363-2000 [IEEE1363], combining encryption and 782 decryption primitives with an encoding method for encryption. The 783 encryption operations apply a message encoding operation to a message 784 to produce an encoded message, which is then converted to an integer 785 message representative. An encryption primitive is applied to the 786 message representative to produce the ciphertext. Reversing this, 787 the decryption operations apply a decryption primitive to the 788 ciphertext to recover a message representative, which is then 789 converted to an octet string encoded message. A message decoding 790 operation is applied to the encoded message to recover the message 791 and verify the correctness of the decryption. 793 To avoid implementation weaknesses related to the way errors are 794 handled within the decoding operation (see [BLEICHENBACHER] and 795 [MANGER]), the encoding and decoding operations for RSAES-OAEP and 796 RSAES-PKCS1-v1_5 are embedded in the specifications of the respective 797 encryption schemes rather than defined in separate specifications. 798 Both encryption schemes are compatible with the corresponding schemes 799 in PKCS #1 v2.1. 801 7.1. RSAES-OAEP 803 RSAES-OAEP combines the RSAEP and RSADP primitives (Sections 5.1.1 804 and 5.1.2) with the EME-OAEP encoding method (step 2 in Section 7.1.1 805 and step 3 in Section 7.1.2). EME-OAEP is based on Bellare and 806 Rogaway's Optimal Asymmetric Encryption scheme [OAEP]. (OAEP stands 807 for "Optimal Asymmetric Encryption Padding"). It is compatible with 808 the IFES scheme defined in IEEE 1363-2000 [IEEE1363], where the 809 encryption and decryption primitives are IFEP-RSA and IFDP-RSA and 810 the message encoding method is EME-OAEP. RSAES-OAEP can operate on 811 messages of length up to k - 2hLen -2 octets, where hLen is the 812 length of the output from the underlying hash function and k is the 813 length in octets of the recipient's RSA modulus. 815 Assuming that computing e-th roots modulo n is infeasible and the 816 mask generation function in RSAES-OAEP has appropriate properties, 817 RSAES-OAEP is semantically secure against adaptive chosen-ciphertext 818 attacks. This assurance is provable in the sense that the difficulty 819 of breaking RSAES-OAEP can be directly related to the difficulty of 820 inverting the RSA function, provided that the mask generation 821 function is viewed as a black box or random oracle; see [FOPS] and 822 the note below for further discussion. 824 Both the encryption and the decryption operations of RSAES-OAEP take 825 the value of a label L as input. In this version of PKCS #1, L is 826 the empty string; other uses of the label are outside the scope of 827 this document. See Appendix A.2.1 for the relevant ASN.1 syntax. 829 RSAES-OAEP is parameterized by the choice of hash function and mask 830 generation function. This choice should be fixed for a given RSA 831 key. Suggested hash and mask generation functions are given in 832 Appendix B. 834 Note. Past results have helpfully clarified the security properties 835 of the OAEP encoding method [OAEP] (roughly the procedure described 836 in step 2 in Section 7.1.1). The background is as follows. In 1994, 837 Bellare and Rogaway [OAEP] introduced a security concept that they 838 denoted plaintext awareness (PA94). They proved that if a 839 deterministic public-key encryption primitive (e.g., RSAEP) is hard 840 to invert without the private key, then the corresponding OAEP-based 841 encryption scheme is plaintext-aware (in the random oracle model), 842 meaning roughly that an adversary cannot produce a valid ciphertext 843 without actually "knowing"the underlying plaintext. Plaintext 844 awareness of an encryption scheme is closely related to the 845 resistance of the scheme against chosen-ciphertext attacks. In such 846 attacks, an adversary is given the opportunity to send queries to an 847 oracle simulating the decryption primitive. Using the results of 848 these queries, the adversary attempts to decrypt a challenge 849 ciphertext. 851 However, there are two flavors of chosen-ciphertext attacks, and PA94 852 implies security against only one of them. The difference relies on 853 what the adversary is allowed to do after she is given the challenge 854 ciphertext. The indifferent attack scenario (denoted CCA1) does not 855 admit any queries to the decryption oracle after the adversary is 856 given the challenge ciphertext, whereas the adaptive scenario 857 (denoted CCA2) does (except that the decryption oracle refuses to 858 decrypt the challenge ciphertext once it is published). In 1998, 859 Bellare and Rogaway, together with Desai and Pointcheval [PA98], came 860 up with a new, stronger notion of plaintext awareness (PA98) that 861 does imply security against CCA2. 863 To summarize, there have been two potential sources for 864 misconception: that PA94 and PA98 are equivalent concepts; or that 865 CCA1 and CCA2 are equivalent concepts. Either assumption leads to 866 the conclusion that the Bellare-Rogaway paper implies security of 867 OAEP against CCA2, which it does not. 869 (Footnote: It might be fair to mention that PKCS #1 v2.0 cites [OAEP] 870 and claims that "a chosen ciphertext attack is ineffective against a 871 plaintext-aware encryption scheme such as RSAES-OAEP" without 872 specifying the kind of plaintext awareness or chosen ciphertext 873 attack considered.) 875 OAEP has never been proven secure against CCA2; in fact, Victor Shoup 876 [SHOUP] has demonstrated that such a proof does not exist in the 877 general case. Put briefly, Shoup showed that an adversary in the 878 CCA2 scenario who knows how to partially invert the encryption 879 primitive but does not know how to invert it completely may well be 880 able to break the scheme. For example, one may imagine an attacker 881 who is able to break RSAES-OAEP if she knows how to recover all but 882 the first 20 bytes of a random integer encrypted with RSAEP. Such an 883 attacker does not need to be able to fully invert RSAEP, because she 884 does not use the first 20 octets in her attack. 886 Still, RSAES-OAEP is secure against CCA2, which was proved by 887 Fujisaki, Okamoto, Pointcheval, and Stern [FOPS] shortly after the 888 announcement of Shoup's result. Using clever lattice reduction 889 techniques, they managed to show how to invert RSAEP completely given 890 a sufficiently large part of the pre-image. This observation, 891 combined with a proof that OAEP is secure against CCA2 if the 892 underlying encryption primitive is hard to partially invert, fills 893 the gap between what Bellare and Rogaway proved about RSAES-OAEP and 894 what some may have believed that they proved. Somewhat 895 paradoxically, we are hence saved by an ostensible weakness in RSAEP 896 (i.e., the whole inverse can be deduced from parts of it). 898 Unfortunately however, the security reduction is not efficient for 899 concrete parameters. While the proof successfully relates an 900 adversary A against the CCA2 security of RSAES-OAEP to an algorithm I 901 inverting RSA, the probability of success for I is only approximately 902 \epsilon^2 / 2^18, where \epsilon is the probability of success for 903 A. 905 (Footnote: In [FOPS] the probability of success for the inverter was 906 \epsilon^2 / 4. The additional factor 1 / 2^16 is due to the eight 907 fixed zero bits at the beginning of the encoded message EM, which are 908 not present in the variant of OAEP considered in [FOPS] (I must apply 909 A twice to invert RSA, and each application corresponds to a factor 1 910 / 2^8).) 912 In addition, the running time for I is approximately t^2, where t is 913 the running time of the adversary. The consequence is that we cannot 914 exclude the possibility that attacking RSAES-OAEP is considerably 915 easier than inverting RSA for concrete parameters. Still, the 916 existence of a security proof provides some assurance that the RSAES- 917 OAEP construction is sounder than ad hoc constructions such as RSAES- 918 PKCS1-v1_5. 920 Hybrid encryption schemes based on the RSA-KEM key encapsulation 921 paradigm offer tight proofs of security directly applicable to 922 concrete parameters; see [ISO18033] for discussion. Future versions 923 of PKCS #1 may specify schemes based on this paradigm. 925 7.1.1. Encryption operation 927 RSAES-OAEP-ENCRYPT ((n, e), M, L) 929 Options: 931 Hash hash function (hLen denotes the length in octets of the hash 932 function output) 933 MGF mask generation function 935 Input: 937 (n, e) recipient's RSA public key (k denotes the length in octets 938 of the RSA modulus n) 939 M message to be encrypted, an octet string of length mLen, 940 where mLen <= k - 2hLen - 2 941 L optional label to be associated with the message; the 942 default value for L, if L is not provided, is the empty 943 string 945 Output: 947 C ciphertext, an octet string of length k 949 Errors: "message too long"; "label too long" 950 Assumption: RSA public key (n, e) is valid 952 Steps: 954 1. Length checking: 956 a. If the length of L is greater than the input limitation 957 for the hash function (2^61 - 1 octets for SHA-1), output 958 "label too long" and stop. 960 b. If mLen > k - 2hLen - 2, output "message too long" and 961 stop. 963 2. EME-OAEP encoding (see Figure 1 below): 965 a. If the label L is not provided, let L be the empty string. 966 Let lHash = Hash(L), an octet string of length hLen (see 967 the note below). 969 b. Generate an octet string PS consisting of k - mLen - 2hLen 970 - 2 zero octets. The length of PS may be zero. 972 c. Concatenate lHash, PS, a single octet with hexadecimal 973 value 0x01, and the message M to form a data block DB of 974 length k - hLen - 1 octets as 976 DB = lHash || PS || 0x01 || M. 978 d. Generate a random octet string seed of length hLen. 980 e. Let dbMask = MGF(seed, k - hLen - 1). 982 f. Let maskedDB = DB \xor dbMask. 984 g. Let seedMask = MGF(maskedDB, hLen). 986 h. Let maskedSeed = seed \xor seedMask. 988 i. Concatenate a single octet with hexadecimal value 0x00, 989 maskedSeed, and maskedDB to form an encoded message EM of 990 length k octets as 992 EM = 0x00 || maskedSeed || maskedDB. 994 3. RSA encryption: 996 a. Convert the encoded message EM to an integer message 997 representative m (see Section 4.2): 999 m = OS2IP (EM). 1001 b. Apply the RSAEP encryption primitive (Section 5.1.1) to 1002 the RSA public key (n, e) and the message representative m 1003 to produce an integer ciphertext representative c: 1005 c = RSAEP ((n, e), m). 1007 c. Convert the ciphertext representative c to a ciphertext C 1008 of length k octets (see Section 4.1): 1010 C = I2OSP (c, k). 1012 4. Output the ciphertext C. 1014 _________________________________________________________________ 1016 +----------+------+--+-------+ 1017 DB = | lHash | PS |01| M | 1018 +----------+------+--+-------+ 1019 | 1020 +----------+ | 1021 | seed | | 1022 +----------+ | 1023 | | 1024 |-------> MGF ---> xor 1025 | | 1026 +--+ V | 1027 |00| xor <----- MGF <-----| 1028 +--+ | | 1029 | | | 1030 V V V 1031 +--+----------+----------------------------+ 1032 EM = |00|maskedSeed| maskedDB | 1033 +--+----------+----------------------------+ 1034 _________________________________________________________________ 1036 Figure 1: EME-OAEP encoding operation. lHash is the hash of the 1037 optional label L. Decoding operation follows reverse steps to 1038 recover M and verify lHash and PS. 1040 Note. If L is the empty string, the corresponding hash value lHash 1041 has the following hexadecimal representation for different choices of 1042 Hash: 1044 SHA-1: (0x)da39a3ee 5e6b4b0d 3255bfef 95601890 afd80709 1045 SHA-256: (0x)e3b0c442 98fc1c14 9afbf4c8 996fb924 27ae41e4 649b934c 1046 a495991b 7852b855 1047 SHA-384: (0x)38b060a7 51ac9638 4cd9327e b1b1e36a 21fdb711 14be0743 1048 4c0cc7bf 63f6e1da 274edebf e76f65fb d51ad2f1 4898b95b 1049 SHA-512: (0x)cf83e135 7eefb8bd f1542850 d66d8007 d620e405 0b5715dc 1050 83f4a921 d36ce9ce 47d0d13c 5d85f2b0 ff8318d2 877eec2f 1051 63b931bd 47417a81 a538327a f927da3e 1053 7.1.2. Decryption operation 1055 RSAES-OAEP-DECRYPT (K, C, L) 1057 Options: 1059 Hash hash function (hLen denotes the length in octets of the hash 1060 function output) 1061 MGF mask generation function 1063 Input: 1065 K recipient's RSA private key (k denotes the length in octets 1066 of the RSA modulus n) 1067 C ciphertext to be decrypted, an octet string of length k, 1068 where k = 2hLen + 2 1069 L optional label whose association with the message is to be 1070 verified; the default value for L, if L is not provided, is 1071 the empty string 1073 Output: 1075 M message, an octet string of length mLen, where mLen <= k - 1076 2hLen - 2 1078 Error: "decryption error" 1080 Steps: 1082 1. Length checking: 1084 a. If the length of L is greater than the input limitation 1085 for the hash function (2^61 - 1 octets for SHA-1), output 1086 "decryption error" and stop. 1088 b. If the length of the ciphertext C is not k octets, output 1089 "decryption error" and stop. 1091 c. If k < 2hLen + 2, output "decryption error" and stop. 1093 2. RSA decryption: 1095 a. Convert the ciphertext C to an integer ciphertext 1096 representative c (see Section 4.2): 1098 c = OS2IP (C). 1100 b. Apply the RSADP decryption primitive (Section 5.1.2) to 1101 the RSA private key K and the ciphertext representative c 1102 to produce an integer message representative m: 1104 m = RSADP (K, c). 1106 If RSADP outputs "ciphertext representative out of range" 1107 (meaning that c >= n), output "decryption error" and stop. 1109 c. Convert the message representative m to an encoded message 1110 EM of length k octets (see Section 4.1): 1112 EM = I2OSP (m, k). 1114 3. EME-OAEP decoding: 1116 a. If the label L is not provided, let L be the empty string. 1117 Let lHash = Hash(L), an octet string of length hLen (see 1118 the note in Section 7.1.1). 1120 b. Separate the encoded message EM into a single octet Y, an 1121 octet string maskedSeed of length hLen, and an octet 1122 string maskedDB of length k - hLen - 1 as 1124 EM = Y || maskedSeed || maskedDB. 1126 c. Let seedMask = MGF(maskedDB, hLen). 1128 d. Let seed = maskedSeed \xor seedMask. 1130 e. Let dbMask = MGF(seed, k - hLen - 1). 1132 f. Let DB = maskedDB \xor dbMask. 1134 g. Separate DB into an octet string lHash' of length hLen, a 1135 (possibly empty) padding string PS consisting of octets 1136 with hexadecimal value 0x00, and a message M as 1138 DB = lHash' || PS || 0x01 || M. 1140 If there is no octet with hexadecimal value 0x01 to 1141 separate PS from M, if lHash does not equal lHash', or if 1142 Y is nonzero, output "decryption error" and stop. (See 1143 the note below.) 1145 4. Output the message M. 1147 Note. Care must be taken to ensure that an opponent cannot 1148 distinguish the different error conditions in Step 3.g, whether by 1149 error message or timing, or, more generally, learn partial 1150 information about the encoded message EM. Otherwise an opponent 1151 may be able to obtain useful information about the decryption of 1152 the ciphertext C, leading to a chosen-ciphertext attack such as 1153 the one observed by Manger [MANGER]. 1155 7.2. RSAES-PKCS1-v1_5 1157 RSAES-PKCS1-v1_5 combines the RSAEP and RSADP primitives (Sections 1158 5.1.1 and 5.1.2) with the EME-PKCS1-v1_5 encoding method (step 1 in 1159 Section 7.2.1 and step 3 in Section 7.2.2). It is mathematically 1160 equivalent to the encryption scheme in PKCS #1 v1.5. RSAES-PKCS1- 1161 v1_5 can operate on messages of length up to k - 11 octets (k is the 1162 octet length of the RSA modulus), although care should be taken to 1163 avoid certain attacks on low-exponent RSA due to Coppersmith, 1164 Franklin, Patarin, and Reiter when long messages are encrypted (see 1165 the third bullet in the notes below and [LOWEXP]; [NEWATTACK] 1166 contains an improved attack). As a general rule, the use of this 1167 scheme for encrypting an arbitrary message, as opposed to a randomly 1168 generated key, is NOT RECOMMENDED. 1170 It is possible to generate valid RSAES-PKCS1-v1_5 ciphertexts without 1171 knowing the corresponding plaintexts, with a reasonable probability 1172 of success. This ability can be exploited in a chosen- ciphertext 1173 attack as shown in [BLEICHENBACHER]. Therefore, if RSAES-PKCS1-v1_5 1174 is to be used, certain easily implemented countermeasures should be 1175 taken to thwart the attack found in [BLEICHENBACHER]. Typical 1176 examples include the addition of structure to the data to be encoded, 1177 rigorous checking of PKCS #1 v1.5 conformance (and other redundancy) 1178 in decrypted messages, and the consolidation of error messages in a 1179 client-server protocol based on PKCS #1 v1.5. These can all be 1180 effective countermeasures and do not involve changes to a PKCS #1 1181 v1.5-based protocol. See [BKS] for a further discussion of these and 1182 other countermeasures. It has recently been shown that the security 1183 of the SSL/TLS handshake protocol [RFC5246], which uses RSAES- 1184 PKCS1-v1_5 and certain countermeasures, can be related to a variant 1185 of the RSA problem; see [RSATLS] for discussion. 1187 Note. The following passages describe some security recommendations 1188 pertaining to the use of RSAES-PKCS1-v1_5. Recommendations from 1189 version 1.5 of this document are included as well as new 1190 recommendations motivated by cryptanalytic advances made in the 1191 intervening years. 1193 o It is RECOMMENDED that the pseudorandom octets in step 2 in 1194 Section 7.2.1 be generated independently for each encryption 1195 process, especially if the same data is input to more than one 1196 encryption process. Haastad's results [HAASTAD] are one 1197 motivation for this recommendation. 1199 o The padding string PS in step 2 in Section 7.2.1 is at least eight 1200 octets long, which is a security condition for public-key 1201 operations that makes it difficult for an attacker to recover data 1202 by trying all possible encryption blocks. 1204 o The pseudorandom octets can also help thwart an attack due to 1205 Coppersmith et al. [LOWEXP] (see [NEWATTACK] for an improvement 1206 of the attack) when the size of the message to be encrypted is 1207 kept small. The attack works on low-exponent RSA when similar 1208 messages are encrypted with the same RSA public key. More 1209 specifically, in one flavor of the attack, when two inputs to 1210 RSAEP agree on a large fraction of bits (8/9) and low-exponent RSA 1211 (e = 3) is used to encrypt both of them, it may be possible to 1212 recover both inputs with the attack. Another flavor of the attack 1213 is successful in decrypting a single ciphertext when a large 1214 fraction (2/3) of the input to RSAEP is already known. For 1215 typical applications, the message to be encrypted is short (e.g., 1216 a 128-bit symmetric key) so not enough information will be known 1217 or common between two messages to enable the attack. However, if 1218 a long message is encrypted, or if part of a message is known, 1219 then the attack may be a concern. In any case, the RSAES-OAEP 1220 scheme overcomes the attack. 1222 7.2.1. Encryption operation 1224 RSAES-PKCS1-V1_5-ENCRYPT ((n, e), M) 1226 Input: 1228 (n, e) recipient's RSA public key (k denotes the length in octets 1229 of the modulus n) 1230 M message to be encrypted, an octet string of length mLen, 1231 where mLen <= k - 11 1233 Output: 1235 C ciphertext, an octet string of length k 1237 Error: "message too long" 1239 Steps: 1241 1. Length checking: If mLen > k - 11, output "message too long" 1242 and stop. 1244 2. EME-PKCS1-v1_5 encoding: 1246 a. Generate an octet string PS of length k - mLen - 3 1247 consisting of pseudo-randomly generated nonzero octets. 1248 The length of PS will be at least eight octets. 1250 b. Concatenate PS, the message M, and other padding to form 1251 an encoded message EM of length k octets as 1253 EM = 0x00 || 0x02 || PS || 0x00 || M. 1255 3. RSA encryption: 1257 a. Convert the encoded message EM to an integer message 1258 representative m (see Section 4.2): 1260 m = OS2IP (EM). 1262 b. Apply the RSAEP encryption primitive (Section 5.1.1) to 1263 the RSA public key (n, e) and the message representative m 1264 to produce an integer ciphertext representative c: 1266 c = RSAEP ((n, e), m). 1268 c. Convert the ciphertext representative c to a ciphertext C 1269 of length k octets (see Section 4.1): 1271 C = I2OSP (c, k). 1273 4. Output the ciphertext C. 1275 7.2.2. Decryption Operation 1277 RSAES-PKCS1-V1_5-DECRYPT (K, C) 1279 Input: 1281 K recipient's RSA private key 1282 C ciphertext to be decrypted, an octet string of length k, 1283 where k is the length in octets of the RSA modulus n 1285 Output: 1287 M message, an octet string of length at most k - 11 1289 Error: "decryption error" 1291 Steps: 1293 1. Length checking: If the length of the ciphertext C is not k 1294 octets (or if k < 11), output "decryption error" and stop. 1296 2. RSA decryption: 1298 a. Convert the ciphertext C to an integer ciphertext 1299 representative c (see Section 4.2): 1301 c = OS2IP (C). 1303 b. Apply the RSADP decryption primitive (Section 5.1.2) to 1304 the RSA private key (n, d) and the ciphertext 1305 representative c to produce an integer message 1306 representative m: 1308 m = RSADP ((n, d), c). 1310 If RSADP outputs "ciphertext representative out of range" 1311 (meaning that c >= n), output "decryption error" and stop. 1313 c. Convert the message representative m to an encoded message 1314 EM of length k octets (see Section 4.1): 1316 EM = I2OSP (m, k). 1318 3. EME-PKCS1-v1_5 decoding: Separate the encoded message EM into 1319 an octet string PS consisting of nonzero octets and a message 1320 M as 1322 EM = 0x00 || 0x02 || PS || 0x00 || M. 1324 If the first octet of EM does not have hexadecimal value 0x00, 1325 if the second octet of EM does not have hexadecimal value 1326 0x02, if there is no octet with hexadecimal value 0x00 to 1327 separate PS from M, or if the length of PS is less than 8 1328 octets, output "decryption error" and stop. (See the note 1329 below.) 1331 4. Output M. 1333 Note. Care shall be taken to ensure that an opponent cannot 1334 distinguish the different error conditions in Step 3, whether by 1335 error message or timing. Otherwise an opponent may be able to 1336 obtain useful information about the decryption of the ciphertext 1337 C, leading to a strengthened version of Bleichenbacher's attack 1338 [BLEICHENBACHER]; compare to Manger's attack [MANGER]. 1340 8. Signature scheme with appendix 1342 For the purposes of this document, a signature scheme with appendix 1343 consists of a signature generation operation and a signature 1344 verification operation, where the signature generation operation 1345 produces a signature from a message with a signer's RSA private key, 1346 and the signature verification operation verifies the signature on 1347 the message with the signer's corresponding RSA public key. To 1348 verify a signature constructed with this type of scheme it is 1349 necessary to have the message itself. In this way, signature schemes 1350 with appendix are distinguished from signature schemes with message 1351 recovery, which are not supported in this document. 1353 A signature scheme with appendix can be employed in a variety of 1354 applications. For instance, the signature schemes with appendix 1355 defined here would be suitable signature algorithms for X.509 1356 certificates [ISO9594]. Related signature schemes could be employed 1357 in PKCS #7 [RFC2315], although for technical reasons the current 1358 version of PKCS #7 separates a hash function from a signature scheme, 1359 which is different than what is done here; see the note in 1360 Appendix A.2.3 for more discussion. 1362 Two signature schemes with appendix are specified in this document: 1363 RSASSA-PSS and RSASSA-PKCS1-v1_5. Although no attacks are known 1364 against RSASSA-PKCS1-v1_5, in the interest of increased robustness, 1365 RSASSA-PSS is REQUIRED in new applications. RSASSA-PKCS1-v1_5 is 1366 included only for compatibility with existing applications. 1368 The signature schemes with appendix given here follow a general model 1369 similar to that employed in IEEE 1363-2000 [IEEE1363], combining 1370 signature and verification primitives with an encoding method for 1371 signatures. The signature generation operations apply a message 1372 encoding operation to a message to produce an encoded message, which 1373 is then converted to an integer message representative. A signature 1374 primitive is applied to the message representative to produce the 1375 signature. Reversing this, the signature verification operations 1376 apply a signature verification primitive to the signature to recover 1377 a message representative, which is then converted to an octet string 1378 encoded message. A verification operation is applied to the message 1379 and the encoded message to determine whether they are consistent. 1381 If the encoding method is deterministic (e.g., EMSA-PKCS1-v1_5), the 1382 verification operation may apply the message encoding operation to 1383 the message and compare the resulting encoded message to the 1384 previously derived encoded message. If there is a match, the 1385 signature is considered valid. If the method is randomized (e.g., 1386 EMSA-PSS), the verification operation is typically more complicated. 1387 For example, the verification operation in EMSA-PSS extracts the 1388 random salt and a hash output from the encoded message and checks 1389 whether the hash output, the salt, and the message are consistent; 1390 the hash output is a deterministic function in terms of the message 1391 and the salt. For both signature schemes with appendix defined in 1392 this document, the signature generation and signature verification 1393 operations are readily implemented as "single-pass" operations if the 1394 signature is placed after the message. See PKCS #7 [RFC2315] for an 1395 example format in the case of RSASSA-PKCS1-v1_5. 1397 8.1. RSASSA-PSS 1399 RSASSA-PSS combines the RSASP1 and RSAVP1 primitives with the EMSA- 1400 PSS encoding method. It is compatible with the IFSSA scheme as 1401 amended in the IEEE 1363a-2004 [IEEE1363A], where the signature and 1402 verification primitives are IFSP-RSA1 and IFVP-RSA1 as defined in 1403 IEEE 1363-2000 [IEEE1363] and the message encoding method is EMSA4. 1404 EMSA4 is slightly more general than EMSA-PSS as it acts on bit 1405 strings rather than on octet strings. EMSA-PSS is equivalent to 1406 EMSA4 restricted to the case that the operands as well as the hash 1407 and salt values are octet strings. 1409 The length of messages on which RSASSA-PSS can operate is either 1410 unrestricted or constrained by a very large number, depending on the 1411 hash function underlying the EMSA-PSS encoding method. 1413 Assuming that computing e-th roots modulo n is infeasible and the 1414 hash and mask generation functions in EMSA-PSS have appropriate 1415 properties, RSASSA-PSS provides secure signatures. This assurance is 1416 provable in the sense that the difficulty of forging signatures can 1417 be directly related to the difficulty of inverting the RSA function, 1418 provided that the hash and mask generation functions are viewed as 1419 black boxes or random oracles. The bounds in the security proof are 1420 essentially "tight", meaning that the success probability and running 1421 time for the best forger against RSASSA-PSS are very close to the 1422 corresponding parameters for the best RSA inversion algorithm; see 1423 [RSARABIN][PSSPROOF][JONSSON] for further discussion. 1425 In contrast to the RSASSA-PKCS1-v1_5 signature scheme, a hash 1426 function identifier is not embedded in the EMSA-PSS encoded message, 1427 so in theory it is possible for an adversary to substitute a 1428 different (and potentially weaker) hash function than the one 1429 selected by the signer. Therefore, it is RECOMMENDED that the EMSA- 1430 PSS mask generation function be based on the same hash function. In 1431 this manner the entire encoded message will be dependent on the hash 1432 function and it will be difficult for an opponent to substitute a 1433 different hash function than the one intended by the signer. This 1434 matching of hash functions is only for the purpose of preventing hash 1435 function substitution, and is not necessary if hash function 1436 substitution is addressed by other means (e.g., the verifier accepts 1437 only a designated hash function). See [HASHID] for further 1438 discussion of these points. The provable security of RSASSA-PSS does 1439 not rely on the hash function in the mask generation function being 1440 the same as the hash function applied to the message. 1442 RSASSA-PSS is different from other RSA-based signature schemes in 1443 that it is probabilistic rather than deterministic, incorporating a 1444 randomly generated salt value. The salt value enhances the security 1445 of the scheme by affording a "tighter" security proof than 1446 deterministic alternatives such as Full Domain Hashing (FDH); see 1447 [RSARABIN] for discussion. However, the randomness is not critical 1448 to security. In situations where random generation is not possible, 1449 a fixed value or a sequence number could be employed instead, with 1450 the resulting provable security similar to that of FDH [FDH]. 1452 8.1.1. Signature generation operation 1454 RSASSA-PSS-SIGN (K, M) 1456 Input: 1458 K signer's RSA private key 1459 M message to be signed, an octet string 1461 Output: 1463 S signature, an octet string of length k, where k is the 1464 length in octets of the RSA modulus n 1466 Errors: "message too long;" "encoding error" 1467 Steps: 1469 1. EMSA-PSS encoding: Apply the EMSA-PSS encoding operation 1470 (Section 9.1.1) to the message M to produce an encoded message 1471 EM of length \ceil ((modBits - 1)/8) octets such that the bit 1472 length of the integer OS2IP (EM) (see Section 4.2) is at most 1473 modBits - 1, where modBits is the length in bits of the RSA 1474 modulus n: 1476 EM = EMSA-PSS-ENCODE (M, modBits - 1). 1478 Note that the octet length of EM will be one less than k if 1479 modBits - 1 is divisible by 8 and equal to k otherwise. If 1480 the encoding operation outputs "message too long," output 1481 "message too long" and stop. If the encoding operation 1482 outputs "encoding error," output "encoding error" and stop. 1484 2. RSA signature: 1486 a. Convert the encoded message EM to an integer message 1487 representative m (see Section 4.2): 1489 m = OS2IP (EM). 1491 b. Apply the RSASP1 signature primitive (Section 5.2.1) to 1492 the RSA private key K and the message representative m to 1493 produce an integer signature representative s: 1495 s = RSASP1 (K, m). 1497 c. Convert the signature representative s to a signature S of 1498 length k octets (see Section 4.1): 1500 S = I2OSP (s, k). 1502 3. Output the signature S. 1504 8.1.2. Signature verification operation 1506 RSASSA-PSS-VERIFY ((n, e), M, S) 1508 Input: 1510 (n, e) signer's RSA public key 1511 M message whose signature is to be verified, an octet string 1512 S signature to be verified, an octet string of length k, where 1513 k is the length in octets of the RSA modulus n 1515 Output: "valid signature" or "invalid signature" 1517 Steps: 1519 1. Length checking: If the length of the signature S is not k 1520 octets, output "invalid signature" and stop. 1522 2. RSA verification: 1524 a. Convert the signature S to an integer signature 1525 representative s (see Section 4.2): 1527 s = OS2IP (S). 1529 b. Apply the RSAVP1 verification primitive (Section 5.2.2) to 1530 the RSA public key (n, e) and the signature representative 1531 s to produce an integer message representative m: 1533 m = RSAVP1 ((n, e), s). 1535 If RSAVP1 output "signature representative out of range," 1536 output "invalid signature" and stop. 1538 c. Convert the message representative m to an encoded message 1539 EM of length emLen = \ceil ((modBits - 1)/8) octets, where 1540 modBits is the length in bits of the RSA modulus n (see 1541 Section 4.1): 1543 EM = I2OSP (m, emLen). 1545 Note that emLen will be one less than k if modBits - 1 is 1546 divisible by 8 and equal to k otherwise. If I2OSP outputs 1547 "integer too large," output "invalid signature" and stop. 1549 3. EMSA-PSS verification: Apply the EMSA-PSS verification 1550 operation (Section 9.1.2) to the message M and the encoded 1551 message EM to determine whether they are consistent: 1553 Result = EMSA-PSS-VERIFY (M, EM, modBits - 1). 1555 4. If Result = "consistent," output "valid signature." 1556 Otherwise, output "invalid signature." 1558 8.2. RSASSA-PKCS1-v1_5 1560 RSASSA-PKCS1-v1_5 combines the RSASP1 and RSAVP1 primitives with the 1561 EMSA-PKCS1-v1_5 encoding method. It is compatible with the IFSSA 1562 scheme defined in IEEE 1363-2000 [IEEE1363], where the signature and 1563 verification primitives are IFSP-RSA1 and IFVP-RSA1 and the message 1564 encoding method is EMSA-PKCS1-v1_5 (which is not defined in IEEE 1565 1363-2000, but is in the IEEE 1363a-2004 [IEEE1363A]). 1567 The length of messages on which RSASSA-PKCS1-v1_5 can operate is 1568 either unrestricted or constrained by a very large number, depending 1569 on the hash function underlying the EMSA-PKCS1-v1_5 method. 1571 Assuming that computing e-th roots modulo n is infeasible and the 1572 hash function in EMSA-PKCS1-v1_5 has appropriate properties, RSASSA- 1573 PKCS1-v1_5 is conjectured to provide secure signatures. More 1574 precisely, forging signatures without knowing the RSA private key is 1575 conjectured to be computationally infeasible. Also, in the encoding 1576 method EMSA-PKCS1-v1_5, a hash function identifier is embedded in the 1577 encoding. Because of this feature, an adversary trying to find a 1578 message with the same signature as a previously signed message must 1579 find collisions of the particular hash function being used; attacking 1580 a different hash function than the one selected by the signer is not 1581 useful to the adversary. See [HASHID] for further discussion. 1583 Note: As noted in PKCS #1 v1.5, the EMSA-PKCS1-v1_5 encoding method 1584 has the property that the encoded message, converted to an integer 1585 message representative, is guaranteed to be large and at least 1586 somewhat "random". This prevents attacks of the kind proposed by 1587 Desmedt and Odlyzko [CHOSEN] where multiplicative relationships 1588 between message representatives are developed by factoring the 1589 message representatives into a set of small values (e.g., a set of 1590 small primes). Coron, Naccache, and Stern [PADDING] showed that a 1591 stronger form of this type of attack could be quite effective against 1592 some instances of the ISO/IEC 9796-2 signature scheme. They also 1593 analyzed the complexity of this type of attack against the EMSA- 1594 PKCS1-v1_5 encoding method and concluded that an attack would be 1595 impractical, requiring more operations than a collision search on the 1596 underlying hash function (i.e., more than 2^80 operations). 1597 Coppersmith, Halevi, and Jutla [FORGERY] subsequently extended Coron 1598 et al.'s attack to break the ISO/IEC 9796-1 signature scheme with 1599 message recovery. The various attacks illustrate the importance of 1600 carefully constructing the input to the RSA signature primitive, 1601 particularly in a signature scheme with message recovery. 1602 Accordingly, the EMSA-PKCS-v1_5 encoding method explicitly includes a 1603 hash operation and is not intended for signature schemes with message 1604 recovery. Moreover, while no attack is known against the EMSA-PKCS- 1605 v1_5 encoding method, a gradual transition to EMSA-PSS is recommended 1606 as a precaution against future developments. 1608 8.2.1. Signature generation operation 1610 RSASSA-PKCS1-V1_5-SIGN (K, M) 1612 Input: 1614 K signer's RSA private key 1615 M message to be signed, an octet string 1617 Output: 1619 S signature, an octet string of length k, where k is the 1620 length in octets of the RSA modulus n 1622 Errors: "message too long"; "RSA modulus too short" 1624 Steps: 1626 1. EMSA-PKCS1-v1_5 encoding: Apply the EMSA-PKCS1-v1_5 encoding 1627 operation (Section 9.2) to the message M to produce an encoded 1628 message EM of length k octets: 1630 EM = EMSA-PKCS1-V1_5-ENCODE (M, k). 1632 If the encoding operation outputs "message too long," output 1633 "message too long" and stop. If the encoding operation 1634 outputs "intended encoded message length too short," output 1635 "RSA modulus too short" and stop. 1637 2. RSA signature: 1639 a. Convert the encoded message EM to an integer message 1640 representative m (see Section 4.2): 1642 m = OS2IP (EM). 1644 b. Apply the RSASP1 signature primitive (Section 5.2.1) to 1645 the RSA private key K and the message representative m to 1646 produce an integer signature representative s: 1648 s = RSASP1 (K, m). 1650 c. Convert the signature representative s to a signature S of 1651 length k octets (see Section 4.1): 1653 S = I2OSP (s, k). 1655 3. Output the signature S. 1657 8.2.2. Signature verification operation 1659 RSASSA-PKCS1-V1_5-VERIFY ((n, e), M, S) 1661 Input: 1663 (n, e) signer's RSA public key 1664 M message whose signature is to be verified, an octet string 1665 S signature to be verified, an octet string of length k, where 1666 k is the length in octets of the RSA modulus n 1668 Output "valid signature" or "invalid signature" 1670 Errors: "message too long"; "RSA modulus too short" 1672 Steps: 1674 1. Length checking: If the length of the signature S is not k 1675 octets, output "invalid signature" and stop. 1677 2. RSA verification: 1679 a. Convert the signature S to an integer signature 1680 representative s (see Section 4.2): 1682 s = OS2IP (S). 1684 b. Apply the RSAVP1 verification primitive (Section 5.2.2) to 1685 the RSA public key (n, e) and the signature representative 1686 s to produce an integer message representative m: 1688 m = RSAVP1 ((n, e), s). 1690 If RSAVP1 outputs "signature representative out of range," 1691 output "invalid signature" and stop. 1693 c. Convert the message representative m to an encoded message 1694 EM of length k octets (see Section 4.1): 1696 EM' = I2OSP (m, k). 1698 If I2OSP outputs "integer too large," output "invalid 1699 signature" and stop. 1701 3. EMSA-PKCS1-v1_5 encoding: Apply the EMSA-PKCS1-v1_5 encoding 1702 operation (Section 9.2) to the message M to produce a second 1703 encoded message EM' of length k octets: 1705 EM' = EMSA-PKCS1-V1_5-ENCODE (M, k). 1707 If the encoding operation outputs "message too long," output 1708 "message too long" and stop. If the encoding operation 1709 outputs "intended encoded message length too short," output 1710 "RSA modulus too short" and stop. 1712 4. Compare the encoded message EM and the second encoded message 1713 EM'. If they are the same, output "valid signature"; 1714 otherwise, output "invalid signature." 1716 Note. Another way to implement the signature verification 1717 operation is to apply a "decoding" operation (not specified in 1718 this document) to the encoded message to recover the underlying 1719 hash value, and then to compare it to a newly computed hash value. 1720 This has the advantage that it requires less intermediate storage 1721 (two hash values rather than two encoded messages), but the 1722 disadvantage that it requires additional code. 1724 9. Encoding methods for signatures with appendix 1726 Encoding methods consist of operations that map between octet string 1727 messages and octet string encoded messages, which are converted to 1728 and from integer message representatives in the schemes. The integer 1729 message representatives are processed via the primitives. The 1730 encoding methods thus provide the connection between the schemes, 1731 which process messages, and the primitives. 1733 An encoding method for signatures with appendix, for the purposes of 1734 this document, consists of an encoding operation and optionally a 1735 verification operation. An encoding operation maps a message M to an 1736 encoded message EM of a specified length. A verification operation 1737 determines whether a message M and an encoded message EM are 1738 consistent, i.e., whether the encoded message EM is a valid encoding 1739 of the message M. 1741 The encoding operation may introduce some randomness, so that 1742 different applications of the encoding operation to the same message 1743 will produce different encoded messages, which has benefits for 1744 provable security. For such an encoding method, both an encoding and 1745 a verification operation are needed unless the verifier can reproduce 1746 the randomness (e.g., by obtaining the salt value from the signer). 1747 For a deterministic encoding method only an encoding operation is 1748 needed. 1750 Two encoding methods for signatures with appendix are employed in the 1751 signature schemes and are specified here: EMSA-PSS and EMSA- 1752 PKCS1-v1_5. 1754 9.1. EMSA-PSS 1756 This encoding method is parameterized by the choice of hash function, 1757 mask generation function, and salt length. These options should be 1758 fixed for a given RSA key, except that the salt length can be 1759 variable (see [JONSSON] for discussion). Suggested hash and mask 1760 generation functions are given in Appendix B. The encoding method is 1761 based on Bellare and Rogaway's Probabilistic Signature Scheme (PSS) 1762 [RSARABIN][PSS]. It is randomized and has an encoding operation and 1763 a verification operation. 1765 Figure 2 illustrates the encoding operation. 1767 __________________________________________________________________ 1769 +-----------+ 1770 | M | 1771 +-----------+ 1772 | 1773 V 1774 Hash 1775 | 1776 V 1777 +--------+----------+----------+ 1778 M' = |Padding1| mHash | salt | 1779 +--------+----------+----------+ 1780 | 1781 +--------+----------+ V 1782 DB = |Padding2| salt | Hash 1783 +--------+----------+ | 1784 | | 1785 V | 1786 xor <--- MGF <---| 1787 | | 1788 | | 1789 V V 1790 +-------------------+----------+--+ 1791 EM = | maskedDB | H |bc| 1792 +-------------------+----------+--+ 1793 __________________________________________________________________ 1795 Figure 2: EMSA-PSS encoding operation. Verification operation 1796 follows reverse steps to recover salt, then forward steps to 1797 recompute and compare H. 1799 Notes. 1801 1. The encoding method defined here differs from the one in Bellare 1802 and Rogaway's submission to IEEE 1363a-2004 [PSS] in three 1803 respects: 1805 * It applies a hash function rather than a mask generation 1806 function to the message. Even though the mask generation 1807 function is based on a hash function, it seems more natural to 1808 apply a hash function directly. 1810 * The value that is hashed together with the salt value is the 1811 string (0x)00 00 00 00 00 00 00 00 || mHash rather than the 1812 message M itself. Here, mHash is the hash of M. Note that 1813 the hash function is the same in both steps. See Note 3 below 1814 for further discussion. (Also, the name "salt" is used 1815 instead of "seed", as it is more reflective of the value's 1816 role.) 1818 * The encoded message in EMSA-PSS has nine fixed bits; the first 1819 bit is 0 and the last eight bits form a "trailer field", the 1820 octet 0xbc. In the original scheme, only the first bit is 1821 fixed. The rationale for the trailer field is for 1822 compatibility with the Rabin-Williams IFSP-RW signature 1823 primitive in IEEE 1363-2000 [IEEE1363] and the corresponding 1824 primitive in ISO/IEC 9796-2:2010 [ISO9796]. 1826 2. Assuming that the mask generation function is based on a hash 1827 function, it is RECOMMENDED that the hash function be the same as 1828 the one that is applied to the message; see Section 8.1 for 1829 further discussion. 1831 3. Without compromising the security proof for RSASSA-PSS, one may 1832 perform steps 1 and 2 of EMSA-PSS-ENCODE and EMSA-PSS-VERIFY (the 1833 application of the hash function to the message) outside the 1834 module that computes the rest of the signature operation, so that 1835 mHash rather than the message M itself is input to the module. 1836 In other words, the security proof for RSASSA-PSS still holds 1837 even if an opponent can control the value of mHash. This is 1838 convenient if the module has limited I/O bandwidth, e.g., a smart 1839 card. Note that previous versions of PSS [RSARABIN][PSS] did not 1840 have this property. Of course, it may be desirable for other 1841 security reasons to have the module process the full message. 1842 For instance, the module may need to "see" what it is signing if 1843 it does not trust the component that computes the hash value. 1845 4. Typical salt lengths in octets are hLen (the length of the output 1846 of the hash function Hash) and 0. In both cases the security of 1847 RSASSA-PSS can be closely related to the hardness of inverting 1848 RSAVP1. Bellare and Rogaway [RSARABIN] give a tight lower bound 1849 for the security of the original RSA-PSS scheme, which 1850 corresponds roughly to the former case, while Coron [FDH] gives a 1851 lower bound for the related Full Domain Hashing scheme, which 1852 corresponds roughly to the latter case. In [PSSPROOF] Coron 1853 provides a general treatment with various salt lengths ranging 1854 from 0 to hLen; see [IEEE1363A] for discussion. See also 1855 [JONSSON], which adapts the security proofs in 1856 [RSARABIN][PSSPROOF] to address the differences between the 1857 original and the present version of RSA-PSS as listed in Note 1 1858 above. 1860 5. As noted in IEEE 1363a-2004 [IEEE1363A], the use of randomization 1861 in signature schemes -- such as the salt value in EMSA-PSS -- may 1862 provide a "covert channel" for transmitting information other 1863 than the message being signed. For more on covert channels, see 1864 [SIMMONS]. 1866 9.1.1. Encoding operation 1868 EMSA-PSS-ENCODE (M, emBits) 1870 Options: 1872 Hash hash function (hLen denotes the length in octets of the hash 1873 function output) 1874 MGF mask generation function 1875 sLen intended length in octets of the salt 1877 Input: 1879 M message to be encoded, an octet string 1880 emBits maximal bit length of the integer OS2IP (EM) (see Section 1881 4.2), at least 8hLen + 8sLen + 9 1883 Output: 1885 EM encoded message, an octet string of length emLen = \ceil 1886 (emBits/8) 1888 Errors: "Encoding error"; "message too long" 1890 Steps: 1892 1. If the length of M is greater than the input limitation for 1893 the hash function (2^61 - 1 octets for SHA-1), output 1894 "message too long" and stop. 1896 2. Let mHash = Hash(M), an octet string of length hLen. 1898 3. If emLen < hLen + sLen + 2, output "encoding error" and stop. 1900 4. Generate a random octet string salt of length sLen; if sLen = 1901 0, then salt is the empty string. 1903 5. Let 1905 M' = (0x)00 00 00 00 00 00 00 00 || mHash || salt; 1907 M' is an octet string of length 8 + hLen + sLen with eight 1908 initial zero octets. 1910 6. Let H = Hash(M'), an octet string of length hLen. 1912 7. Generate an octet string PS consisting of emLen - sLen - hLen 1913 - 2 zero octets. The length of PS may be 0. 1915 8. Let DB = PS || 0x01 || salt; DB is an octet string of length 1916 emLen - hLen - 1. 1918 9. Let dbMask = MGF(H, emLen - hLen - 1). 1920 10. Let maskedDB = DB \xor dbMask. 1922 11. Set the leftmost 8emLen - emBits bits of the leftmost octet 1923 in maskedDB to zero. 1925 12. Let EM = maskedDB || H || 0xbc. 1927 13. Output EM. 1929 9.1.2. Verification operation 1931 EMSA-PSS-VERIFY (M, EM, emBits) 1933 Options: 1935 Hash hash function (hLen denotes the length in octets of the hash 1936 function output) 1937 MGF mask generation function 1938 sLen intended length in octets of the salt 1940 Input: 1942 M message to be verified, an octet string 1943 EM encoded message, an octet string of length emLen = \ceil 1944 (emBits/8) 1945 emBits maximal bit length of the integer OS2IP (EM) (see Section 1946 4.2), at least 8hLen + 8sLen + 9 1948 Output: "consistent" or "inconsistent" 1950 Steps: 1952 1. If the length of M is greater than the input limitation for 1953 the hash function (2^61 - 1 octets for SHA-1), output 1954 "inconsistent" and stop. 1956 2. Let mHash = Hash(M), an octet string of length hLen. 1958 3. If emLen < hLen + sLen + 2, output "inconsistent" and stop. 1960 4. If the rightmost octet of EM does not have hexadecimal value 1961 0xbc, output "inconsistent" and stop. 1963 5. Let maskedDB be the leftmost emLen - hLen - 1 octets of EM, 1964 and let H be the next hLen octets. 1966 6. If the leftmost 8emLen - emBits bits of the leftmost octet in 1967 maskedDB are not all equal to zero, output "inconsistent" and 1968 stop. 1970 7. Let dbMask = MGF(H, emLen - hLen - 1). 1972 8. Let DB = maskedDB \xor dbMask. 1974 9. Set the leftmost 8emLen - emBits bits of the leftmost octet 1975 in DB to zero. 1977 10. If the emLen - hLen - sLen - 2 leftmost octets of DB are not 1978 zero or if the octet at position emLen - hLen - sLen - 1 (the 1979 leftmost position is "position 1") does not have hexadecimal 1980 value 0x01, output "inconsistent" and stop. 1982 11. Let salt be the last sLen octets of DB. 1984 12. Let 1986 M' = (0x)00 00 00 00 00 00 00 00 || mHash || salt ; 1988 M' is an octet string of length 8 + hLen + sLen with eight 1989 initial zero octets. 1991 13. Let H' = Hash(M'), an octet string of length hLen. 1993 14. If H = H', output "consistent." Otherwise, output 1994 "inconsistent." 1996 9.2. EMSA-PKCS1-v1_5 1998 This encoding method is deterministic and only has an encoding 1999 operation. 2001 EMSA-PKCS1-v1_5-ENCODE (M, emLen) 2003 Option: 2005 Hash hash function (hLen denotes the length in octets of the hash 2006 function output) 2008 Input: 2010 M message to be encoded 2011 emLen intended length in octets of the encoded message, at least 2012 tLen + 11, where tLen is the octet length of the DER 2013 encoding T of a certain value computed during the encoding 2014 operation 2016 Output: 2018 EM encoded message, an octet string of length emLen 2020 Errors: "message too long"; "intended encoded message length too 2021 short" 2023 Steps: 2025 1. Apply the hash function to the message M to produce a hash 2026 value H: 2028 H = Hash(M). 2030 If the hash function outputs "message too long," output 2031 "message too long" and stop. 2033 2. Encode the algorithm ID for the hash function and the hash 2034 value into an ASN.1 value of type DigestInfo (see 2035 Appendix A.2.4) with the Distinguished Encoding Rules (DER), 2036 where the type DigestInfo has the syntax 2037 DigestInfo ::= SEQUENCE { 2038 digestAlgorithm AlgorithmIdentifier, 2039 digest OCTET STRING 2040 } 2042 The first field identifies the hash function and the second 2043 contains the hash value. Let T be the DER encoding of the 2044 DigestInfo value (see the notes below) and let tLen be the 2045 length in octets of T. 2047 3. If emLen < tLen + 11, output "intended encoded message length 2048 too short" and stop. 2050 4. Generate an octet string PS consisting of emLen - tLen - 3 2051 octets with hexadecimal value 0xff. The length of PS will be 2052 at least 8 octets. 2054 5. Concatenate PS, the DER encoding T, and other padding to form 2055 the encoded message EM as 2057 EM = 0x00 || 0x01 || PS || 0x00 || T. 2059 6. Output EM. 2061 Notes. 2063 1. For the six hash functions mentioned in Appendix B.1, the DER 2064 encoding T of the DigestInfo value is equal to the following: 2066 MD2: (0x)30 20 30 0c 06 08 2a 86 48 86 f7 0d 02 02 05 00 04 2067 10 || H. 2068 MD5: (0x)30 20 30 0c 06 08 2a 86 48 86 f7 0d 02 05 05 00 04 2069 10 || H. 2070 SHA-1: (0x)30 21 30 09 06 05 2b 0e 03 02 1a 05 00 04 14 || H. 2071 SHA-256: (0x)30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 2072 04 20 || H. 2073 SHA-384: (0x)30 41 30 0d 06 09 60 86 48 01 65 03 04 02 02 05 00 2074 04 30 || H. 2075 SHA-512: (0x)30 51 30 0d 06 09 60 86 48 01 65 03 04 02 03 05 00 2076 04 40 || H. 2077 SHA-512/224: (0x)30 2d 30 0d 06 09 60 86 48 01 65 03 04 02 05 2078 05 00 04 1c || H. 2079 SHA-512/256: (0x)30 31 30 0d 06 09 60 86 48 01 65 03 04 02 06 2080 05 00 04 20 || H. 2082 2. In version 1.5 of this document, T was defined as the BER 2083 encoding, rather than the DER encoding, of the DigestInfo value. 2084 In particular, it is possible - at least in theory - that the 2085 verification operation defined in this document (as well as in 2086 version 2.0) rejects a signature that is valid with respect to 2087 the specification given in PKCS #1 v1.5. This occurs if other 2088 rules than DER are applied to DigestInfo (e.g., an indefinite 2089 length encoding of the underlying SEQUENCE type). While this is 2090 unlikely to be a concern in practice, a cautious implementer may 2091 choose to employ a verification operation based on a BER decoding 2092 operation as specified in PKCS #1 v1.5. In this manner, 2093 compatibility with any valid implementation based on PKCS #1 v1.5 2094 is obtained. Such a verification operation should indicate 2095 whether the underlying BER encoding is a DER encoding and hence 2096 whether the signature is valid with respect to the specification 2097 given in this document. 2099 10. IANA Considerations 2101 This memo includes no request to IANA. 2103 11. Security Considerations 2105 Security considerations are discussed throughout this memo. 2107 12. References 2109 12.1. Normative References 2111 [GARNER] Garner, H., "The Residue Number System", IRE Transactions 2112 on Electronic Computers EC-8 (6), pp. 140-147, June 1959. 2114 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2115 Requirement Levels", BCP 14, RFC 2119, 2116 DOI 10.17487/RFC2119, March 1997, 2117 . 2119 [RSA] Rivest, R., Shamir, A., and L. Adleman, "A Method for 2120 Obtaining Digital Signatures and Public-Key 2121 Cryptosystems", Communications of the ACM 21 (2), pp. 2122 120-126, February 1978. 2124 12.2. Informative References 2126 [ANSIX944] 2127 ANSI, "ANSI X9.44-2007: Key Extablishment Using Integer 2128 Factorization Cryptography", March 2002. 2130 [BKS] Bleichenbacher, D., Kaliski, B., and J. Staddon, "Recent 2131 Results on PKCS #1: RSA Encryption Standard", RSA 2132 Laboratories' Bulletin No. 7, June 1998. 2134 [BLEICHENBACHER] 2135 Bleichenbacher, D., "Chosen Ciphertext Attacks Against 2136 Protocols Based on the RSA Encryption Standard PKCS #1", 2137 Lecture Notes in Computer Science Volume 1462, pp. 1-12, 2138 1998. 2140 [CHOSEN] Desmedt, Y. and A. Odlyzko, "A Chosen Text Attack on the 2141 RSA Cryptosystem and Some Discrete Logarithm schemes", 2142 Lecture Notes in Computer Science Volume 218, pp. 516-522, 2143 1986. 2145 [COCHRAN] Cochran, M., "Notes on the Wang et al. 2^63 SHA-1 2146 Differential Path", August 2008, 2147 . 2149 [FASTDEC] Quisquater, J. and C. Couvreur, "Fast Decipherment 2150 Algorithm for RSA Public-Key Cryptosystem", Electronics 2151 Letters 18 (21), pp 905-907, October 1982. 2153 [FDH] Coron, J., "On the Exact Security of Full Domain Hashing", 2154 Lecture Notes in Computer Science Volume 1880, pp. 2155 229-235, 2000. 2157 [FOPS] Fujisaki, E., Okamoto, T., Pointcheval, D., and J. Stern, 2158 "RSA-OAEP is Secure under the RSA Assumption", Lecture 2159 Notes in Computer Science Volume 2139, pp. 260-274, 2001. 2161 [FORGERY] Coppersmith, D., Halevi, S., and C. Jutla, "ISO 9796-1 and 2162 the New Forgery Strategy", August 1999. 2164 [GRELL] Grell, M., "Re: Encoding Methods PSS/PSS-R", June 1999, 2165 . 2168 [HAASTAD] Haastad, J., "Solving Simultaneous Modular Equations of 2169 Low Degree", SIAM Journal of Computing Volume 17, pp. 2170 336-341, 1998. 2172 [HANDBOOK] 2173 Menezes, A., van Oorschot, P., and S. Vanstone, "Handbook 2174 of Applied Cryptography", 1996. 2176 [HASHID] Kaliski, B., "On Hash Function Identification in Signature 2177 Schemes", Lecture Notes in Computer Science Volume 2271, 2178 pp. 1-16, 2002. 2180 [IEEE1363] 2181 IEEE, "IEEE Std 1363-2000: Standard Specifications for 2182 Public Key Cryptography", August 2000. 2184 [IEEE1363A] 2185 IEEE, "IEEE Std P1363a-2004: Standard Specifications for 2186 Public Key Cryptography: Additional Techniques", September 2187 2004. 2189 [ISO18033] 2190 ISO/IEC, "ISO/IEC 18033-2:2006: Information Technology - 2191 Security Techniques - Encryption Algorithms - Part 2: 2192 Asymmetric Ciphers", 2006. 2194 [ISO9594] ISO/IEC, "ISO/IEC 9594-8:2008: Information technology - 2195 Open Systems Interconnection - The Directory: 2196 Authentication Framework", 2008. 2198 [ISO9796] ISO/IEC, "ISO/IEC 9796-2:2010: Information technology - 2199 Security Techniques - Digital Signature Schemes Giving 2200 Message Recovery - Part 2: Integer Factorization Based 2201 Mechanisms", 2010. 2203 [JONSSON] Jonsson, J., "Security Proofs for the RSA-PSS Signature 2204 Scheme and Its Variants", March 2002, 2205 . 2207 [LOWEXP] Coppersmith, D., Franklin, M., Patarin, J., and M. Reiter, 2208 "Low-Exponent RSA with Related Messages", Lecture Notes in 2209 Computer Science Volume 1070, pp. 1-9, 1996. 2211 [MANGER] Manger, J., "A Chosen Ciphertext Attack on RSA Optimal 2212 Asymmetric Encryption Padding (OAEP) as Standardized in 2213 PKCS #1 v2.0", Lecture Notes in Computer Science Volume 2214 2139, pp. 260-274, 2001. 2216 [MD4] Dobbertin, H., "Cryptanalysis of MD4", Lecture Notes in 2217 Computer Science Volume 1039, pp. 55-72, 1996. 2219 [MD4FIRST] 2220 Dobbertin, H., "The First Two Rounds of MD4 are Not One- 2221 Way", Lecture Notes in Computer Science Volume 1372, pp. 2222 284-292, 1998. 2224 [MD4LAST] den Boer, B. and A. Bosselaers, "An Attack on the Last Two 2225 Rounds of MD4", Lecture Notes in Computer Science Volume 2226 576, pp. 194-203, 1992. 2228 [NEWATTACK] 2229 Coron, J., Joye, M., Naccache, D., and P. Paillier, "New 2230 Attacks on PKCS #1 v1.5 Encryption", Lecture Notes in 2231 Computer Science Volume 1807, pp. 369-379, 2000. 2233 [OAEP] Bellare, M. and P. Rogaway, "Optimal Asymmetric Encryption 2234 - How to Encrypt with RSA", Lecture Notes in Computer 2235 Science Volume 950, pp. 92-111, 1996. 2237 [PA98] Bellare, M., Desai, A., Pointcheval, D., and P. Rogaway, 2238 "Relations Among Notions of Security for Public-Key 2239 Encryption Schemes", Lecture Notes in Computer 2240 Science Volume 1462, pp. 26-45, 1998. 2242 [PADDING] Coron, J., Naccache, D., and J. Stern, "On the Security of 2243 RSA Padding", Lecture Notes in Computer Science Volume 2244 1666, pp. 1-18, 1999. 2246 [PKCS1_21] 2247 RSA Laboratories, "PKCS #1v2.1: RSA Encryption Standard", 2248 June 2002. 2250 [PREFIX] Stevens, M., Lenstra, A., and B. de Weger, "Chosen-prefix 2251 collisions for MD5 and applications", International 2252 Journal of Applied Cryptography Vol. 2, No. 4, pp. 2253 322-359, July 2012. 2255 [PSS] Bellare, M. and P. Rogaway, "PSS: Provably Secure Encoding 2256 Method for Digital Signatures", August 1998, 2257 . 2259 [PSSPROOF] 2260 Coron, J., "Optimal Security Proofs for PSS and Other 2261 Signature Schemes", Lecture Notes in Computer 2262 Science Volume 2332, pp. 272-287, 2002. 2264 [RFC1319] Kaliski, B., "The MD2 Message-Digest Algorithm", RFC 1319, 2265 DOI 10.17487/RFC1319, April 1992, 2266 . 2268 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 2269 DOI 10.17487/RFC1321, April 1992, 2270 . 2272 [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax 2273 Version 1.5", RFC 2315, DOI 10.17487/RFC2315, March 1998, 2274 . 2276 [RFC2437] Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography 2277 Specifications Version 2.0", RFC 2437, 2278 DOI 10.17487/RFC2437, October 1998, 2279 . 2281 [RFC5208] Kaliski, B., "Public-Key Cryptography Standards (PKCS) #8: 2282 Private-Key Information Syntax Specification Version 1.2", 2283 RFC 5208, DOI 10.17487/RFC5208, May 2008, 2284 . 2286 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2287 (TLS) Protocol Version 1.2", RFC 5246, 2288 DOI 10.17487/RFC5246, August 2008, 2289 . 2291 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 2292 RFC 5652, DOI 10.17487/RFC5652, September 2009, 2293 . 2295 [RFC7292] Moriarty, K., Ed., Nystrom, M., Parkinson, S., Rusch, A., 2296 and M. Scott, "PKCS #12: Personal Information Exchange 2297 Syntax v1.1", RFC 7292, DOI 10.17487/RFC7292, July 2014, 2298 . 2300 [RSARABIN] 2301 Bellare, M. and P. Rogaway, "The Exact Security of Digital 2302 Signatures - How to Sign with RSA and Rabin", Lecture 2303 Notes in Computer Science Volume 1070, pp. 399-416, 1996. 2305 [RSATLS] Jonsson, J. and B. Kaliski, "On the Security of RSA 2306 Encryption in TLS", Lecture Notes in Computer 2307 Science Volume 2442, pp. 127-142, 2002. 2309 [SHA1CRYPT] 2310 Wang, X., Yao, A., and F. Yao, "Cryptanalysis on SHA-1", 2311 Lecture Notes in Computer Science Volume 2442, pp. 2312 127-142, February 2005, 2313 . 2316 [SHOUP] Shoup, V., "OAEP Reconsidered", Lecture Notes in Computer 2317 Science Volume 2139, pp. 239-259, 2001. 2319 [SHS] National Institute of Standards and Technology (NIST), 2320 "FIPS Publication 180-4: Secure hash Standard", March 2321 2012. 2323 [SILVERMAN] 2324 Silverman, R., "A Cost-Based Security Analysis of 2325 Symmetric and Asymmetric Key Lengths", RSA Laboratories 2326 Bulletin No. 13, 2000. 2328 [SIMMONS] Simmons, G., "Subliminal Communication is Easy Using the 2329 DSA", Lecture Notes in Computer Science Volume 765, pp. 2330 218-232, 1993. 2332 Appendix A. ASN.1 syntax 2334 A.1. RSA key representation 2336 This section defines ASN.1 object identifiers for RSA public and 2337 private keys, and defines the types RSAPublicKey and RSAPrivateKey. 2338 The intended application of these definitions includes X.509 2339 certificates, PKCS #8 [RFC5208], and PKCS #12 [RFC7292]. 2341 The object identifier rsaEncryption identifies RSA public and private 2342 keys as defined in Appendices A.1.1 and A.1.2. The parameters field 2343 associated with this OID in a value of type AlgorithmIdentifier SHALL 2344 have a value of type NULL. 2346 rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1 } 2348 The definitions in this section have been extended to support multi- 2349 prime RSA, but are backward compatible with previous versions. 2351 A.1.1. RSA public key syntax 2353 An RSA public key should be represented with the ASN.1 type 2354 RSAPublicKey: 2356 RSAPublicKey ::= SEQUENCE { 2357 modulus INTEGER, -- n 2358 publicExponent INTEGER -- e 2359 } 2361 The fields of type RSAPublicKey have the following meanings: 2363 o modulus is the RSA modulus n. 2365 o publicExponent is the RSA public exponent e. 2367 A.1.2. RSA private key syntax 2369 An RSA private key should be represented with the ASN.1 type 2370 RSAPrivateKey: 2372 RSAPrivateKey ::= SEQUENCE { 2373 version Version, 2374 modulus INTEGER, -- n 2375 publicExponent INTEGER, -- e 2376 privateExponent INTEGER, -- d 2377 prime1 INTEGER, -- p 2378 prime2 INTEGER, -- q 2379 exponent1 INTEGER, -- d mod (p-1) 2380 exponent2 INTEGER, -- d mod (q-1) 2381 coefficient INTEGER, -- (inverse of q) mod p 2382 otherPrimeInfos OtherPrimeInfos OPTIONAL 2383 } 2385 The fields of type RSAPrivateKey have the following meanings: 2387 o version is the version number, for compatibility with future 2388 revisions of this document. It SHALL be 0 for this version of the 2389 document, unless multi-prime is used, in which case it SHALL be 1. 2391 Version ::= INTEGER { two-prime(0), multi(1) } 2392 (CONSTRAINED BY 2393 {-- version must be multi if otherPrimeInfos present --}) 2395 o modulus is the RSA modulus n. 2397 o publicExponent is the RSA public exponent e. 2399 o privateExponent is the RSA private exponent d. 2401 o prime1 is the prime factor p of n. 2403 o prime2 is the prime factor q of n. 2405 o exponent1 is d mod (p - 1). 2407 o exponent2 is d mod (q - 1). 2409 o coefficient is the CRT coefficient q^(-1) mod p. 2411 o otherPrimeInfos contains the information for the additional primes 2412 r_3, ..., r_u, in order. It SHALL be omitted if version is 0 and 2413 SHALL contain at least one instance of OtherPrimeInfo if version 2414 is 1. 2416 OtherPrimeInfos ::= SEQUENCE SIZE(1..MAX) OF OtherPrimeInfo 2418 OtherPrimeInfo ::= SEQUENCE { 2419 prime INTEGER, -- ri 2420 exponent INTEGER, -- di 2421 coefficient INTEGER -- ti 2422 } 2424 The fields of type OtherPrimeInfo have the following meanings: 2426 o prime is a prime factor r_i of n, where i >= 3. 2428 o exponent is d_i = d mod (r_i - 1). 2430 o coefficient is the CRT coefficient t_i = (r_1 * r_2 * ... * 2431 r_(i-1))^(-1) mod r_i. 2433 Note. It is important to protect the RSA private key against both 2434 disclosure and modification. Techniques for such protection are 2435 outside the scope of this document. Methods for storing and 2436 distributing private keys and other cryptographic data are described 2437 in PKCS #12 and #15. 2439 A.2. Scheme identification 2441 This section defines object identifiers for the encryption and 2442 signature schemes. The schemes compatible with PKCS #1 v1.5 have the 2443 same definitions as in PKCS #1 v1.5. The intended application of 2444 these definitions includes X.509 certificates and PKCS #7. 2446 Here are type identifier definitions for the PKCS #1 OIDs: 2448 PKCS1Algorithms ALGORITHM-IDENTIFIER ::= { 2449 { OID rsaEncryption PARAMETERS NULL } | 2450 { OID md2WithRSAEncryption PARAMETERS NULL } | 2451 { OID md5WithRSAEncryption PARAMETERS NULL } | 2452 { OID sha1WithRSAEncryption PARAMETERS NULL } | 2453 { OID sha224WithRSAEncryption PARAMETERS NULL } | 2454 { OID sha256WithRSAEncryption PARAMETERS NULL } | 2455 { OID sha384WithRSAEncryption PARAMETERS NULL } | 2456 { OID sha512WithRSAEncryption PARAMETERS NULL } | 2457 { OID sha512-224WithRSAEncryption PARAMETERS NULL } | 2458 { OID sha512-256WithRSAEncryption PARAMETERS NULL } | 2459 { OID id-RSAES-OAEP PARAMETERS RSAES-OAEP-params } | 2460 PKCS1PSourceAlgorithms | 2461 { OID id-RSASSA-PSS PARAMETERS RSASSA-PSS-params }, 2462 ... -- Allows for future expansion -- 2463 } 2465 A.2.1. RSAES-OAEP 2467 The object identifier id-RSAES-OAEP identifies the RSAES-OAEP 2468 encryption scheme. 2470 id-RSAES-OAEP OBJECT IDENTIFIER ::= { pkcs-1 7 } 2472 The parameters field associated with this OID in a value of type 2473 AlgorithmIdentifier SHALL have a value of type RSAES-OAEP-params: 2475 RSAES-OAEP-params ::= SEQUENCE { 2476 hashAlgorithm [0] HashAlgorithm DEFAULT sha1, 2477 maskGenAlgorithm [1] MaskGenAlgorithm DEFAULT mgf1SHA1, 2478 pSourceAlgorithm [2] PSourceAlgorithm DEFAULT pSpecifiedEmpty 2479 } 2481 The fields of type RSAES-OAEP-params have the following meanings: 2483 o hashAlgorithm identifies the hash function. It SHALL be an 2484 algorithm ID with an OID in the set OAEP-PSSDigestAlgorithms. For 2485 a discussion of supported hash functions, see Appendix B.1. 2487 HashAlgorithm ::= AlgorithmIdentifier { 2488 {OAEP-PSSDigestAlgorithms} 2489 } 2491 OAEP-PSSDigestAlgorithms ALGORITHM-IDENTIFIER ::= { 2492 { OID id-sha1 PARAMETERS NULL }| 2493 { OID id-sha224 PARAMETERS NULL }| 2494 { OID id-sha256 PARAMETERS NULL }| 2495 { OID id-sha384 PARAMETERS NULL }| 2496 { OID id-sha512 PARAMETERS NULL }| 2497 { OID id-sha512-224 PARAMETERS NULL }| 2498 { OID id-sha512-256 PARAMETERS NULL }, 2499 ... -- Allows for future expansion -- 2500 } 2502 The default hash function is SHA-1: 2504 sha1 HashAlgorithm ::= { 2505 algorithm id-sha1, 2506 parameters SHA1Parameters : NULL 2507 } 2509 SHA1Parameters ::= NULL 2511 o maskGenAlgorithm identifies the mask generation function. It 2512 SHALL be an algorithm ID with an OID in the set 2513 PKCS1MGFAlgorithms, which for this version SHALL consist of id- 2514 mgf1, identifying the MGF1 mask generation function (see 2515 Appendix B.2.1). The parameters field associated with id-mgf1 2516 SHALL be an algorithm ID with an OID in the set OAEP- 2517 PSSDigestAlgorithms, identifying the hash function on which MGF1 2518 is based. 2520 MaskGenAlgorithm ::= AlgorithmIdentifier { {PKCS1MGFAlgorithms} } 2522 PKCS1MGFAlgorithms ALGORITHM-IDENTIFIER ::= { 2523 { OID id-mgf1 PARAMETERS HashAlgorithm }, 2524 ... -- Allows for future expansion -- 2525 } 2527 o The default mask generation function is MGF1 with SHA-1: 2529 mgf1SHA1 MaskGenAlgorithm ::= { 2530 algorithm id-mgf1, 2531 parameters HashAlgorithm : sha1 2532 } 2534 o pSourceAlgorithm identifies the source (and possibly the value) of 2535 the label L. It SHALL be an algorithm ID with an OID in the set 2536 PKCS1PSourceAlgorithms, which for this version SHALL consist of 2537 id-pSpecified, indicating that the label is specified explicitly. 2538 The parameters field associated with id-pSpecified SHALL have a 2539 value of type OCTET STRING, containing the label. In previous 2540 versions of this specification, the term "encoding parameters" was 2541 used rather than "label", hence the name of the type below. 2543 PSourceAlgorithm ::= AlgorithmIdentifier { 2544 {PKCS1PSourceAlgorithms} 2545 } 2547 PKCS1PSourceAlgorithms ALGORITHM-IDENTIFIER ::= { 2548 { OID id-pSpecified PARAMETERS EncodingParameters }, 2549 ... -- Allows for future expansion -- 2550 } 2552 id-pSpecified OBJECT IDENTIFIER ::= { pkcs-1 9 } 2554 EncodingParameters ::= OCTET STRING(SIZE(0..MAX)) 2556 o The default label is an empty string (so that lHash will contain 2557 the hash of the empty string): 2559 pSpecifiedEmpty PSourceAlgorithm ::= { 2560 algorithm id-pSpecified, 2561 parameters EncodingParameters : emptyString 2562 } 2564 emptyString EncodingParameters ::= ''H 2566 If all of the default values of the fields in RSAES-OAEP-params are 2567 used, then the algorithm identifier will have the following value: 2569 rSAES-OAEP-Default-Identifier RSAES-AlgorithmIdentifier ::= { 2570 algorithm id-RSAES-OAEP, 2571 parameters RSAES-OAEP-params : { 2572 hashAlgorithm sha1, 2573 maskGenAlgorithm mgf1SHA1, 2574 pSourceAlgorithm pSpecifiedEmpty 2575 } 2576 } 2578 RSAES-AlgorithmIdentifier ::= AlgorithmIdentifier { 2579 {PKCS1Algorithms} 2580 } 2582 A.2.2. RSAES-PKCS-v1_5 2584 The object identifier rsaEncryption (see Appendix A.1) identifies the 2585 RSAES-PKCS1-v1_5 encryption scheme. The parameters field associated 2586 with this OID in a value of type AlgorithmIdentifier SHALL have a 2587 value of type NULL. This is the same as in PKCS #1 v1.5. 2589 rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1 } 2591 A.2.3. RSASSA-PSS 2593 The object identifier id-RSASSA-PSS identifies the RSASSA-PSS 2594 encryption scheme. 2596 id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 } 2598 The parameters field associated with this OID in a value of type 2599 AlgorithmIdentifier SHALL have a value of type RSASSA-PSS-params: 2601 RSASSA-PSS-params ::= SEQUENCE { 2602 hashAlgorithm [0] HashAlgorithm DEFAULT sha1, 2603 maskGenAlgorithm [1] MaskGenAlgorithm DEFAULT mgf1SHA1, 2604 saltLength [2] INTEGER DEFAULT 20, 2605 trailerField [3] TrailerField DEFAULT trailerFieldBC 2606 } 2608 The fields of type RSASSA-PSS-params have the following meanings: 2610 o hashAlgorithm identifies the hash function. It SHALL be an 2611 algorithm ID with an OID in the set OAEP-PSSDigestAlgorithms (see 2612 Appendix A.2.1). The default hash function is SHA-1. 2614 o maskGenAlgorithm identifies the mask generation function. It 2615 SHALL be an algorithm ID with an OID in the set PKCS1MGFAlgorithms 2616 (see Appendix A.2.1). The default mask generation function is 2617 MGF1 with SHA-1. For MGF1 (and more generally, for other mask 2618 generation functions based on a hash function), it is RECOMMENDED 2619 that the underlying hash function be the same as the one 2620 identified by hashAlgorithm; see Note 2 in Section 9.1 for further 2621 comments. 2623 o saltLength is the octet length of the salt. It SHALL be an 2624 integer. For a given hashAlgorithm, the default value of 2625 saltLength is the octet length of the hash value. Unlike the 2626 other fields of type RSASSA-PSS-params, saltLength does not need 2627 to be fixed for a given RSA key pair. 2629 o trailerField is the trailer field number, for compatibility with 2630 the draft IEEE 1363a-2004 [IEEE1363A]. It SHALLL be 1 for this 2631 version of the document, which represents the trailer field with 2632 hexadecimal value 0xbc. Other trailer fields (including the 2633 trailer field HashID || 0xcc in IEEE 1363a-2004) are not supported 2634 in this document. 2636 TrailerField ::= INTEGER { trailerFieldBC(1) } 2638 If the default values of the hashAlgorithm, maskGenAlgorithm, and 2639 trailerField fields of RSASSA-PSS-params are used, then the algorithm 2640 identifier will have the following value: 2642 rSASSA-PSS-Default-Identifier RSASSA-AlgorithmIdentifier ::= { 2643 algorithm id-RSASSA-PSS, 2644 parameters RSASSA-PSS-params : { 2645 hashAlgorithm sha1, 2646 maskGenAlgorithm mgf1SHA1, 2647 saltLength 20, 2648 trailerField trailerFieldBC 2649 } 2650 } 2652 RSASSA-AlgorithmIdentifier ::= AlgorithmIdentifier { 2653 {PKCS1Algorithms} 2654 } 2656 Note. In some applications, the hash function underlying a signature 2657 scheme is identified separately from the rest of the operations in 2658 the signature scheme. For instance, in PKCS #7 [RFC2315], a hash 2659 function identifier is placed before the message and a "digest 2660 encryption" algorithm identifier (indicating the rest of the 2661 operations) is carried with the signature. In order for PKCS #7 to 2662 support the RSASSA-PSS signature scheme, an object identifier would 2663 need to be defined for the operations in RSASSA-PSS after the hash 2664 function (analogous to the RSAEncryption OID for the RSASSA- 2665 PKCS1-v1_5 scheme). S/MIME CMS [RFC5652] takes a different approach. 2666 Although a hash function identifier is placed before the message, an 2667 algorithm identifier for the full signature scheme may be carried 2668 with a CMS signature (this is done for DSA signatures). Following 2669 this convention, the id-RSASSA-PSS OID can be used to identify 2670 RSASSA-PSS signatures in CMS. Since CMS is considered the successor 2671 to PKCS #7 and new developments such as the addition of support for 2672 RSASSA-PSS will be pursued with respect to CMS rather than PKCS #7, 2673 an OID for the "rest of" RSASSA-PSS is not defined in this version of 2674 PKCS #1. 2676 A.2.4. RSASSA-PKCS-v1_5 2678 The object identifier for RSASSA-PKCS1-v1_5 SHALL be one of the 2679 following. The choice of OID depends on the choice of hash 2680 algorithm: MD2, MD5, SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA- 2681 512/224, or SHA-512/256. Note that if either MD2 or MD5 is used, 2682 then the OID is just as in PKCS #1 v1.5. For each OID, the 2683 parameters field associated with this OID in a value of type 2684 AlgorithmIdentifier SHALL have a value of type NULL. The OID should 2685 be chosen in accordance with the following table: 2687 Hash algorithm OID 2688 ------------------------------------------------------------ 2689 MD2 md2WithRSAEncryption ::= {pkcs-1 2} 2690 MD5 md5WithRSAEncryption ::= {pkcs-1 4} 2691 SHA-1 sha1WithRSAEncryption ::= {pkcs-1 5} 2692 SHA-256 sha224WithRSAEncryption ::= {pkcs-1 14} 2693 SHA-256 sha256WithRSAEncryption ::= {pkcs-1 11} 2694 SHA-384 sha384WithRSAEncryption ::= {pkcs-1 12} 2695 SHA-512 sha512WithRSAEncryption ::= {pkcs-1 13} 2696 SHA-512/224 sha512-224WithRSAEncryption ::= {pkcs-1 15} 2697 SHA-512/256 sha512-256WithRSAEncryption ::= {pkcs-1 16} 2699 The EMSA-PKCS1-v1_5 encoding method includes an ASN.1 value of type 2700 DigestInfo, where the type DigestInfo has the syntax 2701 DigestInfo ::= SEQUENCE { 2702 digestAlgorithm DigestAlgorithm, 2703 digest OCTET STRING 2704 } 2706 digestAlgorithm identifies the hash function and SHALL be an 2707 algorithm ID with an OID in the set PKCS1-v1-5DigestAlgorithms. For 2708 a discussion of supported hash functions, see Appendix B.1. 2710 DigestAlgorithm ::= AlgorithmIdentifier { 2711 {PKCS1-v1-5DigestAlgorithms} 2712 } 2714 PKCS1-v1-5DigestAlgorithms ALGORITHM-IDENTIFIER ::= { 2715 { OID id-md2 PARAMETERS NULL }| 2716 { OID id-md5 PARAMETERS NULL }| 2717 { OID id-sha1 PARAMETERS NULL }| 2718 { OID id-sha224 PARAMETERS NULL }| 2719 { OID id-sha256 PARAMETERS NULL }| 2720 { OID id-sha384 PARAMETERS NULL }| 2721 { OID id-sha512 PARAMETERS NULL }| 2722 { OID id-sha512-224 PARAMETERS NULL }| 2723 { OID id-sha512-256 PARAMETERS NULL } 2724 } 2726 Appendix B. Supporting techniques 2728 This section gives several examples of underlying functions 2729 supporting the encryption schemes in Section 7 and the encoding 2730 methods in Section 9. A range of techniques is given here to allow 2731 compatibility with existing applications as well as migration to new 2732 techniques. While these supporting techniques are appropriate for 2733 applications to implement, none of them is required to be 2734 implemented. It is expected that profiles for PKCS #1 v2.2 will be 2735 developed that specify particular supporting techniques. 2737 This section also gives object identifiers for the supporting 2738 techniques. 2740 B.1. Hash functions 2742 Hash functions are used in the operations contained in Sections 7 and 2743 9. Hash functions are deterministic, meaning that the output is 2744 completely determined by the input. Hash functions take octet 2745 strings of variable length, and generate fixed length octet strings. 2746 The hash functions used in the operations contained in Sections 7 and 2747 9 should generally be collision-resistant. This means that it is 2748 infeasible to find two distinct inputs to the hash function that 2749 produce the same output. A collision-resistant hash function also 2750 has the desirable property of being one-way; this means that given an 2751 output, it is infeasible to find an input whose hash is the specified 2752 output. In addition to the requirements, the hash function should 2753 yield a mask generation function (Appendix B.2) with pseudorandom 2754 output. 2756 Nine hash functions are given as examples for the encoding methods in 2757 this document: MD2 [RFC1319], MD5 [RFC1321], SHA-1, SHA-224, SHA-256, 2758 SHA-384, SHA-512, SHA-512/224, and SHA-512/256 [SHS]. For the RSAES- 2759 OAEP encryption scheme and EMSA-PSS encoding method, only SHA-1, SHA- 2760 224, SHA-256, SHA-384, SHA-512, SHA-512/224, and SHA-512/256 are 2761 RECOMMENDED. For the EMSA-PKCS1-v1_5 encoding method, SHA-224, SHA- 2762 256, SHA-384, SHA-512, SHA-512/224, and SHA-512/256 are RECOMMENDED 2763 for new applications. MD2, MD5 and SHA-1 are recommended only for 2764 compatibility with existing applications based on PKCS #1 v1.5. 2766 The object identifiers id-md2, id-md5, id-sha1, id-sha224, id-sha256, 2767 id-sha384, id-sha512, id-sha512/224, and id-sha512/256, identify the 2768 respective hash functions: 2770 id-md2 OBJECT IDENTIFIER ::= { 2771 iso (1) member-body (2) us (840) rsadsi (113549) 2772 digestAlgorithm (2) 2 2773 } 2775 id-md5 OBJECT IDENTIFIER ::= { 2776 iso (1) member-body (2) us (840) rsadsi (113549) 2777 digestAlgorithm (2) 5 2778 } 2780 id-sha1 OBJECT IDENTIFIER ::= { 2781 iso(1) identified-organization(3) oiw(14) secsig(3) 2782 algorithms(2) 26 2783 } 2785 id-sha224 OBJECT IDENTIFIER ::= { 2786 joint-iso-itu-t (2) country (16) us (840) organization (1) 2787 gov (101) csor (3) nistalgorithm (4) hashalgs (2) 4 2788 } 2790 id-sha256 OBJECT IDENTIFIER ::= { 2791 joint-iso-itu-t (2) country (16) us (840) organization (1) 2792 gov (101) csor (3) nistalgorithm (4) hashalgs (2) 1 2793 } 2795 id-sha384 OBJECT IDENTIFIER ::= { 2796 joint-iso-itu-t (2) country (16) us (840) organization (1) 2797 gov (101) csor (3) nistalgorithm (4) hashalgs (2) 2 2798 } 2800 id-sha512 OBJECT IDENTIFIER ::= { 2801 joint-iso-itu-t (2) country (16) us (840) organization (1) 2802 gov (101) csor (3) nistalgorithm (4) hashalgs (2) 3 2803 } 2805 id-sha512-224 OBJECT IDENTIFIER ::= { 2806 joint-iso-itu-t (2) country (16) us (840) organization (1) 2807 gov (101) csor (3) nistalgorithm (4) hashalgs (2) 5 2808 } 2810 id-sha512-256 OBJECT IDENTIFIER ::= { 2811 joint-iso-itu-t (2) country (16) us (840) organization (1) 2812 gov (101) csor (3) nistalgorithm (4) hashalgs (2) 6 2813 } 2815 The parameters field associated with these OIDs in a value of type 2816 AlgorithmIdentifier SHALL have a value of type NULL. 2818 The parameters field associated with id-md2 and id-md5 in a value of 2819 type AlgorithmIdentifier shall have a value of type NULL. 2821 The parameters field associated with id-sha1, id-sha224, id-sha256, 2822 id-sha384, id-sha512, id-sha512/224, and id-sha512/256 should 2823 generally be omitted, but if present, shall have a value of type 2824 NULL. 2826 This is to align with the definitions originally promulgated by NIST. 2827 For the SHA algorithms, implementations MUST accept 2828 AlgorithmIdentifier values both without parameters and with NULL 2829 parameters. 2831 Exception: When formatting the DigestInfoValue in EMSA-PKCS1-v1_5 2832 (see 9.2), the parameters field associated with id-sha1, id-sha224, 2833 id-sha256, id-sha384, id-sha512, id-sha512/224, and id-sha512/256 2834 shall have a value of type NULL. This is to maintain compatibility 2835 with existing implementations and with the numeric information values 2836 already published for EMSA-PKCS1-v1_5 which are also reflected in 2837 IEEE 1363a-2004 [IEEE1363A]. 2839 Note. Version 1.5 of PKCS #1 also allowed for the use of MD4 in 2840 signature schemes. The cryptanalysis of MD4 has progressed 2841 significantly in the intervening years. For example, Dobbertin [MD4] 2842 demonstrated how to find collisions for MD4 and that the first two 2843 rounds of MD4 are not one-way [MD4FIRST]. Because of these results 2844 and others (e.g. [MD4LAST]), MD4 is NOT RECOMMENDED. 2846 Further advances have been made in the cryptanalysis of MD2 and MD5, 2847 and especially after Stevens et al. findings [PREFIX] on chosen- 2848 prefix collisions on MD5. MD2 and MD5 should be considered 2849 cryptographically broken and removed from existing applications. 2850 This version of the standard supports MD2 and MD5 just for backwards 2851 compatibility reasons. 2853 There have also been advances in the cryptanalysis of SHA-1. 2854 Particularly the results of Wang et al. [SHA1CRYPT] (which have been 2855 independently verified by M. Cochran in his analysis [COCHRAN]) on 2856 using a differential path to find collisions in SHA-1, which conclude 2857 that the security strength of the SHA-1 hashing algorithm is 2858 significantly reduced. However, this reduction is not significant 2859 enough to warrant the removal of SHA-1 from existing applications, 2860 but its usage is only recommended for backwards compatibility 2861 reasons. 2863 To address these concerns, only SHA-224, SHA-256, SHA-384, SHA-512, 2864 SHA-512/224, and SHA-512/256 are RECOMMENDED for new applications. 2865 As of today, the best (known) collision attacks against these hash 2866 functions are generic attacks with complexity 2L/2, where L is the 2867 bit length of the hash output. For the signature schemes in this 2868 document, a collision attack is easily translated into a signature 2869 forgery. Therefore, the value L / 2 should be at least equal to the 2870 desired security level in bits of the signature scheme (a security 2871 level of B bits means that the best attack has complexity 2B). The 2872 same rule of thumb can be applied to RSAES-OAEP; it is RECOMMENDED 2873 that the bit length of the seed (which is equal to the bit length of 2874 the hash output) be twice the desired security level in bits. 2876 B.2. Mask generation functions 2878 A mask generation function takes an octet string of variable length 2879 and a desired output length as input, and outputs an octet string of 2880 the desired length. There may be restrictions on the length of the 2881 input and output octet strings, but such bounds are generally very 2882 large. Mask generation functions are deterministic; the octet string 2883 output is completely determined by the input octet string. The 2884 output of a mask generation function should be pseudorandom: Given 2885 one part of the output but not the input, it should be infeasible to 2886 predict another part of the output. The provable security of RSAES- 2887 OAEP and RSASSA-PSS relies on the random nature of the output of the 2888 mask generation function, which in turn relies on the random nature 2889 of the underlying hash. 2891 One mask generation function is given here: MGF1, which is based on a 2892 hash function. MGF1 coincides with the mask generation functions 2893 defined in IEEE 1363-2000 [IEEE1363] and ANSI X9.44-2007 [ANSIX944]. 2894 Future versions of this document may define other mask generation 2895 functions. 2897 B.2.1. MGF1 2899 MGF1 is a Mask Generation Function based on a hash function. 2901 MGF1 (mgfSeed, maskLen) 2903 Options: 2905 Hash hash function (hLen denotes the length in octets of the hash 2906 function output) 2908 Input: 2910 mgfSeed seed from which mask is generated, an octet string 2911 maskLen intended length in octets of the mask, at most 2^32 hLen 2913 Output: 2915 mask mask, an octet string of length maskLen 2917 Error: 2919 "mask too long" 2921 Steps: 2923 1. If maskLen > 2^32 hLen, output "mask too long" and stop. 2925 2. Let T be the empty octet string. 2927 3. For counter from 0 to \ceil (maskLen / hLen) - 1, do the 2928 following: 2930 A. Convert counter to an octet string C of length 4 octets (see 2931 Section 4.1): 2933 C = I2OSP (counter, 4) . 2935 B. Concatenate the hash of the seed mgfSeed and C to the octet 2936 string T: 2938 T = T || Hash(mgfSeed || C) . 2940 4. Output the leading maskLen octets of T as the octet string mask. 2942 The object identifier id-mgf1 identifies the MGF1 mask generation 2943 function: 2945 id-mgf1 OBJECT IDENTIFIER ::= { pkcs-1 8 } 2947 The parameters field associated with this OID in a value of type 2948 AlgorithmIdentifier shall have a value of type hashAlgorithm, 2949 identifying the hash function on which MGF1 is based. 2951 Appendix C. ASN.1 module 2953 -- PKCS #1 v2.2 ASN.1 Module 2954 -- Revised October 27, 2012 2956 -- This module has been checked for conformance with the 2957 -- ASN.1 standard by the OSS ASN.1 Tools 2959 PKCS-1 { 2960 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 2961 modules(0) pkcs-1(1) 2962 } 2963 DEFINITIONS EXPLICIT TAGS ::= 2965 BEGIN 2967 -- EXPORTS ALL 2968 -- All types and values defined in this module are exported for use 2969 -- in other ASN.1 modules. 2971 IMPORTS 2973 id-sha224, id-sha256, id-sha384, id-sha512, id-sha512-224, 2974 id-sha512-256 2975 FROM NIST-SHA2 { 2976 joint-iso-itu-t(2) country(16) us(840) organization(1) 2977 gov(101) csor(3) nistalgorithm(4) hashAlgs(2) 2978 }; 2980 -- ============================ 2981 -- Basic object identifiers 2982 -- ============================ 2984 -- The DER encoding of this in hexadecimal is: 2985 -- (0x)06 08 2986 -- 2A 86 48 86 F7 0D 01 01 2987 -- 2988 pkcs-1 OBJECT IDENTIFIER ::= { 2989 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 1 2990 } 2992 -- 2993 -- When rsaEncryption is used in an AlgorithmIdentifier the 2994 -- parameters MUST be present and MUST be NULL. 2995 -- 2996 rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1 } 2998 -- 2999 -- When id-RSAES-OAEP is used in an AlgorithmIdentifier the 3000 -- parameters MUST be present and MUST be RSAES-OAEP-params. 3001 -- 3002 id-RSAES-OAEP OBJECT IDENTIFIER ::= { pkcs-1 7 } 3004 -- 3005 -- When id-pSpecified is used in an AlgorithmIdentifier the 3006 -- parameters MUST be an OCTET STRING. 3007 -- 3008 id-pSpecified OBJECT IDENTIFIER ::= { pkcs-1 9 } 3010 -- 3011 -- When id-RSASSA-PSS is used in an AlgorithmIdentifier the 3012 -- parameters MUST be present and MUST be RSASSA-PSS-params. 3013 -- 3014 id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 } 3016 -- 3017 -- When the following OIDs are used in an AlgorithmIdentifier the 3018 -- parameters MUST be present and MUST be NULL. 3019 -- 3020 md2WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 2 } 3021 md5WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 4 } 3022 sha1WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 5 } 3023 sha224WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 14 } 3024 sha256WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 11 } 3025 sha384WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 12 } 3026 sha512WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 13 } 3027 sha512-224WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 15 } 3028 sha512-256WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 16 } 3030 -- 3031 -- This OID really belongs in a module with the secsig OIDs. 3032 -- 3033 id-sha1 OBJECT IDENTIFIER ::= { 3034 iso(1) identified-organization(3) oiw(14) secsig(3) algorithms(2) 3035 26 3036 } 3038 -- 3039 -- OIDs for MD2 and MD5, allowed only in EMSA-PKCS1-v1_5. 3040 -- 3041 id-md2 OBJECT IDENTIFIER ::= { 3042 iso(1) member-body(2) us(840) rsadsi(113549) digestAlgorithm(2) 2 3043 } 3045 id-md5 OBJECT IDENTIFIER ::= { 3046 iso(1) member-body(2) us(840) rsadsi(113549) digestAlgorithm(2) 5 3047 } 3049 -- 3050 -- When id-mgf1 is used in an AlgorithmIdentifier the parameters MUST 3051 -- be present and MUST be a HashAlgorithm, for example sha1. 3052 -- 3053 id-mgf1 OBJECT IDENTIFIER ::= { pkcs-1 8 } 3055 -- ================ 3056 -- Useful types 3057 -- ================ 3058 ALGORITHM-IDENTIFIER ::= CLASS { 3059 &id OBJECT IDENTIFIER UNIQUE, 3060 &Type OPTIONAL 3061 } 3062 WITH SYNTAX { OID &id [PARAMETERS &Type] } 3064 -- Note: the parameter InfoObjectSet in the following definitions 3065 -- allows a distinct information object set to be specified for sets 3066 -- of algorithms such as: 3067 -- DigestAlgorithms ALGORITHM-IDENTIFIER ::= { 3068 -- { OID id-md2 PARAMETERS NULL }| 3069 -- { OID id-md5 PARAMETERS NULL }| 3070 -- { OID id-sha1 PARAMETERS NULL } 3071 -- } 3072 -- 3074 AlgorithmIdentifier { ALGORITHM-IDENTIFIER:InfoObjectSet } ::= 3075 SEQUENCE { 3076 algorithm 3077 ALGORITHM-IDENTIFIER.&id({InfoObjectSet}), 3078 parameters 3079 ALGORITHM-IDENTIFIER.&Type({InfoObjectSet}{@.algorithm}) 3080 OPTIONAL 3081 } 3083 -- ============== 3084 -- Algorithms 3085 -- ============== 3087 -- 3088 -- Allowed EME-OAEP and EMSA-PSS digest algorithms. 3089 -- 3090 OAEP-PSSDigestAlgorithms ALGORITHM-IDENTIFIER ::= { 3091 { OID id-sha1 PARAMETERS NULL }| 3092 { OID id-sha224 PARAMETERS NULL }| 3093 { OID id-sha256 PARAMETERS NULL }| 3094 { OID id-sha384 PARAMETERS NULL }| 3095 { OID id-sha512 PARAMETERS NULL }| 3096 { OID id-sha512-224 PARAMETERS NULL }| 3097 { OID id-sha512-256 PARAMETERS NULL }, 3098 ... -- Allows for future expansion -- 3099 } 3101 -- 3102 -- Allowed EMSA-PKCS1-v1_5 digest algorithms. 3103 -- 3104 PKCS1-v1-5DigestAlgorithms ALGORITHM-IDENTIFIER ::= { 3105 { OID id-md2 PARAMETERS NULL }| 3106 { OID id-md5 PARAMETERS NULL }| 3107 { OID id-sha1 PARAMETERS NULL }| 3108 { OID id-sha224 PARAMETERS NULL }| 3109 { OID id-sha256 PARAMETERS NULL }| 3110 { OID id-sha384 PARAMETERS NULL }| 3111 { OID id-sha512 PARAMETERS NULL }| 3112 { OID id-sha512-224 PARAMETERS NULL }| 3113 { OID id-sha512-256 PARAMETERS NULL } 3114 } 3116 -- When id-md2 and id-md5 are used in an AlgorithmIdentifier the 3117 -- parameters field shall have a value of type NULL. 3119 -- When id-sha1, id-sha224, id-sha256, id-sha384, id-sha512, 3120 -- id-sha512-224, and id-sha512-256 are used in an 3121 -- AlgorithmIdentifier the parameters (which are optional) SHOULD be 3122 -- omitted, but if present, SHALL have a value of type NULL. However, 3123 -- implementations MUST accept AlgorithmIdentifier values both 3124 -- without parameters and with NULL parameters. 3126 -- Exception: When formatting the DigestInfoValue in EMSA-PKCS1-v1_5 3127 -- (see 9.2), the parameters field associated with id-sha1, 3128 -- id-sha224, id-sha256, id-sha384 , id-sha512 , id-sha512-224, and 3129 -- id-sha512-256 SHALL have a value of type NULL. This is to maintain 3130 -- compatibility with existing implementations and with the numeric 3131 -- information values already published for EMSA-PKCS1-v1_5, which 3132 -- are also reflected in IEEE 1363a-2004. 3134 sha1 HashAlgorithm ::= { 3135 algorithm id-sha1, 3136 parameters SHA1Parameters : NULL 3137 } 3139 HashAlgorithm ::= AlgorithmIdentifier { {OAEP-PSSDigestAlgorithms} } 3141 SHA1Parameters ::= NULL 3143 -- 3144 -- Allowed mask generation function algorithms. 3145 -- If the identifier is id-mgf1, the parameters are a HashAlgorithm. 3146 -- 3147 PKCS1MGFAlgorithms ALGORITHM-IDENTIFIER ::= { 3148 { OID id-mgf1 PARAMETERS HashAlgorithm }, 3149 ... -- Allows for future expansion -- 3150 } 3151 -- 3152 -- Default AlgorithmIdentifier for id-RSAES-OAEP.maskGenAlgorithm and 3153 -- id-RSASSA-PSS.maskGenAlgorithm. 3154 -- 3155 mgf1SHA1 MaskGenAlgorithm ::= { 3156 algorithm id-mgf1, 3157 parameters HashAlgorithm : sha1 3158 } 3160 MaskGenAlgorithm ::= AlgorithmIdentifier { {PKCS1MGFAlgorithms} } 3162 -- 3163 -- Allowed algorithms for pSourceAlgorithm. 3164 -- 3165 PKCS1PSourceAlgorithms ALGORITHM-IDENTIFIER ::= { 3166 { OID id-pSpecified PARAMETERS EncodingParameters }, 3167 ... -- Allows for future expansion -- 3168 } 3170 EncodingParameters ::= OCTET STRING(SIZE(0..MAX)) 3172 -- 3173 -- This identifier means that the label L is an empty string, so the 3174 -- digest of the empty string appears in the RSA block before 3175 -- masking. 3176 -- 3178 pSpecifiedEmpty PSourceAlgorithm ::= { 3179 algorithm id-pSpecified, 3180 parameters EncodingParameters : emptyString 3181 } 3183 PSourceAlgorithm ::= AlgorithmIdentifier { {PKCS1PSourceAlgorithms} } 3185 emptyString EncodingParameters ::= ''H 3187 -- 3188 -- Type identifier definitions for the PKCS #1 OIDs. 3189 -- 3190 PKCS1Algorithms ALGORITHM-IDENTIFIER ::= { 3191 { OID rsaEncryption PARAMETERS NULL } | 3192 { OID md2WithRSAEncryption PARAMETERS NULL } | 3193 { OID md5WithRSAEncryption PARAMETERS NULL } | 3194 { OID sha1WithRSAEncryption PARAMETERS NULL } | 3195 { OID sha224WithRSAEncryption PARAMETERS NULL } | 3196 { OID sha256WithRSAEncryption PARAMETERS NULL } | 3197 { OID sha384WithRSAEncryption PARAMETERS NULL } | 3198 { OID sha512WithRSAEncryption PARAMETERS NULL } | 3199 { OID sha512-224WithRSAEncryption PARAMETERS NULL } | 3200 { OID sha512-256WithRSAEncryption PARAMETERS NULL } | 3201 { OID id-RSAES-OAEP PARAMETERS RSAES-OAEP-params } | 3202 PKCS1PSourceAlgorithms | 3203 { OID id-RSASSA-PSS PARAMETERS RSASSA-PSS-params }, 3204 ... -- Allows for future expansion -- 3205 } 3207 -- =================== 3208 -- Main structures 3209 -- =================== 3211 RSAPublicKey ::= SEQUENCE { 3212 modulus INTEGER, -- n 3213 publicExponent INTEGER -- e 3214 } 3216 -- 3217 -- Representation of RSA private key with information for the CRT 3218 -- algorithm. 3219 -- 3220 RSAPrivateKey ::= SEQUENCE { 3221 version Version, 3222 modulus INTEGER, -- n 3223 publicExponent INTEGER, -- e 3224 privateExponent INTEGER, -- d 3225 prime1 INTEGER, -- p 3226 prime2 INTEGER, -- q 3227 exponent1 INTEGER, -- d mod (p-1) 3228 exponent2 INTEGER, -- d mod (q-1) 3229 coefficient INTEGER, -- (inverse of q) mod p 3230 otherPrimeInfos OtherPrimeInfos OPTIONAL 3231 } 3233 Version ::= INTEGER { two-prime(0), multi(1) } 3234 (CONSTRAINED BY 3235 {-- version MUST 3236 be multi if otherPrimeInfos present --}) 3238 OtherPrimeInfos ::= SEQUENCE SIZE(1..MAX) OF OtherPrimeInfo 3240 OtherPrimeInfo ::= SEQUENCE { 3241 prime INTEGER, -- ri 3242 exponent INTEGER, -- di 3243 coefficient INTEGER -- ti 3244 } 3245 -- 3246 -- AlgorithmIdentifier.parameters for id-RSAES-OAEP. 3247 -- Note that the tags in this Sequence are explicit. 3248 -- 3249 RSAES-OAEP-params ::= SEQUENCE { 3250 hashAlgorithm [0] HashAlgorithm DEFAULT sha1, 3251 maskGenAlgorithm [1] MaskGenAlgorithm DEFAULT mgf1SHA1, 3252 pSourceAlgorithm [2] PSourceAlgorithm DEFAULT pSpecifiedEmpty 3253 } 3255 -- 3256 -- Identifier for default RSAES-OAEP algorithm identifier. 3257 -- The DER Encoding of this is in hexadecimal: 3258 -- (0x)30 0D 3259 -- 06 09 3260 -- 2A 86 48 86 F7 0D 01 01 07 3261 -- 30 00 3262 -- Notice that the DER encoding of default values is "empty". 3263 -- 3265 rSAES-OAEP-Default-Identifier RSAES-AlgorithmIdentifier ::= { 3266 algorithm id-RSAES-OAEP, 3267 parameters RSAES-OAEP-params : { 3268 hashAlgorithm sha1, 3269 maskGenAlgorithm mgf1SHA1, 3270 pSourceAlgorithm pSpecifiedEmpty 3271 } 3272 } 3274 RSAES-AlgorithmIdentifier ::= AlgorithmIdentifier { 3275 {PKCS1Algorithms} 3276 } 3278 -- 3279 -- AlgorithmIdentifier.parameters for id-RSASSA-PSS. 3280 -- Note that the tags in this Sequence are explicit. 3281 -- 3282 RSASSA-PSS-params ::= SEQUENCE { 3283 hashAlgorithm [0] HashAlgorithm DEFAULT sha1, 3284 maskGenAlgorithm [1] MaskGenAlgorithm DEFAULT mgf1SHA1, 3285 saltLength [2] INTEGER DEFAULT 20, 3286 trailerField [3] TrailerField DEFAULT trailerFieldBC 3287 } 3289 TrailerField ::= INTEGER { trailerFieldBC(1) } 3291 -- 3292 -- Identifier for default RSASSA-PSS algorithm identifier 3293 -- The DER Encoding of this is in hexadecimal: 3294 -- (0x)30 0D 3295 -- 06 09 3296 -- 2A 86 48 86 F7 0D 01 01 0A 3297 -- 30 00 3298 -- Notice that the DER encoding of default values is "empty". 3299 -- 3300 rSASSA-PSS-Default-Identifier RSASSA-AlgorithmIdentifier ::= { 3301 algorithm id-RSASSA-PSS, 3302 parameters RSASSA-PSS-params : { 3303 hashAlgorithm sha1, 3304 maskGenAlgorithm mgf1SHA1, 3305 saltLength 20, 3306 trailerField trailerFieldBC 3307 } 3308 } 3310 RSASSA-AlgorithmIdentifier ::= AlgorithmIdentifier { 3311 {PKCS1Algorithms} 3312 } 3314 -- 3315 -- Syntax for the EMSA-PKCS1-v1_5 hash identifier. 3316 -- 3317 DigestInfo ::= SEQUENCE { 3318 digestAlgorithm DigestAlgorithm, 3319 digest OCTET STRING 3320 } 3322 DigestAlgorithm ::= AlgorithmIdentifier { 3323 {PKCS1-v1-5DigestAlgorithms} 3324 } 3326 END 3328 Appendix D. Intellectual property considerations 3330 The RSA public-key cryptosystem is described in U.S. Patent 3331 4,405,829, which expired on September 20, 2000. EMC Corporation 3332 makes no other patent claims on the constructions described in this 3333 document, although specific underlying techniques may be covered. 3334 Multi-prime RSA is described in U.S. Patent 5,848,159. 3336 The PSS signature scheme [PSS] is described in U.S. Patent 3337 6,266,771, which expired on July 24, 2009, and U.S. Patent 3338 7,036,014, which expired on April 25, 2010, and was held by the 3339 University of California. The PSS signature scheme is specified in 3340 IEEE P1363a-2004 [IEEE1363A]. Prior to the finalization of this 3341 standard, the University of California provided a letter to the IEEE 3342 P1363 working group stating that if the PSS signature scheme is 3343 included in an IEEE standard, "the University of California will, 3344 when that standard is adopted, FREELY license any conforming 3345 implementation of PSS as a technique for achieving a digital 3346 signature with appendix" [GRELL]. 3348 EMC Corporation makes no other representations regarding intellectual 3349 property claims by other parties. Such determination is the 3350 responsibility of the user. 3352 Appendix E. Revision history 3354 Versions 1.0 -- 1.3 3356 Versions 1.0 -- 1.3 were distributed to participants in RSA Data 3357 Security, Inc.'s Public-Key Cryptography Standards meetings in 3358 February and March 1991. Version 1.4 3360 Version 1.4 was part of the June 3, 1991 initial public release of 3361 PKCS. Version 1.4 was published as NIST/OSI Implementors' Workshop 3362 document SEC-SIG-91-18. Version 1.5 3364 Version 1.5 incorporated several editorial changes, including updates 3365 to the references and the addition of a revision history. The 3366 following substantive changes were made: 3368 o Section 10: "MD4 with RSA" signature and verification processes 3369 were added. 3371 o Section 11: md4WithRSAEncryption object identifier was added. 3373 Version 1.5 was republished as IETF RFC 2313. 3375 Version 2.0 3377 Version 2.0 incorporated major editorial changes in terms of the 3378 document structure and introduced the RSAES-OAEP encryption scheme. 3379 This version continued to support the encryption and signature 3380 processes in version 1.5, although the hash algorithm MD4 was no 3381 longer allowed due to cryptanalytic advances in the intervening 3382 years. Version 2.0 was republished as RFC 2437 [RFC2437]. 3384 Version 2.1 3386 Version 2.1 introduces multi-prime RSA and the RSASSA-PSS signature 3387 scheme with appendix along with several editorial improvements. This 3388 version continues to support the schemes in version 2.0. 3390 Version 2.2 3392 Version 2.2 updates the list of allowed hashing algorithms to align 3393 them with FIPS 180-4 [SHS], therefore adding SHA-224, SHA-512/224 and 3394 SHA-512/256. The following substantive changes were made: 3396 o Object identifiers for sha224WithRSAEncryption, 3397 sha512-224WithRSAEncryption and sha512-256WithRSAEncryption were 3398 added. 3400 o This version continues to support the schemes in version 2.1. 3402 Appendix F. About PKCS 3404 The Public-Key Cryptography Standards are specifications produced by 3405 RSA Laboratories in cooperation with secure systems developers 3406 worldwide for the purpose of accelerating the deployment of public- 3407 key cryptography. First published in 1991 as a result of meetings 3408 with a small group of early adopters of public-key technology, the 3409 PKCS documents have become widely referenced and implemented. 3410 Contributions from the PKCS series have become part of many formal 3411 and de facto standards, including ANSI X9 and IEEE P1363 documents, 3412 PKIX, SET, S/MIME, SSL/TLS, and WAP/WTLS. 3414 Further development of most PKCS documents occurs through the IETF. 3415 Suggestions for improvement are welcome. 3417 Appendix G. Acknowledgements 3419 This document is based on a contribution of RSA Laboratories, the 3420 research center of RSA Security Inc. 3422 Authors' Addresses 3424 Kathleen M. Moriarty (editor) 3425 EMC Corporation 3426 176 South Street 3427 Hopkinton, MA 01748 3428 US 3430 Email: kathleen.moriarty@emc.com 3431 Burt Kaliski 3432 Verisign 3433 12061 Bluemont Way 3434 Reston, VA 20190 3435 US 3437 Email: bkaliski@verisign.com 3438 URI: http://verisignlabs.com 3440 Jakob Jonsson 3441 Subset AB 3442 Munkbrogtan 4 3443 Stockholm SE-11127 3444 SE 3446 Phone: +46 8 428 687 43 3447 Email: jakob.jonsson@subset.se 3449 Andreas Rusch 3450 RSA 3451 345 Queen Street 3452 Brisbane, QLD 4000 3453 AU 3455 Email: andreas.rusch@rsa.com