The ESP Triple DES Transform
RFC 1851

Document Type RFC - Experimental (September 1995; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html 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 hardware
Show full document text