RFC 1851
The ESP Triple DES Transform
RFC 1851: The ESP Triple DES Transform 🎀
okay bestie, this is RFC 1851, "The ESP Triple DES Transform" ✨ It came from the Network Working Group, dated September 1995. The authors are P. Karn (Qualcomm), P. Metzger (Piermont), and W. Simpson (Daydreamer) 💖 It's marked as Experimental 🧪 and the title block doesn't list anything it obsoletes or updates. 🫶
Status of This Memo 💅
so this bit is the official vibe check. it defines an Experimental Protocol for the Internet community, and it does not specify an Internet standard of any kind 🧪 they're literally asking for discussion and suggestions for improvement, so feedback is welcome 🫶 and distribution of this memo is unlimited 🌈
Abstract 🦋
this doc describes the Triple DES-CBC security transform for the IP Encapsulating Security Payload (ESP). that's the whole plot 💜
Table of Contents 📚
1. Introduction .......................................... 2
1.1 Keys ............................................ 2
1.2 Initialization Vector ........................... 2
1.3 Data Size ....................................... 3
1.4 Performance ..................................... 3
2. Payload Format ........................................ 4
3. Algorithm ............................................. 6
3.1 Encryption ...................................... 6
3.2 Decryption ...................................... 7
SECURITY CONSIDERATIONS ...................................... 7
ACKNOWLEDGEMENTS ............................................. 8
REFERENCES ................................................... 9
AUTHOR'S ADDRESS ............................................. 111. Introduction ✨
okay so the Encapsulating Security Payload (ESP) [RFC-1827] gives confidentiality for IP datagrams by encrypting the payload data that needs protecting 🔐 this spec describes how ESP uses a variant of the Cipher Block Chaining (CBC) mode of the US Data Encryption Standard (DES) algorithm [FIPS-46, FIPS-46-1, FIPS-74, FIPS-81] 💅 that variant is called Triple DES (3DES), and it processes each block of the plaintext three times, each time with a different key [Tuchman79] 🔑
this doc assumes you already know the related document "Security Architecture for the Internet Protocol" [RFC-1825]. it's the overall security plan for IP and it's important background for this spec 📖
1.1. Keys 🔑
the secret 3DES key shared between the communicating parties is effectively 168-bits long 🤯 it's made of three independent 56-bit quantities used by the DES algorithm. each of the three 56-bit subkeys is stored as a 64-bit (eight octet) quantity, and the least significant bit of each octet is used as a parity bit 💖
1.2. Initialization Vector 🌸
this mode of 3DES requires an Initialization Vector (IV) that is eight octets long 🎀
each datagram carries its own IV. including the IV in every datagram means each received datagram can still be decrypted even when other datagrams get dropped or re-ordered in transit 🦋 how the IV values get selected is implementation dependent 🤷♀️
Notes:
- a common, acceptable technique is just a counter that starts at a randomly chosen value. it's an easy way to avoid repetition and it's robust enough for practical use, BUT cryptanalysis may use the rare serendipitous occurrence when a corresponding bit position in the first DES block increments in exactly the same fashion 👀
- other implementations are unpredictable, usually through a pseudo-random number generator. Care should be taken that the periodicity of the number generator is long enough to prevent repetition during the lifetime of the session key 🌈
1.3. Data Size 📏
3DES operates on blocks of eight octets, so padding after the end of the unencrypted payload data is often needed 🧩
input and output come out the same number of octets, which makes in-place encryption and decryption easier ✨ on receipt, if the length of the data to be decrypted is not an integral multiple of eight octets, an error is indicated, as described in [RFC-1825] 💀
1.4. Performance 🏎️
three DES-CBC implementations may be pipelined in series to get parallel computation. at the time of writing, at least one hardware implementation could encrypt or decrypt at about 1 Gbps [Schneier94, p. 231] 🔥
2. Payload Format 📦
here's the layout. it's giving packet diagram energy 🧁
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Initialization Vector (IV) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Payload Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Padding | Pad Length | Payload Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Security Parameters Index (SPI)
a 32-bit value that identifies the Security Parameters for this datagram. the value MUST NOT be zero 🙅♀️
Initialization Vector (IV)
the size of this field is variable, but it's constant for all 3DES datagrams with the same SPI and IP Destination. octets are sent in network order (most significant octet first) [RFC-1700] 🧭
the size MUST be a multiple of 32-bits. sizes of 32 and 64 bits are required to be supported. the use of other sizes is beyond the scope of this spec. the size is expected to be indicated by the key management mechanism 🔑
when the size is 32-bits, a 64-bit IV is formed from the 32-bit value followed by (concatenated with) the bit-wise complement of the 32-bit value. this field size is the most common, since it lines up the Payload Data for both 32-bit and 64-bit processing ✨
All conformant implementations MUST also correctly process a 64-bit field size. this gives strict compatibility with existing hardware implementations 💪
it is the intent that the value not repeat during the lifetime of the encryption session key. even when a full 64-bit IV is used, the session key SHOULD be changed at least as frequently as 2**32 datagrams. 🚨
Payload Data
the size of this field is variable. before encryption and after decryption, this field begins with the IP Protocol/Payload header specified in the Payload Type field. note that with IP-in-IP encapsulation (Payload Type 4), this will be another IP header 🪆
Padding
the size of this field is variable. before encryption, it's filled with unspecified, implementation dependent (preferably random) values, to align the Pad Length and Payload Type fields at an eight octet boundary 🌸
after decryption, it MUST be ignored 🫥
Pad Length
this field indicates the size of the Padding field. it does not include the Pad Length and Payload Type fields. the value typically ranges from 0 to 7, but may be up to 255 to permit hiding of the actual data length 🙈
this field is opaque. that means the value is set before encryption and only examined after decryption 🔒
Payload Type
this field indicates the contents of the Payload Data field, using the IP Protocol/Payload value. the up-to-date values are specified in the most recent "Assigned Numbers" [RFC-1700] 📒
this field is opaque too. the value is set before encryption and only examined after decryption 🔒
for example, when encrypting an entire IP datagram (Tunnel-Mode), this field will contain the value 4, which indicates IP-in-IP encapsulation 🎁
to be continued! 🫶 part 2 covers Section 3 (the Algorithm), the Security Considerations, Acknowledgements, References, and the Author's Address 💖
Security Considerations 🔐
okay bestie, this part is SERIOUS 💀 but it's also kind of iconic because it's basically the security group chat's big warning 📣. Users need to understand that the security this spec gives you depends totally on how strong Triple DES is, whether the algorithm is implemented correctly, how secure the key management is (and how well it's implemented), how strong the key is [CN94], and whether every participating node implements everything correctly 🫶.
Applications might want to avoid weak keys for any of the three DES rounds 🗝️. The odds of randomly picking one are low, but low isn't zero [Schneier94, p. 233] 😬.
It was once thought that DES might be a group, but it has been shown that it isn't [CW92] 🤯. Because DES isn't a group, stacking multiple rounds of DES doesn't do the same thing as just using DES with a different key 🔄.
Here's the plot twist 🌀: Triple DES with independent keys is NOT as hard to brute-force as a cryptosystem with three times the keylength, even though you'd naively expect it to be. A space/time tradeoff has been shown that can brute-force break triple block encryptions in the time you'd naively expect for double encryption [MH81] 💔.
2DES can be broken with a meet-in-the-middle attack, and that doesn't take much more complexity than breaking DES already takes [ibid] 🙃. So 3DES with independent keys is actually needed to get this level of security 💅. There's also an attack on 3DES using two independent keys that's somewhat (sixteen times) faster than any known attack on independent keys, and it has been demonstrated [OW91] ⚡.
The cut and paste attack described by [Bell95] takes advantage of how all Cipher Block Chaining algorithms work 🧩. When a block gets damaged in transit, decryption garbles that block and the one after it, but every block after that decrypts correctly 🤷♀️. If an attacker legitimately has the same key, they can use this to insert or replay previously encrypted data belonging to other users of the same engine, which can reveal the plaintext 👀. The usual transport checksum (ICMP, TCP, or UDP) can catch this attack, but on its own it isn't considered cryptographically strong 🥀. In this situation, you need user- or connection-oriented integrity checking [RFC-1826] 🛡️.
It's widely believed that 3DES is a lot stronger than DES because it's harder to brute-force, but real cryptanalysis of 3DES might not use brute force at all 🧠. It could instead use variants of differential [BS93] or linear [Matsui94] cryptanalysis 🔍. Also, no encryption algorithm is permanently safe from brute force, because computers keep getting faster ⏩🖥️.
As with every cryptosystem, if you're running applications where a security breach would be seriously risky, you need to keep an eye on developments in cryptography (especially cryptanalysis) and be ready to switch to other transforms if 3DES turns out to be weak 🚨💜.
Acknowledgements 🌸
Some of the text in this specification came from work by Randall Atkinson for the SIP, SIPP, and IPv6 Working Groups 🙌.
Comments should be submitted to the ipsec@ans.net mailing list 📬.
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.
[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.
Author's Address 💌
Questions about this memo can also be directed to:
Phil Karn
Qualcomm, Inc.
6455 Lusk Blvd.
San Diego, California 92121-2779
karn@unix.ka9q.ampr.org
Perry Metzger
Piermont Information Systems Inc.
160 Cabrini Blvd., Suite #2
New York, NY 10033
perry@piermont.com
William Allen Simpson
Daydreamer
Computer Systems Consulting Services
1384 Fontaine
Madison Heights, Michigan 48071
Bill.Simpson@um.cc.umich.edu
bsimpson@MorningStar.com📦 where this page comes from
- ietf: rfc1851 1995-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms