rfc1851.txt

RFC 的详细文档！

   Append a Payload Type octet containing the IP Protocol/Payload value
   which identifies the protocol header that begins the payload.

   Provide an Initialization Vector (IV) of the size indicated by the
   SPI.

   Encrypt the payload with Triple DES (EDE mode), producing a
   ciphertext of the same length.

   Octets are mapped to DES blocks in network order (most significant
   octet first) [RFC-1700].  Octet 0 (modulo 8) of the payload
   corresponds to bits 1-8 of the 64-bit DES input block, while octet 7
   (modulo 8) corresponds to bits 57-64 of the DES input block.

   Construct an appropriate IP datagram for the target Destination, with
   the indicated SPI, IV, and payload.

   The Total/Payload Length in the encapsulating IP Header reflects the
   length of the encrypted data, plus the SPI, IV, padding, Pad Length,
   and Payload Type octets.






Karn, et al                   Experimental                      [Page 6]

RFC 1851                        ESP 3DES                  September 1995


3.2.  Decryption

   First, the SPI field is removed and examined.  This is used as an
   index into the local Security Parameter table to find the negotiated
   parameters and decryption key.

   The negotiated form of the IV determines the size of the IV field.
   These octets are removed, and an appropriate 64-bit IV value is
   constructed.

   The encrypted part of the payload is decrypted using Triple DES (DED
   mode).

   The Payload Type is removed and examined.  If it is unrecognized, the
   payload is discarded with an appropriate ICMP message.

   The Pad Length is removed and examined.  The specified number of pad
   octets are removed from the end of the decrypted payload, and the IP
   Total/Payload Length is adjusted accordingly.

   The IP Header(s) and the remaining portion of the decrypted payload
   are passed to the protocol receive routine specified by the Payload
   Type field.



Security Considerations

   Users need to understand that the quality of the security provided by
   this specification depends completely on the strength of the Triple
   DES algorithm, the correctness of that algorithm's implementation,
   the security of the key management mechanism and its implementation,
   the strength of the key [CN94], and upon the correctness of the
   implementations in all of the participating nodes.

   Among other considerations, applications may wish to take care not to
   select weak keys for any of the three DES rounds, although the odds
   of picking one at random are low [Schneier94, p. 233].

   It was originally thought that DES might be a group, but it has been
   demonstrated that it is not [CW92].  Since DES is not a group,
   composition of multiple rounds of DES is not equivalent to simply
   using DES with a different key.

   Triple DES with independent keys is not, as naively might be
   expected, as difficult to break by brute force as a cryptosystem with
   three times the keylength.  A space/time tradeoff has been shown
   which can brute-force break triple block encryptions in the time



Karn, et al                   Experimental                      [Page 7]

RFC 1851                        ESP 3DES                  September 1995


   naively expected for double encryption [MH81].

   However, 2DES can be broken with a meet-in-the-middle attack, without
   significantly more complexity than breaking DES requires [ibid], so
   3DES with independant keys is actually needed to provide this level
   of security.  An attack on 3DES using two independent keys that is
   somewhat (sixteen times) faster than any known for independent keys
   has been shown [OW91].

   The cut and paste attack described by [Bell95] exploits the nature of
   all Cipher Block Chaining algorithms.  When a block is damaged in
   transmission, on decryption both it and the following block will be
   garbled by the decryption process, but all subsequent blocks will be
   decrypted correctly.  If an attacker has legitimate access to the
   same key, this feature can be used to insert or replay previously
   encrypted data of other users of the same engine, revealing the
   plaintext.  The usual (ICMP, TCP, UDP) transport checksum can detect
   this attack, but on its own is not considered cryptographically
   strong.  In this situation, user or connection oriented integrity
   checking is needed [RFC-1826].

   Although it is widely believed that 3DES is substantially stronger
   than DES, as it is less amenable to brute force attack, it should be
   noted that real cryptanalysis of 3DES might not use brute force
   methods at all.  Instead, it might be performed using variants on
   differential [BS93] or linear [Matsui94] cryptanalysis.  It should
   also be noted that no encryption algorithm is permanently safe from
   brute force attack, because of the increasing speed of modern
   computers.

   As with all cryptosystems, those responsible for applications with
   substantial risk when security is breeched should pay close attention
   to developments in cryptography, and especially cryptanalysis, and
   switch to other transforms should 3DES prove weak.



Acknowledgements

   Some of the text of this specification was derived from work by
   Randall Atkinson for the SIP, SIPP, and IPv6 Working Groups.

   Comments should be submitted to the [e-mail] mailing list.








Karn, et al                   Experimental                      [Page 8]

RFC 1851                        ESP 3DES                  September 1995


References

   [Bell95] Bellovin, S., "An Issue With DES-CBC When Used Without
            Strong Integrity", Proceedings of the 32nd IETF, Danvers,
            MA, April 1995.

   [BS93]   Biham, E., and Shamir, A., "Differential Cryptanalysis of
            the Data Encryption Standard", Berlin: Springer-Verlag,
            1993.

   [CN94]   Carroll, J.M., and Nudiati, S., "On Weak Keys and Weak Data:
            Foiling the Two Nemeses", Cryptologia, Vol. 18 No. 23 pp.
            253-280, July 1994.

   [CW92]   Campbell, K.W., and Wiener, M.J., "Proof that DES Is Not a
            Group", Advances in Cryptology -- Crypto '92 Proceedings,
            Berlin: Springer-Verlag, 1993, pp 518-526.

   [FIPS-46]
            US National Bureau of Standards, "Data Encryption Standard",
            Federal Information Processing Standard (FIPS) Publication
            46, January 1977.

   [FIPS-46-1]
            US National Bureau of Standards, "Data Encryption Standard",
            Federal Information Processing Standard (FIPS) Publication
            46-1, January 1988.

   [FIPS-74]
            US National Bureau of Standards, "Guidelines for
            Implementing and Using the Data Encryption Standard",
            Federal Information Processing Standard (FIPS) Publication
            74, April 1981.

   [FIPS-81]
            US National Bureau of Standards, "DES Modes of Operation"
            Federal Information Processing Standard (FIPS) Publication
            81, December 1980.

   [Matsui94]
            Matsui, M., "Linear Cryptanalysis method dor DES Cipher,"
            Advances in Cryptology -- Eurocrypt '93 Proceedings, Berlin:
            Springer-Verlag, 1994.

   [MH81]   Merle, R.C., and Hellman, M., "On the Security of Multiple
            Encryption", Communications of the ACM, v. 24 n. 7, 1981,
            pp. 465-467.




Karn, et al                   Experimental                      [Page 9]

RFC 1851                        ESP 3DES                  September 1995


   [OW91]   van Oorschot, P.C., and Weiner, M.J.  "A Known-Plaintext
            Attack on Two-Key Triple Encryption", Advances in Cryptology
            -- Eurocrypt '90 Proceedings, Berlin: Springer-Verlag, 1991,
            pp. 318-325.

   [RFC-1800]
            Postel, J., "Internet Official Protocol Standards", STD 1,
            RFC 1800, USC/Information Sciences Institute, July 1995.

   [RFC-1700]
            Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
            1700, USC/Information Sciences Institute, October 1994.

   [RFC-1825]
            Atkinson, R., "Security Architecture for the Internet
            Protocol", RFC-1825, Naval Research Laboratory, July 1995.

   [RFC-1826]
            Atkinson, R., "IP Authentication Header", RFC-1826, Naval
            Research Laboratory, July 1995.

   [RFC-1827]
            Atkinson, R., "IP Encapsulating Security Protocol (ESP)",
            RFC-1827, Naval Research Laboratory, July 1995.

   [Schneier94]
            Schneier, B., "Applied Cryptography", John Wiley & Sons, New
            York, NY, 1994.  ISBN 0-471-59756-2

   [Tuchman79]
            Tuchman, W, "Hellman Presents No Shortcut Solutions to DES",
            IEEE Spectrum, v. 16 n. 7, July 1979, pp. 40-41.



















Karn, et al                   Experimental                     [Page 10]

RFC 1851                        ESP 3DES                  September 1995


Author's Address

   Questions about this memo can also be directed to:

      Phil Karn
      Qualcomm, Inc.
      6455 Lusk Blvd.
      San Diego, California  92121-2779

      [e-mail]


      Perry Metzger
      Piermont Information Systems Inc.
      160 Cabrini Blvd., Suite #2
      New York, NY  10033

      [e-mail]


      William Allen Simpson
      Daydreamer
      Computer Systems Consulting Services
      1384 Fontaine
      Madison Heights, Michigan  48071

      [e-mail]
          [e-mail]























Karn, et al                   Experimental                     [Page 11]