rfc2313.txt

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

   Version ::= INTEGER

   The fields of type RSAPrivateKey have the following meanings:

        o    version is the version number, for compatibility
             with future revisions of this document. It shall
             be 0 for this version of the document.

        o    modulus is the modulus n.

        o    publicExponent is the public exponent e.

        o    privateExponent is the private exponent d.

        o    prime1 is the prime factor p of n.

        o    prime2 is the prime factor q of n.

        o    exponent1 is d mod (p-1).

        o    exponent2 is d mod (q-1).

        o    coefficient is the Chinese Remainder Theorem
             coefficient q-1 mod p.

   Notes.

        1.   An RSA private key logically consists of only the
             modulus n and the private exponent d. The presence of the
             values p, q, d mod (p-1), d mod (p-1), and q-1 mod p is
             intended for efficiency, as Quisquater and Couvreur have
             shown [QC82]. A private-key syntax that does not include




Kaliski                      Informational                      [Page 7]

RFC 2313                PKCS #1: RSA Encryption               March 1998


             all the extra values can be converted readily to the syntax
             defined here, provided the public key is known, according
             to a result by Miller [Mil76].

        2.   The presence of the public exponent e is intended
             to make it straightforward to derive a public key from the
             private key.

8. Encryption process

   This section describes the RSA encryption process.

   The encryption process consists of four steps: encryption- block
   formatting, octet-string-to-integer conversion, RSA computation, and
   integer-to-octet-string conversion. The input to the encryption
   process shall be an octet string D, the data; an integer n, the
   modulus; and an integer c, the exponent. For a public-key operation,
   the integer c shall be an entity's public exponent e; for a private-
   key operation, it shall be an entity's private exponent d. The output
   from the encryption process shall be an octet string ED, the
   encrypted data.

   The length of the data D shall not be more than k-11 octets, which is
   positive since the length k of the modulus is at least 12 octets.
   This limitation guarantees that the length of the padding string PS
   is at least eight octets, which is a security condition.

   Notes.

        1.   In typical applications of this document to
             encrypt content-encryption keys and message digests, one
             would have ||D|| <= 30. Thus the length of the RSA modulus
             will need to be at least 328 bits (41 octets), which is
             reasonable and consistent with security recommendations.

        2.   The encryption process does not provide an
             explicit integrity check to facilitate error detection
             should the encrypted data be corrupted in transmission.
             However, the structure of the encryption block guarantees
             that the probability that corruption is undetected is less
             than 2-16, which is an upper bound on the probability that
             a random encryption block looks like block type 02.

        3.   Application of private-key operations as defined
             here to data other than an octet string containing a
             message digest is not recommended and is subject to further
             study.




Kaliski                      Informational                      [Page 8]

RFC 2313                PKCS #1: RSA Encryption               March 1998


        4.   This document may be extended to handle data of
             length more than k-11 octets.

8.1 Encryption-block formatting

   A block type BT, a padding string PS, and the data D shall be
   formatted into an octet string EB, the encryption block.

              EB = 00 || BT || PS || 00 || D .           (1)

   The block type BT shall be a single octet indicating the structure of
   the encryption block. For this version of the document it shall have
   value 00, 01, or 02. For a private- key operation, the block type
   shall be 00 or 01. For a public-key operation, it shall be 02.

   The padding string PS shall consist of k-3-||D|| octets. For block
   type 00, the octets shall have value 00; for block type 01, they
   shall have value FF; and for block type 02, they shall be
   pseudorandomly generated and nonzero. This makes the length of the
   encryption block EB equal to k.

   Notes.

        1.   The leading 00 octet ensures that the encryption
             block, converted to an integer, is less than the modulus.

        2.   For block type 00, the data D must begin with a
             nonzero octet or have known length so that the encryption
             block can be parsed unambiguously. For block types 01 and
             02, the encryption block can be parsed unambiguously since
             the padding string PS contains no octets with value 00 and
             the padding string is separated from the data D by an octet
             with value 00.

        3.   Block type 01 is recommended for private-key
             operations. Block type 01 has the property that the
             encryption block, converted to an integer, is guaranteed to
             be large, which prevents certain attacks of the kind
             proposed by Desmedt and Odlyzko [DO86].

        4.   Block types 01 and 02 are compatible with PEM RSA
             encryption of content-encryption keys and message digests
             as described in RFC 1423.








Kaliski                      Informational                      [Page 9]

RFC 2313                PKCS #1: RSA Encryption               March 1998


        5.   For block type 02, it is recommended that the
             pseudorandom octets be generated independently for each
             encryption process, especially if the same data is input to
             more than one encryption process.  Hastad's results [Has88]
             motivate this recommendation.

        6.   For block type 02, the padding string is at least
             eight octets long, which is a security condition for
             public-key operations that prevents an attacker from
             recoving data by trying all possible encryption blocks. For
             simplicity, the minimum length is the same for block type
             01.

        7.   This document may be extended in the future to
             include other block types.

8.2 Octet-string-to-integer conversion

   The encryption block EB shall be converted to an integer x, the
   integer encryption block. Let EB1, ..., EBk be the octets of EB from
   first to last. Then the integer x shall satisfy

                                     k
                x =  SUM  2^(8(k-i)) EBi .              (2)
                                   i = 1

   In other words, the first octet of EB has the most significance in
   the integer and the last octet of EB has the least significance.

   Note. The integer encryption block x satisfies 0 <= x <  n since EB1
   = 00 and 2^(8(k-1)) <= n.

8.3 RSA computation

   The integer encryption block x shall be raised to the power c modulo
   n to give an integer y, the integer encrypted data.

                       y = x^c mod n,  0 <= y < n .

   This is the classic RSA computation.

8.4 Integer-to-octet-string conversion

   The integer encrypted data y shall be converted to an octet string ED
   of length k, the encrypted data. The encrypted data ED shall satisfy






Kaliski                      Informational                     [Page 10]

RFC 2313                PKCS #1: RSA Encryption               March 1998


                                     k
                y =  SUM  2^(8(k-i)) EDi .              (3)
                                   i = 1

   where ED1, ..., EDk are the octets of ED from first to last.

   In other words, the first octet of ED has the most significance in
   the integer and the last octet of ED has the least significance.

9. Decryption process

   This section describes the RSA decryption process.

   The decryption process consists of four steps: octet-string-to-
   integer conversion, RSA computation, integer-to-octet-string
   conversion, and encryption-block parsing. The input to the decryption
   process shall be an octet string ED, the encrypted data; an integer
   n, the modulus; and an integer c, the exponent. For a public-key
   operation, the integer c shall be an entity's public exponent e; for
   a private-key operation, it shall be an entity's private exponent d.
   The output from the decryption process shall be an octet string D,
   the data.

   It is an error if the length of the encrypted data ED is not k.

   For brevity, the decryption process is described in terms of the
   encryption process.

9.1 Octet-string-to-integer conversion

   The encrypted data ED shall be converted to an integer y, the integer
   encrypted data, according to Equation (3).

   It is an error if the integer encrypted data y does not satisfy 0 <=
   y < n.

9.2 RSA computation

   The integer encrypted data y shall be raised to the power c modulo n
   to give an integer x, the integer encryption block.

                       x = y^c mod n,  0 <= x < n .

   This is the classic RSA computation.







Kaliski                      Informational                     [Page 11]

RFC 2313                PKCS #1: RSA Encryption               March 1998


9.3 Integer-to-octet-string conversion

   The integer encryption block x shall be converted to an octet string
   EB of length k, the encryption block, according to Equation (2).

9.4 Encryption-block parsing

   The encryption block EB shall be parsed into a block type BT, a
   padding string PS, and the data D according to Equation (1).

   It is an error if any of the following conditions occurs:

        o    The encryption block EB cannot be parsed
             unambiguously (see notes to Section 8.1).

        o    The padding string PS consists of fewer than eight
             octets, or is inconsistent with the block type BT.

        o    The decryption process is a public-key operation
             and the block type BT is not 00 or 01, or the decryption
             process is a private-key operation and the block type is
             not 02.

10. Signature algorithms

   This section defines three signature algorithms based on the RSA
   encryption process described in Sections 8 and 9. The intended use of
   the signature algorithms is in signing X.509/PEM certificates and
   certificate-revocation lists, PKCS #6 extended certificates, and
   other objects employing digital signatures such as X.401 message
   tokens. The algorithms are not intended for use in constructing
   digital signatures in PKCS #7. The first signature algorithm
   (informally, "MD2 with RSA") combines the MD2 message-digest
   algorithm with RSA, the second (informally, "MD4 with RSA") combines
   the MD4 message-digest algorithm with RSA, and the third (informally,
   "MD5 with RSA") combines the MD5 message-digest algorithm with RSA.

   This section describes the signature process and the verification
   process for the two algorithms. The "selected" message-digest
   algorithm shall be either MD2 or MD5, depending on the signature
   algorithm. The signature process shall be performed with an entity's
   private key and the verification process shall be performed with an
   entity's public key. The signature process transforms an octet string
   (the message) to a bit string (the signature); the verification
   process determines whether a bit string (the signature) is the
   signature of an octet string (the message).





Kaliski                      Informational                     [Page 12]

RFC 2313                PKCS #1: RSA Encryption               March 1998


   Note. The only difference between the signature algorithms defined
   here and one of the the methods by which signatures (encrypted
   message digests) are constructed in PKCS #7 is that signatures here
   are represented here as bit strings, for consistency with the X.509
   SIGNED macro. In PKCS #7 encrypted message digests are octet strings.

10.1 Signature process

   The signature process consists of four steps: message digesting, data
   encoding, RSA encryption, and octet-string-to-bit-string conversion.
   The input to the signature process shall be an octet string M, the
   message; and a signer's private key. The output from the signature
   process shall be a bit string S, the signature.

10.1.1 Message digesting

   The message M shall be digested with the selected message- digest
   algorithm to give an octet string MD, the message digest.

10.1.2 Data encoding

   The message digest MD and a message-digest algorithm identifier shall
   be combined into an ASN.1 value of type DigestInfo, described below,
   which shall be BER-encoded to give an octet string D, the data.

   DigestInfo ::= SEQUENCE {
     digestAlgorithm DigestAlgorithmIdentifier,
     digest Digest }

   DigestAlgorithmIdentifier ::= AlgorithmIdentifier

   Digest ::= OCTET STRING

   The fields of type DigestInfo have the following meanings: