rfc2437.txt

<VC++网络游戏建摸与实现>源代码

   c = RSAEP ((n, e), m)

   4. Convert the ciphertext representative c to a ciphertext C of
   length k octets: C = I2OSP (c, k)

   5. Output the ciphertext C.

7.1.2 Decryption operation

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

   Input:
   K          recipient's RSA private key
   C          ciphertext to be decrypted, an octet string of length
              k, where k is the length in octets of the modulus n
   P          encoding parameters, an octet string that may be empty

   Output:
   M          message, an octet string of length at most k-2-2hLen,
              where hLen is the length in octets of the hash
              function output for EME-OAEP; or "decryption error"






Kaliski & Staddon            Informational                     [Page 14]

RFC 2437        PKCS #1: RSA Cryptography Specifications    October 1998


   Steps:

   1. If the length of the ciphertext C is not k octets, output
   "decryption error" and stop.

   2. Convert the ciphertext C to an integer ciphertext representative
   c: c = OS2IP (C).

   3. Apply the RSADP decryption primitive (Section 5.1.2) to the
   private key K and the ciphertext representative c to produce an
   integer message representative m:

   m = RSADP (K, c)

   If RSADP outputs "ciphertext out of range," then output "decryption
   error" and stop.

   4. Convert the message representative m to an encoded message EM of
   length k-1 octets: EM = I2OSP (m, k-1)

   If I2OSP outputs "integer too large," then output "decryption error"
   and stop.

   5. Apply the EME-OAEP decoding operation to the encoded message EM
   and the encoding parameters P to recover a message M:

   M = EME-OAEP-DECODE (EM, P)

   If the decoding operation outputs "decoding error," then output
   "decryption error" and stop.

   6. Output the message M.

   Note. It is important that the error messages output in steps 4 and 5
   be the same, otherwise an adversary may be able to extract useful
   information from the type of error message received. Error message
   information is used to mount a chosen-ciphertext attack on PKCS #1
   v1.5 encrypted messages in [4].

7.2 RSAES-PKCS1-v1_5

   RSAES-PKCS1-v1_5 combines the RSAEP and RSADP primitives with the
   EME-PKCS1-v1_5 encoding method. It is the same as the encryption
   scheme in PKCS #1 v1.5. RSAES-PKCS1-v1_5 can operate on messages of
   length up to k-11 octets, although care should be taken to avoid
   certain attacks on low-exponent RSA due to Coppersmith, et al. when
   long messages are encrypted (see the third bullet in the notes below
   and [7]).



Kaliski & Staddon            Informational                     [Page 15]

RFC 2437        PKCS #1: RSA Cryptography Specifications    October 1998


   RSAES-PKCS1-v1_5 does not provide "plaintext aware" encryption. In
   particular, it is possible to generate valid ciphertexts without
   knowing the corresponding plaintexts, with a reasonable probability
   of success. This ability can be exploited in a chosen ciphertext
   attack as shown in [4]. Therefore, if RSAES-PKCS1-v1_5 is to be used,
   certain easily implemented countermeasures should be taken to thwart
   the attack found in [4]. The addition of structure to the data to be
   encoded, rigorous checking of PKCS #1 v1.5 conformance and other
   redundancy in decrypted messages, and the consolidation of error
   messages in a client-server protocol based on PKCS #1 v1.5 can all be
   effective countermeasures and don't involve changes to a PKCS #1
   v1.5-based protocol. These and other countermeasures are discussed in
   [5].

   Notes. The following passages describe some security recommendations
   pertaining to the use of RSAES-PKCS1-v1_5. Recommendations from
   version 1.5 of this document are included as well as new
   recommendations motivated by cryptanalytic advances made in the
   intervening years.

   -It is recommended that the pseudorandom octets in EME-PKCS1-v1_5 be
   generated independently for each encryption process, especially if
   the same data is input to more than one encryption process. Hastad's
   results [13] are one motivation for this recommendation.

   -The padding string PS in EME-PKCS1-v1_5 is at least eight octets
   long, which is a security condition for public-key operations that
   prevents an attacker from recovering data by trying all possible
   encryption blocks.

   -The pseudorandom octets can also help thwart an attack due to
   Coppersmith et al. [7] when the size of the message to be encrypted
   is kept small. The attack works on low-exponent RSA when similar
   messages are encrypted with the same public key. More specifically,
   in one flavor of the attack, when two inputs to RSAEP agree on a
   large fraction of bits (8/9) and low-exponent RSA (e = 3) is used to
   encrypt both of them, it may be possible to recover both inputs with
   the attack. Another flavor of the attack is successful in decrypting
   a single ciphertext when a large fraction (2/3) of the input to RSAEP
   is already known. For typical applications, the message to be
   encrypted is short (e.g., a 128-bit symmetric key) so not enough
   information will be known or common between two messages to enable
   the attack.  However, if a long message is encrypted, or if part of a
   message is known, then the attack may be a concern. In any case, the
   RSAEP-OAEP scheme overcomes the attack.






Kaliski & Staddon            Informational                     [Page 16]

RFC 2437        PKCS #1: RSA Cryptography Specifications    October 1998


7.2.1 Encryption operation

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

   Input:
   (n, e)  recipient's RSA public key
   M       message to be encrypted, an octet string of length at
           most k-11 octets, where k is the length in octets of the
           modulus n

   Output:
   C       ciphertext, an octet string of length k; or "message too
           long"

   Steps:

   1. Apply the EME-PKCS1-v1_5 encoding operation (Section 9.1.2.1) to
   the message M to produce an encoded message EM of length k-1 octets:

   EM = EME-PKCS1-V1_5-ENCODE (M, k-1)

   If the encoding operation outputs "message too long," then output
   "message too long" and stop.

   2. Convert the encoded message EM to an integer message
   representative m: m = OS2IP (EM)

   3. Apply the RSAEP encryption primitive (Section 5.1.1) to the public
   key (n, e) and the message representative m to produce an integer
   ciphertext representative c: c = RSAEP ((n, e), m)

   4. Convert the ciphertext representative c to a ciphertext C of
   length k octets: C = I2OSP (c, k)

   5. Output the ciphertext C.

7.2.2 Decryption operation

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

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

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



Kaliski & Staddon            Informational                     [Page 17]

RFC 2437        PKCS #1: RSA Cryptography Specifications    October 1998


   Steps:

   1. If the length of the ciphertext C is not k octets, output
   "decryption error" and stop.

   2. Convert the ciphertext C to an integer ciphertext representative
   c: c = OS2IP (C).

   3. Apply the RSADP decryption primitive to the private key (n, d) and
   the ciphertext representative c to produce an integer message
   representative m: m = RSADP ((n, d), c).

   If RSADP outputs "ciphertext out of range," then output "decryption
   error" and stop.

   4. Convert the message representative m to an encoded message EM of
   length k-1 octets: EM = I2OSP (m, k-1)

   If I2OSP outputs "integer too large," then output "decryption error"
   and stop.

   5. Apply the EME-PKCS1-v1_5 decoding operation to the encoded message
   EM to recover a message M: M = EME-PKCS1-V1_5-DECODE (EM).

   If the decoding operation outputs "decoding error," then output
   "decryption error" and stop.

   6. Output the message M.

   Note. It is important that only one type of error message is output
   by EME-PKCS1-v1_5, as ensured by steps 4 and 5. If this is not done,
   then an adversary may be able to use information extracted form the
   type of error message received to mount a chosen-ciphertext attack
   such as the one found in [4].

8. Signature schemes with appendix

   A signature scheme with appendix consists of a signature generation
   operation and a signature verification operation, where the signature
   generation operation produces a signature from a message with a
   signer's private key, and the signature verification operation
   verifies the signature on the message with the signer's corresponding
   public key.  To verify a signature constructed with this type of
   scheme it is necessary to have the message itself. In this way,
   signature schemes with appendix are distinguished from signature
   schemes with message recovery, which are not supported in this
   document.




Kaliski & Staddon            Informational                     [Page 18]

RFC 2437        PKCS #1: RSA Cryptography Specifications    October 1998


   A signature scheme with appendix can be employed in a variety of
   applications. For instance, X.509 [6] employs such a scheme to
   authenticate the content of a certificate; the signature scheme with
   appendix defined here would be a suitable signature algorithm in that
   context. A related signature scheme could be employed in PKCS #7
   [21], although for technical reasons, the current version of PKCS #7
   separates a hash function from a signature scheme, which is different
   than what is done here.

   One signature scheme with appendix is specified in this document:
   RSASSA-PKCS1-v1_5.

   The signature scheme with appendix given here follows a general model
   similar to that employed in IEEE P1363, by combining signature and
   verification primitives with an encoding method for signatures. The
   signature generation operations apply a message encoding operation to
   a message to produce an encoded message, which is then converted to
   an integer message representative. A signature primitive is then
   applied to the message representative to produce the signature. The
   signature verification operations apply a signature verification
   primitive to the signature to recover a message representative, which
   is then converted to an octet string. The message encoding operation
   is again applied to the message, and the result is compared to the
   recovered octet string. If there is a match, the signature is
   considered valid. (Note that this approach assumes that the signature
   and verification primitives have the message-recovery form and the
   encoding method is deterministic, as is the case for RSASP1/RSAVP1
   and EMSA-PKCS1-v1_5. The signature generation and verification
   operations have a different form in P1363 for other primitives and
   encoding methods.)

   Editor's note. RSA Laboratories is investigating the possibility of
   including a scheme based on the PSS encoding methods specified in
   [3], which would be recommended for new applications.

8.1 RSASSA-PKCS1-v1_5

   RSASSA-PKCS1-v1_5 combines the RSASP1 and RSAVP1 primitives with the
   EME-PKCS1-v1_5 encoding method. It is compatible with the IFSSA
   scheme defined in the draft P1363 where the signature and
   verification primitives are IFSP-RSA1 and IFVP-RSA1 and the message
   encoding method is EMSA-PKCS1-v1_5 (which is not defined in P1363).
   The length of messages on which RSASSA-PKCS1-v1_5 can operate is
   either unrestricted or constrained by a very large number, depending
   on the hash function underlying the message encoding method.






Kaliski & Staddon            Informational                     [Page 19]

RFC 2437        PKCS #1: RSA Cryptography Specifications    October 1998


   Assuming that the hash function in EMSA-PKCS1-v1_5 has appropriate
   properties and the key size is sufficiently large, RSASSA-PKCS1-v1_5
   provides secure signatures, meaning that it is computationally
   infeasible to generate a signature without knowing the private key,
   and computationally infeasible to find a message with a given
   signature or two messages with the same signature. Also, in the
   encoding method EMSA-PKCS1-v1_5, a hash function identifier is
   embedded in the encoding.  Because of this feature, an adversary must
   invert or find collisions of the particular hash function being used;
   attacking a different hash function than the one selected by the
   signer is not useful to the adversary.

8.1.1 Signature generation operation

   RSASSA-PKCS1-V1_5-SIGN (K, M)
   Input:
   K         signer's RSA private ke
   M         message to be signed, an octet string

   Output:
   S         signature, an octet string of length k, where k is the
             length in octets of the modulus n; "message too long" or
             "modulus too short"
   Steps:

   1. Apply the EMSA-PKCS1-v1_5 encoding operation (Section 9.2.1) to
   the message M to produce an encoded message EM of length k-1 octets:

   EM = EMSA-PKCS1-V1_5-ENCODE (M, k-1)

   If the encoding operation outputs "message too long," then output
   "message too long" and stop. If the encoding operation outputs
   "intended encoded message length too short" then output "modulus too
   short".

   2. Convert the encoded message EM to an integer message
   representative m: m = OS2IP (EM)

   3. Apply the RSASP1 signature primitive (Section 5.2.1) to the
   private key K and the message representative m to produce an integer
   signature representative s: s = RSASP1 (K, m)

   4. Convert the signature representative s to a signature S of length
   k octets: S = I2OSP (s, k)

   5. Output the signature S.





Kaliski & Staddon            Informational                     [Page 20]

RFC 2437        PKCS #1: RSA Cryptography Specifications    October 1998


8.1.2 Signature verification operation

   RSASSA-PKCS1-V1_5-VERIFY ((n, e), M, S)

   Input:
   (n, e)    signer's RSA public key
   M         message whose signature is to be verified, an octet string
   S         signature to be verified, an octet string of length k,
             where k is the length in octets of the modulus n

   Output: "valid signature," "invalid signature," or "message too