The ESP Triple DES Transform
RFC 1851
Document | Type |
RFC - Experimental
(September 1995; No errata)
Was draft-metzger-esp-3des-cbc (individual)
|
|
---|---|---|---|
Authors | Phil Karn , William Simpson , Perry Metzger | ||
Last updated | 2013-03-02 | ||
Stream | Legacy | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | Legacy state | (None) | |
Consensus Boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | RFC 1851 (Experimental) | |
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
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 Karn, et al Experimental [Page 1] RFC 1851 ESP 3DES September 1995 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. Karn, et al Experimental [Page 2] RFC 1851 ESP 3DES September 1995 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 hardwareShow full document text