As per Relevance of the word security, we have this rfc below:
Network Working Group C.
Request for Comments: 2405 Cisco Systems, Inc
Category: Standards Track N.
Bay Networks, Inc
November 1998
The ESP DES-CBC Cipher
With Explicit
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
Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
This document describes the use of the DES Cipher algorithm in
Block Chaining Mode, with an explicit IV, as a
mechanism within the context of the IPSec Encapsulating
Payload (ESP).
1.
This document describes the use of the DES Cipher algorithm in
Block Chaining Mode as a confidentiality mechanism within the
of the Encapsulating Security Payload
DES is a symmetric block cipher algorithm. The algorithm is
in [FIPS-46-2][FIPS-74][FIPS-81]. [Schneier96] provides a
description of Cipher Block Chaining Mode, a mode which is
to several encryption algorithms
As specified in this memo, DES-CBC is not an
mechanism. [Although DES-MAC, described in [Schneier96] amongst
places, does provide authentication, DES-MAC is not discussed here.]
For further information on how the various pieces of ESP fit
to provide security services, refer to [ESP] and [road].
Madson & Doraswamy Standards Track [Page 1]
RFC 2405 The ESP DES-CBC Cipher Algorithm November 1998
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in [RFC-2119].
2. Algorithm and
DES-CBC is a symmetric secret-key block algorithm. It has a
size of 64 bits
[FIPS-46-2][FIPS-74] and [FIPS-81] describe the DES algorithm,
[Schneier96] provides a good description of CBC mode
2.1
Phil Karn has tuned DES-CBC software to achieve 10.45 Mbps with a 90
MHz Pentium, scaling to 15.9 Mbps with a 133 MHz Pentium. Other
speed estimates may be found in [Schneier96].
3. ESP
DES-CBC requires an explicit Initialization Vector (IV) of 8
(64 bits). This IV immediately precedes the protected (encrypted
payload. The IV MUST be a random value
Including the IV in each datagram ensures that decryption of
received datagram can be performed, even when some datagrams
dropped, or datagrams are re-ordered in transit
Implementation note
Common practice is to use random data for the first IV and
last 8 octets of encrypted data from an encryption process as
IV for the next encryption process; this logically extends the
across the packets. It also has the advantage of limiting
leakage of information from the random number genrator. No
which mechnism is used, the receiver MUST NOT assume any
for this value, other than that it is an IV
To avoid ECB encryption of very similar plaintext blocks
different packets, implementations MUST NOT use a counter or
low-Hamming distance source for IVs
The payload field, as defined in [ESP], is broken down according
the following diagram
Madson & Doraswamy Standards Track [Page 2]
RFC 2405 The ESP DES-CBC Cipher Algorithm November 1998
+---------------+---------------+---------------+---------------+
| |
+ Initialization Vector (IV) +
| |
+---------------+---------------+---------------+---------------+
| |
~ Encrypted Payload (variable length) ~
| |
+---------------------------------------------------------------+
1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
3.1 Block Size and
The DES-CBC algorithm described in this document MUST use a
size of 8 octets (64 bits).
When padding is required, it MUST be done according to
conventions specified in [ESP].
4. Key
DES-CBC is a symmetric secret key algorithm. The key size is 64-bits
[It is commonly known as a 56-bit key as the key has 56
bits; the least significant bit in every byte is the parity bit.]
[arch] describes the general mechanism to derive keying material
the ESP transform. The derivation of the key from some amount
keying material does not differ between the manually-
automatically-keyed security associations
This mechanism MUST derive a 64-bit key value for use by this cipher
The mechanism will derive raw key values, the derivation
itself is not responsible for handling parity or weak key checks
Weak key checks SHOULD be performed. If such a key is found, the
SHOULD be rejected and a new SA requested
Implementation note
If an implementation chooses to do weak key checking, it
recognize that the known weak keys [FIPS74] have been adjusted
parity. Otherwise the handling of parity is a local issue
A strong pseudo-random function MUST be used to generate the
key. For a discussion on this topic, reference [RFC1750].
Madson & Doraswamy Standards Track [Page 3]
RFC 2405 The ESP DES-CBC Cipher Algorithm November 1998
4.1 Weak
DES has 16 known weak keys, including so-called semi-weak keys.
list of weak keys can be found in [FIPS74].
4.2 Key
[Blaze96] discusses the costs and key recovery time for brute
attacks. It presents various combinations of total cost/time
recover a key/cost per key recovered for 40-bit and 56-bit DES keys
based on late 1995 estimates
While a brute force search of a 56-bit DES keyspace can be
infeasable for the so-called casual hacker, who is simply using
CPU cycles or other low-cost resources, it is within reach of
willing to spend a bit more money
For example, for a cost of $300,000, a 56-bit DES key can
recovered in an average of 19 days using off-the-shelf technology
in only 3 hours using a custom developed chip
It should be noted that there are other attacks which can recover
key faster, that brute force attacks are considered the "worst case",
although the easiest to implement
[Wiener94] also discusses a $1M machine which can break a DES key
3.5 hours (1993 estimates), using a known-plaintext attack.
discussed in the Security Considerations section, a known
attack is reasonably likely
It should also be noted that over time, the total and average
costs as well as the average key recovery time will continue to drop
While the above does not provide specific recommendations for
lifetime, it does reinforce the point that for a given
the desired key lifetime is dependent upon the perceived threat (
educated guess as to the amount of resources available to
attacker) relative to the worth of the data to be protected
While there are no recommendations for volume-based lifetimes
here, it shoud be noted that given sufficient volume there is
increased probabilty that known plaintext can be accumulated
5. Interaction with Authentication
As of this writing, there are no known issues which preclude the
of the DES-CBC algorithm with any specific authentication algorithm
Madson & Doraswamy Standards Track [Page 4]
RFC 2405 The ESP DES-CBC Cipher Algorithm November 1998
6. Security
[Much of this section was originally written by William Allen
and Perry Metzger.]
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 Security Association management mechanism and
implementation, the strength of the key [CN94], and upon
correctness of the implementations in all of the participating nodes
[Bell95] and [Bell96] describe a cut and paste splicing attack
applies to all Cipher Block Chaining algorithms. This attack can
addressed with the use of an authentication mechanism
The use of the cipher mechanism without any
authentication mechanism is strongly discouraged. This cipher can
used in an ESP transform that also includes authentication; it
also be used in an ESP transform that doesn't include
provided there is an companion AH header. Refer to [ESP], [AH],
[arch], and [road] for more details
When the default ESP padding is used, the padding bytes have
predictable value. They provide a small measure of tamper
on their own block and the previous block in CBC mode. This makes
somewhat harder to perform splicing attacks, and avoids a
covert channel. This small amount of known plaintext does not
any problems for modern ciphers
At the time of writing of this document, [BS93] demonstrated
differential cryptanalysis based chosen-plaintext attack
2^47 plaintext-ciphertext pairs, where the size of a pair is the
of a DES block (64 bits). [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, [Wiener94] 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
Madson & Doraswamy Standards Track [Page 5]
RFC 2405 The ESP DES-CBC Cipher Algorithm November 1998
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
The case for using random values for IVs has been refined with
following summary provided by Steve Bellovin. Refer to [Bell97]
further information
"The problem arises if you use a counter as an IV, or some
source with a low Hamming distance between successive IVs,
encryption in CBC mode. In CBC mode, the "effective plaintext
for an encryption is the XOR of the actual plaintext and
ciphertext of the preceeding block. Normally, that's a
value, which means that the effective plaintext is quite random
That's good, because many blocks of actual plaintext don't
very much from packet to packet, either
For the first block of plaintext, though, the IV takes the
of the previous block of ciphertext. If the IV doesn't
much from the previous IV, and the actual plaintext block doesn'
differ much from the previous packet's, then the
plaintext won't differ much, either. This means that you
pairs of ciphertext blocks combined with plaintext blocks
differ in just a few bit positions. This can be a wedge
assorted cryptanalytic attacks."
The discussion on IVs has been updated to require that
implementation not use a low-Hamming distance source for IVs
7.
[Bell95] Bellovin, S., "An Issue With DES-CBC When Used
Strong Integrity", Presentation at the 32nd
Engineering Task Force, Danvers Massachusetts,
1995.
[Bell96] Bellovin, S., "Problem Areas for the IP
Protocols", Proceedings of the Sixth Usenix
Symposium, July 1996.
Madson & Doraswamy Standards Track [Page 6]
RFC 2405 The ESP DES-CBC Cipher Algorithm November 1998
[Bell97] Bellovin, S., "Probable Plaintext Cryptanalysis of
IP Security Protocols", Proceedings of the Symposium
Network and Distributed System Security, San Diego, CA
pp. 155-160, February 1997 (
http://www.research.att.com/~smb/papers/probtxt.{ps
pdf}).
[BS93] Biham, E., and A. Shamir, "Differential Cryptanalysis
the Data Encryption Standard", Berlin: Springer-Verlag
1993.
[Blaze96] Blaze, M., Diffie, W., Rivest, R., Schneier, B.,
Shimomura, T., Thompson, E., and M. Wiener, "Minimal
Lengths for Symmetric Ciphers to Provide
Commercial Security", currently available
http://www.bsa.org/policy/encryption/cryptographers.html
[CN94] Carroll, J.M., and S. Nudiati, "On Weak Keys and
Data: Foiling the Two Nemeses", Cryptologia, Vol. 18
No. 23 pp. 253-280, July 1994.
[FIPS-46-2] US National Bureau of Standards, "Data
Standard", Federal Information Processing
(FIPS) Publication 46-2, December 1993,
http://www.itl.nist.gov/div897/pubs/fip46-2.
(supercedes FIPS-46-1).
[FIPS-74] US National Bureau of Standards, "Guidelines
Implementing and Using the Data Encryption Standard",
Federal Information Processing Standard (FIPS
Publication 74, April 1981,
http://www.itl.nist.gov/div897/pubs/fip74.htm
[FIPS-81] US National Bureau of Standards, "DES Modes
Operation", Federal Information Processing
(FIPS) Publication 81, December 1980,
http://www.itl.nist.gov/div897/pubs/fip81.htm
[Matsui94] Matsui, M., "Linear Cryptanalysis method for
Cipher", Advances in Cryptology -- Eurocrypt '93
Proceedings, Berlin: Springer-Verlag, 1994.
[RFC-1750] Eastlake, D., Crocker, S., and J. Schiller, "
Recommendations for Security", RFC 1750, December 1994.
[RFC-2119] Bradner, S., "Key words for use in RFCs to
Requirement Levels", BCP 14, RFC 2119, March 1997.
Madson & Doraswamy Standards Track [Page 7]
RFC 2405 The ESP DES-CBC Cipher Algorithm November 1998
[Schneier96] Schneier, B., "Applied Cryptography Second Edition",
John Wiley & Sons, New York, NY, 1996. ISBN 0-471-
12845-7.
[Wiener94] Wiener, M.J., "Efficient DES Key Search", School
Computer Science, Carleton University, Ottawa, Canada
TR-244, May 1994. Presented at the Rump Session
Crypto '93. [Reprinted in "Practical Cryptography
Data Internetworks", W.Stallings, editor, IEEE
Society Press, pp.31-79 (1996). Currently available
ftp://ripem.msu.edu/pub/crypt/docs/des-key-search.ps.]
[ESP] Kent, S., and R. Atkinson, "IP Encapsulating
Payload (ESP)", RFC 2406, November 1998.
[AH] Kent, S., and R. Atkinson, "IP Authentication
(AH)", RFC 2402, November 1998.
[arch] Kent, S., and R. Atkinson, "Security Architecture
the Internet Protocol", RFC 2401, November 1998.
[road] Thayer, R., Doraswamy, N., and R. Glenn, "IP
Document Roadmap", RFC 2411, November 1998.
8.
Much of the information provided here originated with various ESP-
documents authored by Perry Metzger and William Allen Simpson
especially the Security Considerations section
This document is also derived in part from previous works by
Hughes, those people that worked with Jim on the combined DES
CBC+HMAC-MD5 ESP transforms, the ANX bakeoff participants, and
members of the IPsec working group
Thanks to Rob Glenn for assisting with the nroff formatting
Madson & Doraswamy Standards Track [Page 8]
RFC 2405 The ESP DES-CBC Cipher Algorithm November 1998
The IPSec working group can be contacted via the IPSec
group's mailing list (ipsec@tis.com) or through its chairs
Robert
International Computer Security
EMail: rgm@icsa.
Theodore Y. Ts'
Massachusetts Institute of
EMail: tytso@MIT.
9. Editors'
Cheryl
Cisco Systems, Inc
EMail: cmadson@cisco.
Naganand
Bay Networks, Inc
EMail: naganand@baynetworks.
Madson & Doraswamy Standards Track [Page 9]
RFC 2405 The ESP DES-CBC Cipher Algorithm November 1998
10. Full Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Madson & Doraswamy 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
