rfc2313.txt

RFC 的详细文档！

        o    digestAlgorithm identifies the message-digest
             algorithm (and any associated parameters). For
             this application, it should identify the selected
             message-digest algorithm, MD2, MD4 or MD5. For
             reference, the relevant object identifiers are the
             following:










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


   md2 OBJECT IDENTIFIER ::=

     { iso(1) member-body(2) US(840) rsadsi(113549)
         digestAlgorithm(2) 2 } md4 OBJECT IDENTIFIER ::=
     { iso(1) member-body(2) US(840) rsadsi(113549)
         digestAlgorithm(2) 4 } md5 OBJECT IDENTIFIER ::=
     { iso(1) member-body(2) US(840) rsadsi(113549)
         digestAlgorithm(2) 5 }

             For these object identifiers, the parameters field of the
             digestAlgorithm value should be NULL.

        o    digest is the result of the message-digesting
             process, i.e., the message digest MD.

   Notes.

        1.   A message-digest algorithm identifier is included
             in the DigestInfo value to limit the damage resulting from
             the compromise of one message-digest algorithm. For
             instance, suppose an adversary were able to find messages
             with a given MD2 message digest.  That adversary might try
             to forge a signature on a message by finding an innocuous-
             looking message with the same MD2 message digest, and
             coercing a signer to sign the innocuous-looking message.
             This attack would succeed only if the signer used MD2. If
             the DigestInfo value contained only the message digest,
             however, an adversary could attack signers that use any
             message digest.

        2.   Although it may be claimed that the use of a
             SEQUENCE type violates the literal statement in the X.509
             SIGNED and SIGNATURE macros that a signature is an
             ENCRYPTED OCTET STRING (as opposed to ENCRYPTED SEQUENCE),
             such a literal interpretation need not be required, as
             I'Anson and Mitchell point out [IM90].

        3.  No reason is known that MD4 would not be
             for very high security digital signature schemes, but
             because MD4 was designed to be exceptionally fast, it is
             "at the edge" in terms of risking successful cryptanalytic
             attack.  A message-digest algorithm can be considered
             "broken" if someone can find a collision: two messages with
             the same digest. While collisions have been found in
             variants of MD4 with only two digesting "rounds"






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


             [Mer90][dBB92], none have been found in MD4 itself, which
             has three rounds. After further critical review, it may be
             appropriate to consider MD4 for very high security
             applications.

             MD5, which has four rounds and is proportionally slower
             than MD4, is recommended until the completion of MD4's
             review. The reported "pseudocollisions" in MD5's internal
             compression function [dBB93] do not appear to have any
             practical impact on  MD5's security.

             MD2, the slowest of the three, has the most conservative
             design. No attacks on MD2 have been published.

10.1.3 RSA encryption

   The data D shall be encrypted with the signer's RSA private key as
   described in Section 7 to give an octet string ED, the encrypted
   data. The block type shall be 01. (See Section 8.1.)

10.1.4 Octet-string-to-bit-string conversion

   The encrypted data ED shall be converted into a bit string S, the
   signature. Specifically, the most significant bit of the first octet
   of the encrypted data shall become the first bit of the signature,
   and so on through the least significant bit of the last octet of the
   encrypted data, which shall become the last bit of the signature.

   Note. The length in bits of the signature S is a multiple of eight.

10.2 Verification process

   The verification process for both signature algorithms consists of
   four steps: bit-string-to-octet-string conversion, RSA decryption,
   data decoding, and message digesting and comparison. The input to the
   verification process shall be an octet string M, the message; a
   signer's public key; and a bit string S, the signature. The output
   from the verification process shall be an indication of success or
   failure.

10.2.1 Bit-string-to-octet-string conversion

   The signature S shall be converted into an octet string ED, the
   encrypted data. Specifically, assuming that the length in bits of the
   signature S is a multiple of eight, the first bit of the signature
   shall become the most significant bit of the first octet of the





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


   encrypted data, and so on through the last bit of the signature,
   which shall become the least significant bit of the last octet of the
   encrypted data.

   It is an error if the length in bits of the signature S is not a
   multiple of eight.

10.2.2 RSA decryption

   The encrypted data ED shall be decrypted with the signer's RSA public
   key as described in Section 8 to give an octet string D, the data.

   It is an error if the block type recovered in the decryption process
   is not 01. (See Section 9.4.)

10.2.3 Data decoding

   The data D shall be BER-decoded to give an ASN.1 value of type
   DigestInfo, which shall be separated into a message digest MD and a
   message-digest algorithm identifier. The message-digest algorithm
   identifier shall determine the "selected" message-digest algorithm
   for the next step.

   It is an error if the message-digest algorithm identifier does not
   identify the MD2, MD4 or MD5 message-digest algorithm.

10.2.4 Message digesting and comparison

   The message M shall be digested with the selected message-digest
   algorithm to give an octet string MD', the comparative message
   digest. The verification process shall succeed if the comparative
   message digest MD' is the same as the message digest MD, and the
   verification process shall fail otherwise.

11. Object identifiers

   This document defines five object identifiers: pkcs-1, rsaEncryption,
   md2WithRSAEncryption, md4WithRSAEncryption, and md5WithRSAEncryption.

   The object identifier pkcs-1 identifies this document.

   pkcs-1 OBJECT IDENTIFIER ::=

     { iso(1) member-body(2) US(840) rsadsi(113549)
         pkcs(1) 1 }






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


   The object identifier rsaEncryption identifies RSA public and private
   keys as defined in Section 7 and the RSA encryption and decryption
   processes defined in Sections 8 and 9.

   rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1 }

   The rsaEncryption object identifier is intended to be used in the
   algorithm field of a value of type AlgorithmIdentifier. The
   parameters field of that type, which has the algorithm-specific
   syntax ANY DEFINED BY algorithm, would have ASN.1 type NULL for this
   algorithm.

   The object identifiers md2WithRSAEncryption, md4WithRSAEncryption,
   md5WithRSAEncryption, identify, respectively, the "MD2 with RSA,"
   "MD4 with RSA," and "MD5 with RSA" signature and verification
   processes defined in Section 10.

   md2WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 2 }
   md4WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 3 }
   md5WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 4 }

   These object identifiers are intended to be used in the algorithm
   field of a value of type AlgorithmIdentifier. The parameters field of
   that type, which has the algorithm-specific syntax ANY DEFINED BY
   algorithm, would have ASN.1 type NULL for these algorithms.

   Note. X.509's object identifier rsa also identifies RSA public keys
   as defined in Section 7, but does not identify private keys, and
   identifies different encryption and decryption processes. It is
   expected that some applications will identify public keys by rsa.
   Such public keys are compatible with this document; an rsaEncryption
   process under an rsa public key is the same as the rsaEncryption
   process under an rsaEncryption public key.

Security Considerations

   Security issues are discussed throughout this memo.

Revision history

   Versions 1.0-1.3

   Versions 1.0-1.3 were distributed to participants in RSA Data
   Security, Inc.'s Public-Key Cryptography Standards meetings in
   February and March 1991.






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


   Version 1.4

   Version 1.4 is part of the June 3, 1991 initial public release of
   PKCS. Version 1.4 was published as NIST/OSI Implementors' Workshop
   document SEC-SIG-91-18.

   Version 1.5

   Version 1.5 incorporates several editorial changes, including updates
   to the references and the addition of a revision history. The
   following substantive changes were made:

        o    Section 10: "MD4 with RSA" signature and
             verification processes are added.

        o    Section 11: md4WithRSAEncryption object identifier
             is added.

   Supersedes June 3, 1991 version, which was also published as NIST/OSI
   Implementors' Workshop document SEC-SIG-91-18.

Acknowledgements

   This document is based on a contribution of RSA Laboratories, a
   division of RSA Data Security, Inc.  Any substantial use of the text
   from this document must acknowledge RSA Data Security, Inc. RSA Data
   Security, Inc.  requests that all material mentioning or referencing
   this document identify this as "RSA Data Security, Inc. PKCS #1".

Author's Address

   Burt Kaliski
   RSA Laboratories East
   20 Crosby Drive
   Bedford, MA  01730

   Phone: [phone]
   EMail: [e-mail]













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


Full Copyright Statement

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
























Kaliski                      Informational                     [Page 19]