As per Relevance of the word security, we have this rfc below:
Network Working Group P.
Request for Comments: 1829
Category: Standards Track P.
W.
August 1995
The ESP DES-CBC
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
This document describes the DES-CBC security transform for the
Encapsulating Security Payload (ESP).
Table of
1. Introduction .......................................... 1
1.1 Keys ............................................ 1
1.2 Initialization Vector ........................... 1
1.3 Data Size ....................................... 2
1.4 Performance ..................................... 2
2. Payload Format ........................................ 3
3. Algorithm ............................................. 5
3.1 Encryption ...................................... 5
3.2 Decryption ...................................... 5
SECURITY CONSIDERATIONS ...................................... 6
ACKNOWLEDGEMENTS ............................................. 7
REFERENCES ................................................... 8
AUTHOR'S ADDRESS ............................................. 10
Karn, Metzger & Simpson Standards Track [Page i
RFC 1829 ESP DES-CBC August 1995
1.
The Encapsulating Security Payload (ESP) [RFC-1827]
confidentiality for IP datagrams by encrypting the payload data to
protected. This specification describes the ESP use of the
Block Chaining (CBC) mode of the US Data Encryption Standard (DES
algorithm [FIPS-46, FIPS-46-1, FIPS-74, FIPS-81].
All implementations that claim conformance or compliance with
Encapsulating Security Payload specification MUST implement
DES-CBC transform
This document assumes that the reader is familiar with the
document "Security Architecture for the Internet Protocol
[RFC-1825], which defines the overall security plan for IP,
provides important background for this specification
1.1.
The secret DES key shared between the communicating parties is
octets in length. This key consists of a 56-bit quantity used by
DES algorithm. The 56-bit key is stored as a 64-bit (eight octet
quantity, with the least significant bit of each octet used as
parity bit
1.2. Initialization
This mode of DES requires an Initialization Vector (IV) that is
octets in length
Each datagram contains its own IV. Including the IV in each
ensures that decryption of each received datagram can be performed
even when other datagrams are dropped, or datagrams are re-ordered
transit
The method for selection of IV values is implementation dependent
Notes
A common acceptable technique is simply a counter, beginning
a randomly chosen value. While this provides an easy method
preventing repetition, and is sufficiently robust for
use, cryptanalysis may use the rare serendipitous occurrence
a corresponding bit position in the first DES block increments
exactly the same fashion
Karn, Metzger & Simpson Standards Track [Page 1]
RFC 1829 ESP DES-CBC August 1995
Other implementations exhibit unpredictability, usually through
pseudo-random number generator. Care should be taken that
periodicity of the number generator is long enough to
repetition during the lifetime of the session key
1.3. Data
The DES algorithm operates on blocks of eight octets. This
requires padding after the end of the unencrypted payload data
Both input and output result in the same number of octets,
facilitates in-place encryption and decryption
On receipt, if the length of the data to be decrypted is not
integral multiple of eight octets, then an error is indicated,
described in [RFC-1825].
1.4.
At the time of writing, at least one hardware implementation
encrypt or decrypt at about 1 Gbps [Schneier94, p. 231].
Karn, Metzger & Simpson Standards Track [Page 2]
RFC 1829 ESP DES-CBC August 1995
2. Payload
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
datagram. The value MUST NOT be zero
Initialization Vector (IV
The size of this field is variable, although it is constant
all DES-CBC datagrams of the same SPI and IP Destination.
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
are required to be supported. The use of other sizes is
the scope of this specification. The size is expected to
indicated by the key management mechanism
When the size is 32-bits, a 64-bit IV is formed from the 32-
value followed by (concatenated with) the bit-wise complement
the 32-bit value. This field size is most common, as it
the Payload Data for both 32-bit and 64-bit processing
All conformant implementations MUST also correctly process
64-bit field size. This provides strict compatibility
existing hardware implementations
It is the intent that the value not repeat during the
of the encryption session key. Even when a full 64-bit IV
used, the session key SHOULD be changed at least as
as 2**32 datagrams
Karn, Metzger & Simpson Standards Track [Page 3]
RFC 1829 ESP DES-CBC August 1995
Payload
The size of this field is variable
Prior to encryption and after decryption, this field begins
the IP Protocol/Payload header specified in the Payload
field. Note that in the case of IP-in-IP encapsulation (
Type 4), this will be another IP header
The size of this field is variable
Prior to encryption, it is filled with unspecified
dependent (preferably random) values, to align the Pad Length
Payload Type fields at an eight octet boundary
After decryption, it MUST be ignored
Pad
This field indicates the size of the Padding field. It does
include the Pad Length and Payload Type fields. The
typically ranges from 0 to 7, but may be up to 255 to
hiding of the actual data length
This field is opaque. That is, the value is set prior
encryption, and is examined only after decryption
Payload
This field indicates the contents of the Payload Data field,
the IP Protocol/Payload value. Up-to-date values of the
Protocol/Payload are specified in the most recent "
Numbers" [RFC-1700].
This field is opaque. That is, the value is set prior
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
IP-in-IP encapsulation
Karn, Metzger & Simpson Standards Track [Page 4]
RFC 1829 ESP DES-CBC August 1995
3.
In DES-CBC, the base DES encryption function is applied to the XOR
each plaintext block with the previous ciphertext block to yield
ciphertext for the current block. This provides
re-synchronization when datagrams are lost
For more explanation and implementation information for DES,
[Schneier94].
3.1.
Append zero or more octets of (preferably random) padding to
plaintext, to make its modulo 8 length equal to 6. For example,
the plaintext length is 41, 5 octets of padding are added
Append a Pad Length octet containing the number of padding
just added
Append a Payload Type octet containing the IP Protocol/Payload
which identifies the protocol header that begins the payload
Provide an Initialization Vector (IV) of the size indicated by
SPI
Encrypt the payload with DES in CBC mode, producing a ciphertext
the same length
Octets are mapped to DES blocks in network order (most
octet first) [RFC-1700]. Octet 0 (modulo 8) of the
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,
the indicated SPI, IV, and payload
The Total/Payload Length in the encapsulating IP Header reflects
length of the encrypted data, plus the SPI, IV, padding, Pad Length
and Payload Type octets
3.2.
First, the SPI field is removed and examined. This is used as
index into the local Security Parameter table to find the
Karn, Metzger & Simpson Standards Track [Page 5]
RFC 1829 ESP DES-CBC August 1995
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
constructed
The encrypted part of the payload is decrypted using DES in the
mode
The Payload Type is removed and examined. If it is unrecognized,
payload is discarded with an appropriate ICMP message
The Pad Length is removed and examined. The specified number of
octets are removed from the end of the decrypted payload, and the
Total/Payload Length is adjusted accordingly
The IP Header(s) and the remaining portion of the decrypted
are passed to the protocol receive routine specified by the
Type field
Security
Users need to understand that the quality of the security provided
this specification depends completely on the strength of the
algorithm, the correctness of that algorithm's implementation,
security of the key management mechanism and its implementation,
strength of the key [CN94], and upon the correctness of
implementations in all of the participating nodes
Among other considerations, applications may wish to take care not
select weak keys, although the odds of picking one at random are
[Schneier94, p 233].
The cut and paste attack described by [Bell95] exploits the nature
all Cipher Block Chaining algorithms. When a block is damaged
transmission, on decryption both it and the following block will
garbled by the decryption process, but all subsequent blocks will
decrypted correctly. If an attacker has legitimate access to
same key, this feature can be used to insert or replay
encrypted data of other users of the same engine, revealing
plaintext. The usual (ICMP, TCP, UDP) transport checksum can
this attack, but on its own is not considered
strong. In this situation, user or connection oriented
checking is needed [RFC-1826].
At the time of writing of this document, [BS93] demonstrated
Karn, Metzger & Simpson Standards Track [Page 6]
RFC 1829 ESP DES-CBC August 1995
differential cryptanalysis based chosen-plaintext attack
2^47 plaintext-ciphertext pairs, and [Matsui94] demonstrated a
cryptanalysis based known-plaintext attack requiring only 2^43
plaintext-ciphertext pairs. Although these attacks are
considered practical, they must be taken into account
More disturbingly, [Weiner94] has shown the design of a DES
machine costing $1 Million that can crack one key every 3.5 hours
This is an extremely practical attack
One or two blocks of known plaintext suffice to recover a DES key
Because IP datagrams typically begin with a block of known and/
guessable header text, frequent key changes will not protect
this attack
It is suggested that DES is not a good encryption algorithm for
protection of even moderate value information in the face of
equipment. Triple DES is probably a better choice for such purposes
However, despite these potential risks, the level of privacy
by use of ESP DES-CBC in the Internet environment is far greater
sending the datagram as cleartext
This document was reviewed by the IP Security Working Group of
Internet Engineering Task Force (IETF). Comments should be
to the ipsec@ans.net mailing list
Some of the text of this specification was derived from work
Randall Atkinson for the SIP, SIPP, and IPv6 Working Groups
The use of DES for confidentiality is closely modeled on the
done for SNMPv2 [RFC-1446].
Steve Bellovin, Steve Deering, Karl Fox, Charles Lynn, Craig Metz
Dave Mihelcic and Jeffrey Schiller provided useful critiques
earlier versions of this draft
Karn, Metzger & Simpson Standards Track [Page 7]
RFC 1829 ESP DES-CBC August 1995
[Bell95] Bellovin, S., "An Issue With DES-CBC When Used
Strong Integrity", Proceedings of the 32nd IETF, Danvers
MA, April 1995.
[BS93] Biham, E., and Shamir, A., "Differential Cryptanalysis
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.
[FIPS-46]
US National Bureau of Standards, "Data Encryption Standard",
Federal Information Processing Standard (FIPS)
46, January 1977.
[FIPS-46-1]
US National Bureau of Standards, "Data Encryption Standard",
Federal Information Processing Standard (FIPS)
46-1, January 1988.
[FIPS-74]
US National Bureau of Standards, "Guidelines
Implementing and Using the Data Encryption Standard",
Federal Information Processing Standard (FIPS)
74, April 1981.
[FIPS-81]
US National Bureau of Standards, "DES Modes of Operation
Federal Information Processing Standard (FIPS)
81, December 1980.
[Matsui94]
Matsui, M., "Linear Cryptanalysis method dor DES Cipher,"
Advances in Cryptology -- Eurocrypt '93 Proceedings, Berlin
Springer-Verlag, 1994.
[RFC-1446]
Galvin, J., and McCloghrie, K., "Security Protocols
Version 2 of the Simple Network Management
(SNMPv2)", RFC-1446, DDN Network Information Center,
1993.
[RFC-1700]
Reynolds, J., and Postel, J., "Assigned Numbers", STD 2,
Karn, Metzger & Simpson Standards Track [Page 8]
RFC 1829 ESP DES-CBC August 1995
RFC-1700, USC/Information Sciences Institute, October 1994.
[RFC-1800]
Postel, J., "Internet Official Protocol Standards", STD 1,
RFC-1800, USC/Information Sciences Institute, July 1995.
[RFC-1825]
Atkinson, R., "Security Architecture for the
Protocol", RFC-1825, Naval Research Laboratory, July 1995.
[RFC-1826]
Atkinson, R., "IP Authentication Header", RFC-1826,
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,
York, NY, 1994. ISBN 0-471-59756-2
[Weiner94]
Wiener, M.J., "Efficient DES Key Search", School of
Science, Carleton University, Ottawa, Canada, TR-244,
1994. Presented at the Rump Session of Crypto '93.
Karn, Metzger & Simpson Standards Track [Page 9]
RFC 1829 ESP DES-CBC August 1995
Author's
Questions about this memo can also be directed to
Phil
Qualcomm, Inc
6455 Lusk Blvd
San Diego, California 92121-2779
karn@unix.ka9q.ampr.
Perry
Piermont Information Systems Inc
160 Cabrini Blvd., Suite #2
New York, NY 10033
perry@piermont.
William Allen
Computer Systems Consulting
1384
Madison Heights, Michigan 48071
Bill.Simpson@um.cc.umich.
bsimpson@MorningStar.
Karn, Metzger & Simpson Standards Track [Page 10]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
