RFC 2405

The ESP DES-CBC Cipher Algorithm With Explicit IV

📅 published November 1998, from ietf

The ESP DES-CBC Cipher Algorithm With Explicit IV 🎀

okay bestie, this is RFC 2405 and it's giving DES in CBC mode with an explicit IV for ESP 💅

Title block deets 📋: it's from the Network Working Group and written by C. Madson (Cisco Systems, Inc.) and N. Doraswamy (Bay Networks, Inc.). The category is Standards Track and the date is November 1998. The title block doesn't list any RFCs it obsoletes or updates, so there's nothing to chase there 🦋

Status of This Memo ✨

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

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

Abstract 💜

This document describes the use of the DES Cipher algorithm in Cipher Block Chaining Mode, with an explicit IV, as a confidentiality mechanism within the context of the IPSec Encapsulating Security Payload (ESP).

1. Introduction 🌸

okay so this section sets the scene: DES-CBC is used as a confidentiality mechanism inside the Encapsulating Security Payload 🔐

DES is a symmetric block cipher algorithm. It's described in [FIPS-46-2][FIPS-74][FIPS-81]. [Schneier96] gives a general description of Cipher Block Chaining Mode, which is a mode that works with several encryption algorithms, so it's not just a DES thing 🧚

Here's the important bit: as specified in this memo, DES-CBC is not an authentication mechanism 🙈 [Although DES-MAC, described in [Schneier96] amongst other places, does provide authentication, DES-MAC is not discussed here.]

For how all the pieces of ESP fit together to provide security services, check out [ESP] and [road] 💖

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119] ✨

2. Algorithm and Mode 🦋

DES-CBC is a symmetric secret-key block algorithm. It has a block size of 64 bits 💅

[FIPS-46-2][FIPS-74] and [FIPS-81] describe the DES algorithm, while [Schneier96] gives a good description of CBC mode 📚

2.1. Performance 🚀

Phil Karn tuned DES-CBC software to hit 10.45 Mbps on a 90 MHz Pentium, scaling up to 15.9 Mbps on a 133 MHz Pentium. Other DES speed estimates can be found in [Schneier96] 🔥

3. ESP Payload 🎀

okay this part is about how the bytes actually look on the wire 👀

DES-CBC requires an explicit Initialization Vector (IV) of 8 octets (64 bits). This IV immediately precedes the protected (encrypted) payload. The IV MUST be a random value 🎲

Including the IV in each datagram means every received datagram can be decrypted, even when some datagrams are dropped or re-ordered in transit. Iconic resilience 👑

Implementation note: 🫶

Common practice is to use random data for the first IV, and the last 8 octets of encrypted data from one encryption process as the IV for the next encryption process. This logically extends the CBC across packets. It also has the advantage of limiting the leakage of information from the random number generator. No matter which mechanism is used, the receiver MUST NOT assume any meaning for this value, other than that it is an IV.

To avoid ECB encryption of very similar plaintext blocks in different packets, implementations MUST NOT use a counter or other low-Hamming distance source for IVs 🙅‍♀️

The payload field, as defined in [ESP], is broken down according to the following diagram 🧩

    +---------------+---------------+---------------+---------------+
    |                                                               |
    +                   Initialization Vector (IV)                  +
    |                                                               |
    +---------------+---------------+---------------+---------------+
    |                                                               |
    ~              Encrypted Payload (variable length)              ~
    |                                                               |
    +---------------------------------------------------------------+
     1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8

3.1. Block Size and Padding 🍓

The DES-CBC algorithm described in this document MUST use a block size of 8 octets (64 bits).

When padding is required, it MUST be done according to the conventions specified in [ESP] ✨

Heads up bestie: there is no section 3.5 in this RFC. After 3.1 the next section is 4, so that's where part 2 picks up 🫶

Part 1 is wrapped 🎀 Part 2 is coming with Key Material (section 4), the weak keys and key lifetime talk, and the Interaction with Authentication Algorithms section, so stay tuned 💜

6. Security Considerations ✨

🔐 Okay bestie, this part is SERIOUS, so listen up. [Much of this section was originally written by William Allen Simpson and Perry Metzger.] The security this spec gives you depends COMPLETELY on how strong DES is, whether that algorithm is implemented correctly, how secure the Security Association management mechanism and its implementation are, how strong the key is [CN94], and whether every participating node implements things correctly. One weak link and the whole chain is cooked 💀

[Bell95] and [Bell96] describe a cut and paste splicing attack that hits ALL Cipher Block Chaining algorithms. The fix is to use an authentication mechanism 🛡️

Using the cipher with NO authentication mechanism is strongly discouraged, no cap. It CAN be used in an ESP transform that also includes authentication. It can also be used in an ESP transform that doesn't include authentication, but only if there's a companion AH header. For the full tea, check out [ESP], [AH], [arch], and [road] 📚

When the default ESP padding is used, the padding bytes have a predictable value. They give you a little bit of tamper detection on their own block and the previous block in CBC mode, which makes splicing attacks somewhat harder and avoids a possible covert channel 🕵️‍♀️ That small amount of known plaintext doesn't cause any problems for modern ciphers, so we're good ✨

At the time of writing, [BS93] showed a differential cryptanalysis based chosen-plaintext attack that needs 2^47 plaintext-ciphertext pairs, where each pair is the size of a DES block (64 bits). [Matsui94] showed a linear cryptanalysis based known-plaintext attack that needs only 2^43 plaintext-ciphertext pairs. These attacks aren't considered practical, but they still MUST be taken into account in your thinking. (Okay, I'm yelling, but you know I mean it 🙈)

Now the scary part 😭 [Wiener94] showed the design of a DES cracking machine that costs $1 Million and can crack one key every 3.5 hours. That is an extremely practical attack. Iconic? No. Terrifying? Yes.

One or two blocks of known plaintext are enough to recover a DES key. IP datagrams typically begin with a block of known and/or guessable header text, so frequent key changes will NOT protect you from this attack 💀

So it's suggested that DES is not a good encryption algorithm for protecting even moderate value information against equipment like that. Triple DES is probably a better choice for those purposes 🔒

Still, even with all these risks, the privacy you get from ESP DES-CBC on the Internet is WAY better than sending the datagram as cleartext. Not nothing, bestie 💖

The case for random IVs got a refined summary from Steve Bellovin, and you can read more in [Bell97]. Here's his explanation:

"The problem arises if you use a counter as an IV, or some other source with a low Hamming distance between successive IVs, for encryption in CBC mode. In CBC mode, the "effective plaintext" for an encryption is the XOR of the actual plaintext and the ciphertext of the preceeding block. Normally, that's a random value, which means that the effective plaintext is quite random. That's good, because many blocks of actual plaintext don't change very much from packet to packet, either. For the first block of plaintext, though, the IV takes the place of the previous block of ciphertext. If the IV doesn't differ much from the previous IV, and the actual plaintext block doesn't differ much from the previous packet's, then the effective plaintext won't differ much, either. This means that you have pairs of ciphertext blocks combined with plaintext blocks that differ in just a few bit positions. This can be a wedge for assorted cryptanalytic attacks."

The discussion on IVs has been updated to require that an implementation not use a low-Hamming distance source for IVs. Don't be the implementer who uses a counter, bestie 🙅‍♀️

7. References 📚

  • [Bell95] Bellovin, S., "An Issue With DES-CBC When Used Without Strong Integrity", Presentation at the 32nd Internet Engineering Task Force, Danvers Massachusetts, April 1995.
  • [Bell96] Bellovin, S., "Problem Areas for the IP Security Protocols", Proceedings of the Sixth Usenix Security Symposium, July 1996.
  • [Bell97] Bellovin, S., "Probable Plaintext Cryptanalysis of the IP Security Protocols", Proceedings of the Symposium on Network and Distributed System Security, San Diego, CA, pp. 155-160, February 1997 (also http://www.research.att.com/~smb/papers/probtxt.{ps, pdf}).
  • [BS93] Biham, E., and A. Shamir, "Differential Cryptanalysis of the Data Encryption Standard", Berlin: Springer-Verlag, 1993.
  • [Blaze96] Blaze, M., Diffie, W., Rivest, R., Schneier, B., Shimomura, T., Thompson, E., and M. Wiener, "Minimal Key Lengths for Symmetric Ciphers to Provide Adequate Commercial Security", currently available at http://www.bsa.org/policy/encryption/cryptographers.html.
  • [CN94] Carroll, J.M., and S. Nudiati, "On Weak Keys and Weak Data: Foiling the Two Nemeses", Cryptologia, Vol. 18 No. 23 pp. 253-280, July 1994.
  • [FIPS-46-2] US National Bureau of Standards, "Data Encryption Standard", Federal Information Processing Standard (FIPS) Publication 46-2, December 1993, http://www.itl.nist.gov/div897/pubs/fip46-2.htm (supercedes FIPS-46-1).
  • [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, http://www.itl.nist.gov/div897/pubs/fip74.htm.
  • [FIPS-81] US National Bureau of Standards, "DES Modes of Operation", Federal Information Processing Standard (FIPS) Publication 81, December 1980, http://www.itl.nist.gov/div897/pubs/fip81.htm.
  • [Matsui94] Matsui, M., "Linear Cryptanalysis method for DES Cipher", Advances in Cryptology -- Eurocrypt '93 Proceedings, Berlin: Springer-Verlag, 1994.
  • [RFC-1750] Eastlake, D., Crocker, S., and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
  • [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [Schneier96] Schneier, B., "Applied Cryptography Second Edition", John Wiley & Sons, New York, NY, 1996. ISBN 0-471-12845-7.
  • [Wiener94] Wiener, M.J., "Efficient DES Key Search", School of Computer Science, Carleton University, Ottawa, Canada, TR-244, May 1994. Presented at the Rump Session of Crypto '93. [Reprinted in "Practical Cryptography for Data Internetworks", W.Stallings, editor, IEEE Computer Society Press, pp.31-79 (1996). Currently available at ftp://ripem.msu.edu/pub/crypt/docs/des-key-search.ps.]
  • [ESP] Kent, S., and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
  • [AH] Kent, S., and R. Atkinson, "IP Authentication Header (AH)", RFC 2402, November 1998.
  • [arch] Kent, S., and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
  • [road] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.

8. Acknowledgments 🫶

Okay, the people who made this happen deserve ALL the flowers 💐 Much of the info here came from various ESP-DES documents written by Perry Metzger and William Allen Simpson, especially the Security Considerations section.

This document is also partly derived from earlier work by Jim Hughes, the people who worked with Jim on the combined DES-CBC+HMAC-MD5 ESP transforms, the ANX bakeoff participants, and the members of the IPsec working group. Main character energy from the whole crew 👑

Thanks to Rob Glenn for helping with the nroff formatting 🎀

The IPSec working group can be reached through its mailing list (ipsec@tis.com) or through its chairs:

  • Robert Moskowitz, International Computer Security Association, EMail: rgm@icsa.net
  • Theodore Y. Ts'o, Massachusetts Institute of Technology, EMail: tytso@MIT.EDU

9. Editors' Addresses 💌

  • Cheryl Madson, Cisco Systems, Inc., EMail: cmadson@cisco.com
  • Naganand Doraswamy, Bay Networks, Inc., EMail: naganand@baynetworks.com

Legal bit, but make it cute 🎀 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. 💜

📦 where this page comes from