rfc3217.txt

RFC 的详细文档！

       significant (first) 8 octets, and TEMP1 is the remaining octets.
   5.  Decrypt TEMP1 in CBC mode using the key-encryption key.  Use the
       IV value from the previous step as the initialization vector.
       Call the plaintext LCEKPADICV.
   6.  Decompose the LCEKPADICV into LCEKPAD, and ICV.  ICV is the least
       significant (last) octet 8 octets.  LCEKPAD is the remaining
       octets.
   7.  Compute an 8 octet key checksum value on LCEKPAD as described
       above in Section 2.  If the computed key checksum value does not
       match the decrypted key checksum value, ICV, then error.
   8.  Decompose the LCEKPAD into LENGTH, CEK, and PAD.  LENGTH is the
       most significant (first) octet.  CEK is the following LENGTH
       octets.  PAD is the remaining octets, if any.
   9.  If the length of PAD is more than 7 octets, then error.
   10. Use CEK as an RC2 key.

4.3  RC2 Key Wrap Algorithm Identifier

   Some security protocols employ ASN.1 [X.208-88, X.209-88], and these
   protocols employ algorithm identifiers to name cryptographic
   algorithms.  To support these protocols, the RC2 key wrap algorithm
   has been assigned the following algorithm identifier:





Housley                      Informational                      [Page 5]

RFC 3217            Triple-DES and RC2 Key Wrapping        December 2001


      id-alg-CMSRC2wrap OBJECT IDENTIFIER ::= { iso(1) member-body(2)
         us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 7 }

   The AlgorithmIdentifier parameter field MUST be RC2wrapParameter:

      RC2wrapParameter ::= RC2ParameterVersion

      RC2ParameterVersion ::= INTEGER

   The RC2 effective-key-bits (key size) greater than 32 and less than
   256 is encoded in the RC2ParameterVersion.  For the effective-key-
   bits of 40, 64, and 128, the rc2ParameterVersion values are 160, 120,
   and 58 respectively.  These values are not simply the RC2 key length.
   Note that the value 160 must be encoded as two octets (00 A0),
   because the one octet (A0) encoding represents a negative number.

4.4  RC2 Key Wrap Example

   This section contains a RC2 Key Wrap example.  Intermediate values
   corresponding to the named items in section 4.1 are given in
   hexadecimal.

   CEK:        b70a 25fb c9d8 6a86 050c e0d7 11ea d4d9
   KEK:        fd04 fd08 0607 07fb 0003 feff fd02 fe05
   LENGTH:     10
   LCEK:       10b7 0a25 fbc9 d86a 8605 0ce0 d711 ead4 d9
   PAD:        4845 cce7 fd12 50
   LCEKPAD:    10b7 0a25 fbc9 d86a 8605 0ce0 d711 ead4
               d948 45cc e7fd 1250
   ICV:        0a6f f19f db40 4988
   LCEKPADICV: 10b7 0a25 fbc9 d86a 8605 0ce0 d711 ead4
               d948 45cc e7fd 1250 0a6f f19f db40 4988
   IV:         c7d9 0059 b29e 97f7
   TEMP1:      a01d a259 3793 1260 e48c 55f5 04ce 70b8
               ac8c d79e ffe8 9932 9fa9 8a07 a31f f7a7
   TEMP2:      c7d9 0059 b29e 97f7 a01d a259 3793 1260
               e48c 55f5 04ce 70b8 ac8c d79e ffe8 9932
               9fa9 8a07 a31f f7a7
   TEMP3:      a7f7 1fa3 078a a99f 3299 8eff 9ed7 8cac
               b870 ce04 f555 8ce4 6012 9337 59a2 1da0
               f797 9eb2 5900 d9c7
   RESULT:     70e6 99fb 5701 f783 3330 fb71 e87c 85a4
               20bd c99a f05d 22af 5a0e 48d3 5f31 3898
               6cba afb4 b28d 4f35







Housley                      Informational                      [Page 6]

RFC 3217            Triple-DES and RC2 Key Wrapping        December 2001


5  References

   [3DES]     American National Standards Institute.  ANSI X9.52-1998,
              Triple Data Encryption Algorithm Modes of Operation.
              1998.

   [CMS]      Housley, R., "Cryptographic Message Syntax", RFC 2630,
              June 1999.

   [DES]      American National Standards Institute.  ANSI X3.106,
              "American National Standard for Information Systems - Data
              Link Encryption".  1983.

   [DH-X9.42] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC
              2631, June 1999.

   [DSS]      National Institute of Standards and Technology.  FIPS Pub
              186: Digital Signature Standard.  19 May 1994.

   [MODES]    National Institute of Standards and Technology.  FIPS Pub
              81: DES Modes of Operation.  2 December 1980.

   [RANDOM]   Eastlake, D., Crocker, S. and J. Schiller, "Randomness
              Recommendations for Security", RFC 1750, December 1994.

   [RC2]      Rivest, R., "A Description of the RC2 (r) Encryption
              Algorithm", RFC 2268, March 1998.

   [SHA1]     National Institute of Standards and Technology.  FIPS Pub
              180-1: Secure Hash Standard.  17 April 1995.

   [STDWORDS] Bradner, S., "Key Words for Use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [X.208-88] CCITT.  Recommendation X.208: Specification of Abstract
              Syntax Notation One (ASN.1).  1988.

   [X.209-88] CCITT.  Recommendation X.209: Specification of Basic
              Encoding Rules for Abstract Syntax Notation One (ASN.1).
              1988.











Housley                      Informational                      [Page 7]

RFC 3217            Triple-DES and RC2 Key Wrapping        December 2001


6  Security Considerations

   Implementations must protect the key-encryption key.  Compromise of
   the key-encryption key may result in the disclosure of all keys that
   have been wrapped with the key-encryption key, which may lead to the
   disclosure of all traffic protected with those wrapped key.

   Implementations must randomly generate initialization vectors (IVs)
   and padding.  The generation of quality random numbers is difficult.
   RFC 1750 [RANDOM] offers important guidance in this area, and
   Appendix 3 of FIPS Pub 186 [DSS] provides one quality PRNG technique.

   If the key-encryption key and wrapped key are associated with
   different symmetric encryption algorithms, the effective security
   provided to data encrypted with the wrapped key is determined by the
   weaker of the two algorithms.  If, for example, data is encrypted
   with 168-bit Triple-DES and that Triple-DES key is wrapped with a
   40-bit RC2 key, then at most 40 bits of protection is provided.  A
   trivial search to determine the value of the 40-bit RC2 key can
   recover Triple-DES key, and then the Triple-DES key can be used to
   decrypt the content.  Therefore, implementers must ensure that key-
   encryption algorithms are as strong or stronger than content-
   encryption algorithms.

   These key wrap algorithms specified in this document have been
   reviewed for use with Triple-DES and RC2, and they have not been
   reviewed for use with other encryption algorithms.  Similarly, the
   key wrap algorithms make use of CBC mode [MODES], and they have not
   been reviewed for use with other cryptographic modes.

7  Acknowledgments

   This document is the result of contributions from many professionals.
   I appreciate the hard work of all members of the IETF S/MIME Working
   Group.  I extend a special thanks to Carl Ellison, Peter Gutmann, Bob
   Jueneman, Don Johnson, Burt Kaliski, John Pawling, and Jim Schaad for
   their support in defining these algorithms and generating this
   specification.

8  Author Address

   Russell Housley
   RSA Laboratories
   918 Spring Knoll Drive
   Herndon, VA 20170
   USA

   EMail: [e-mail]



Housley                      Informational                      [Page 8]

RFC 3217            Triple-DES and RC2 Key Wrapping        December 2001


9  Full Copyright Statement

   Copyright (C) The Internet Society (2001).  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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Housley                      Informational                      [Page 9]