The ESP Triple DES Transform
How IPsec's ESP encrypts packets by running the DES cipher three times in a row with three keys.
Karn, P., Metzger, P., and W. Simpson, "The ESP Triple DES Transform", RFC 1851, DOI 10.17487/RFC1851, September 1995, <https://www.rfc-editor.org/info/rfc1851>.
@misc{rfc1851,
series = {Request for Comments},
number = 1851,
howpublished = {RFC 1851},
publisher = {RFC Editor},
doi = {10.17487/RFC1851},
url = {https://www.rfc-editor.org/info/rfc1851},
author = {P. Karn and P. Metzger and W. Simpson},
title = {{The ESP Triple DES Transform}},
pagetotal = 11,
year = 1995,
month = sep,
} RFC text
Contents
Network Working Group P. Karn
Request for Comments: 1851 Qualcomm
Category: Experimental P. Metzger
Piermont
W. Simpson
Daydreamer
September 1995
The ESP Triple DES Transform
Status of this Memo
This document defines an Experimental Protocol for the Internet
community. This does not specify an Internet standard of any kind.
Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
Abstract
This document describes the Triple DES-CBC security transform for the
IP Encapsulating Security Payload (ESP).
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 ............................................. 11
1. Introduction
The Encapsulating Security Payload (ESP) [RFC-1827] provides
confidentiality for IP datagrams by encrypting the payload data to be
protected. This specification describes the ESP use of a variant of
of the Cipher Block Chaining (CBC) mode of the US Data Encryption
Standard (DES) algorithm [FIPS-46, FIPS-46-1, FIPS-74, FIPS-81].
This variant, known as Triple DES (3DES), processes each block of the
plaintext three times, each time with a different key [Tuchman79].
This document assumes that the reader is familiar with the related
document "Security Architecture for the Internet Protocol" [RFC-
1825], which defines the overall security plan for IP, and provides
important background for this specification.
1.1. Keys
The secret 3DES key shared between the communicating parties is
effectively 168-bits long. This key consists 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, with the
least significant bit of each octet used as a parity bit.
1.2. Initialization Vector
This mode of 3DES requires an Initialization Vector (IV) that is
eight octets in length.
Each datagram contains its own IV. Including the IV in each datagram
ensures that decryption of each received datagram can be performed,
even when other datagrams are dropped, or datagrams are re-ordered in
transit.
The method for selection of IV values is implementation dependent.
Notes:
A common acceptable technique is simply a counter, beginning with
a randomly chosen value. While this provides an easy method for
preventing repetition, and is sufficiently robust for practical
use, 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 exhibit unpredictability, 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
The 3DES algorithm operates on blocks of eight octets. This often
requires padding after the end of the unencrypted payload data.
Both input and output result in the same number of octets, which
facilitates in-place encryption and decryption.
On receipt, if the length of the data to be decrypted is not an
integral multiple of eight octets, then an error is indicated, as
described in [RFC-1825].
1.4. Performance
Three DES-CBC implementations may be pipelined in series to provide
parallel computation. At the time of writing, at least one hardware
implementation can encrypt or decrypt at about 1 Gbps [Schneier94, p.
231].
2. Payload Format
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Initialization Vector (IV) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Payload Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Padding | Pad Length | Payload Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Security Parameters Index (SPI)
A 32-bit value identifying the Security Parameters for this
datagram. The value MUST NOT be zero.
Initialization Vector (IV)
The size of this field is variable, although it is constant for
all 3DES datagrams of 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 specification. 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 most common, as it aligns
the Payload Data for both 32-bit and 64-bit processing.
All conformant implementations MUST also correctly process a 64-
bit field size. This provides 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.
Prior to encryption and after decryption, this field begins with
the IP Protocol/Payload header specified in the Payload Type
field. Note that in the case of IP-in-IP encapsulation (Payload
Type 4), this will be another IP header.
Padding
The size of this field is variable.
Prior to encryption, it is 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 is, the value is set prior to
encryption, and is examined only after decryption.
Payload Type
This field indicates the contents of the Payload Data field, using
the IP Protocol/Payload value. Up-to-date values of the IP
Protocol/Payload are specified in the most recent "Assigned
Numbers" [RFC-1700].
This field is opaque. That is, the value is set prior to
encryption, and is examined only 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.
3. Algorithm
The 3DES algorithm is a simple variant on the DES-CBC algorithm. The
DES function is replaced by three rounds of that function, an
encryption followed by a decryption followed by an encryption, each
with independant keys, k1, k2 and k3.
Note that when all three keys (k1, k2 and k3) are the same, 3DES is
equivalent to DES-CBC. This property allows the 3DES hardware
implementations to operate in DES mode without modification.
For more explanation and implementation information for Triple DES,
see [Schneier94].
3.1. Encryption
Append zero or more octets of (preferably random) padding to the
plaintext, to make its modulo 8 length equal to 6. For example, if
the plaintext length is 41, 5 octets of padding are added.
Append a Pad Length octet containing the number of padding octets
just added.
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.
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
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 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
AI ELI5
On this page
§1Triple DES for ESP
The Encapsulating Security Payload (ESP, RFC 1827) provides confidentiality for IP datagrams by encrypting the payload data. This memo specifies how ESP uses a variant of the Cipher Block Chaining (CBC) mode of the US Data Encryption Standard (DES). The variant, Triple DES (3DES), processes each block of the plaintext three times, each time with a different key.
The reader is expected to know the Security Architecture for the Internet Protocol (RFC 1825), which defines the overall security plan for IP.
Regular DES locks the message once. Triple DES locks it three times with three different keys.
§1.1Keys, IVs and Block Size
The shared secret 3DES key is effectively 168 bits long. It consists of three independent 56-bit quantities, each stored as a 64-bit (eight octet) value whose least significant bit in each octet is a parity bit.
This mode needs an Initialization Vector (IV) of eight octets. Each datagram carries its own IV, so a datagram can be decrypted even when others are dropped or reordered. How IV values are chosen is implementation dependent. A counter starting at a random value is called acceptable, but the notes warn that cryptanalysis may exploit it, and that a pseudo-random generator needs a period long enough to avoid repetition during the session key's lifetime.
3DES works on blocks of eight octets, which often requires padding. Input and output have the same length, which allows in-place work. If the data to decrypt is not a multiple of eight octets, an error is indicated as described in RFC 1825. Three DES-CBC implementations can be pipelined in series, and the RFC notes that at least one hardware implementation could process about 1 Gbps at the time of writing.
The three keys together make one big secret. Each message also carries a small random starter note so that scrambling the same words twice looks different.
§2The ESP Payload Format
The ESP payload holds these fields in order: a 32-bit Security Parameters Index (SPI), the Initialization Vector, the Payload Data, Padding, a Pad Length octet and a Payload Type octet.
- SPI: identifies the Security Parameters for the datagram and MUST NOT be zero.
- IV: variable size, constant for all 3DES datagrams of the same SPI and IP destination, and a multiple of 32 bits. Sizes of 32 and 64 bits MUST be supported. With a 32-bit IV, the 64-bit IV is the 32-bit value followed by its bit-wise complement. The session key SHOULD be changed at least as often as 2**32 datagrams, even with a full 64-bit IV.
- Payload Data: begins with the protocol header named by Payload Type. For IP-in-IP encapsulation (Payload Type 4) that is another IP header.
- Padding: filled with implementation dependent, preferably random, values to align Pad Length and Payload Type at an eight octet boundary. It MUST be ignored after decryption.
- Pad Length: the size of the Padding field, typically 0 to 7 but up to 255, which can hide the real data length.
- Payload Type: the IP Protocol/Payload value of the contents. In tunnel mode it is 4.
Pad Length and Payload Type are opaque: they are set before encryption and examined only after decryption.
Every package has a label saying which agreement it follows, a starter note, the secret contents, some filler to make it fit, and a note saying how much filler there is and what is inside.
§3Encryption and Decryption Steps
3DES here is a variant of DES-CBC where the DES function is replaced by an encryption, then a decryption, then an encryption, with independent keys k1, k2 and k3. When all three keys are the same, 3DES is equivalent to DES-CBC, so 3DES hardware can run in DES mode unchanged.
To encrypt: append padding so the length modulo 8 equals 6 (a 41 octet plaintext gets 5 octets of padding), append the Pad Length octet, append the Payload Type octet, provide an IV of the size indicated by the SPI, and encrypt with Triple DES in EDE mode. Then build the IP datagram with the SPI, IV and encrypted payload. The IP length reflects the encrypted data plus the SPI, IV, padding, Pad Length and Payload Type octets.
To decrypt: remove the SPI and use it to look up the negotiated parameters and key. Remove the IV, whose size the negotiation determines. Decrypt (the RFC calls this DED mode). Remove and check the Payload Type, and if it is unrecognized, discard the payload with an appropriate ICMP message. Remove the Pad Length and that many pad octets, adjust the IP length, and pass the result to the protocol named by Payload Type.
To send, add filler and two notes, then lock it three times. To receive, unlock it three times, read the notes, throw away the filler and hand the contents to whoever it is for.
§4Security Considerations
The quality of the security depends entirely on the strength of Triple DES, the correctness of its implementation, the security of key management, the strength of the key, and correct implementations in all participating nodes. Applications may wish to avoid weak keys for any of the three DES rounds, though the odds of picking one at random are low.
DES has been shown not to be a group, so combining several rounds is not equivalent to one DES with a different key. Triple DES with independent keys is not as hard to brute-force as a cipher with three times the key length, because a space/time tradeoff breaks triple block encryption in the time naively expected for double encryption. Double DES falls to a meet-in-the-middle attack, so 3DES with independent keys is needed for this level of security. An attack on two-key 3DES is sixteen times faster than any known for independent keys.
CBC also permits a cut and paste attack: a damaged block garbles itself and the next block only, so an attacker with legitimate access to the same key may insert or replay data from other users. Ordinary transport checksums can detect this but are not cryptographically strong, so user or connection oriented integrity checking is needed (RFC 1826). Cryptanalysis may not use brute force at all, and the RFC advises watching developments and switching transforms if 3DES proves weak.
Three locks are good but not three times as good. Someone clever might also swap pieces of messages around, so you need a separate check that nothing was tampered with.