idnits 2.17.1 draft-ietf-ipsec-ciph-cbc-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Weak key checks SHOULD be performed. If such a key is found, the key SHOULD be rejected and a new SA requested. Some cipher algorithms have weak keys or keys that MUST not be used due to their weak nature. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 10, 1998) is 9537 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Atkinson95' is mentioned on line 78, but not defined == Missing Reference: 'Schneier93' is mentioned on line 302, but not defined == Missing Reference: 'Schneier95' is mentioned on line 359, but not defined -- Looks like a reference, but probably isn't: '1' on line 254 -- Looks like a reference, but probably isn't: '2' on line 160 == Missing Reference: 'Schneier97' is mentioned on line 366, but not defined ** Downref: Normative reference to an Informational RFC: RFC 2144 (ref. 'Adams97') ** Downref: Normative reference to an Informational RFC: RFC 2040 (ref. 'Baldwin96') -- Possible downref: Non-RFC (?) normative reference: ref. 'Bell97' -- Possible downref: Non-RFC (?) normative reference: ref. 'Crypto93' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-46' == Outdated reference: A later version (-05) exists of draft-ietf-ipsec-esp-v2-03 -- Possible downref: Non-RFC (?) normative reference: ref. 'Lai' -- Unexpected draft version: The latest known version of draft-ietf-ipsec-ciph-des-expiv is -01, but you're referring to -02. -- Possible downref: Non-RFC (?) normative reference: ref. 'Schneier' -- Unexpected draft version: The latest known version of draft-ietf-ipsec-doc-roadmap is -01, but you're referring to -02. ** Downref: Normative reference to an Informational draft: draft-ietf-ipsec-doc-roadmap (ref. 'Thayer97') -- Possible downref: Non-RFC (?) normative reference: ref. 'Tuchman79' Summary: 11 errors (**), 0 flaws (~~), 9 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force R. Pereira 2 IP Security Working Group TimeStep Corporation 3 Internet Draft R. Adams 4 Expires in six months Cisco Systems Inc. 5 March 10, 1998 7 The ESP CBC-Mode Cipher Algorithms 8 10 Status of this Memo 12 This document is a submission to the IETF Internet Protocol 13 Security (IPSEC) Working Group. Comments are solicited and should 14 be addressed to the working group mailing list (ipsec@tis.com) or 15 to the editor. 17 This document is an Internet-Draft. Internet Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working Groups. Note that other groups may also distribute 20 working documents as Internet Drafts. 22 Internet-Drafts draft documents are valid for a maximum of six 23 months and may be updated, replaced, or obsolete by other documents 24 at any time. It is inappropriate to use Internet-Drafts as 25 reference material or to cite them other than as "work in 26 progress." 28 To learn the current status of any Internet-Draft, please check the 29 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 30 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 31 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 32 ftp.isi.edu (US West Coast). 34 Distribution of this memo is unlimited. 36 Abstract 38 This document describes how to use CBC-mode cipher algorithms with 39 the IPSec ESP (Encapsulating Security Payload) Protocol. It not 40 only clearly states how to use certain cipher algorithms, but also 41 how to use all CBC-mode cipher algorithms. 43 Internet Draft The ESP CBC-Mode Cipher Algorithms Mar-98 45 Table of Contents 47 1. Introduction...................................................2 48 1.1 Specification of Requirements...............................2 49 2. Cipher Algorithms..............................................3 50 2.1 Mode........................................................3 51 2.2 Key Size....................................................3 52 2.3 Weak Keys...................................................4 53 2.4 Block Size and Padding......................................6 54 2.5 Rounds......................................................6 55 2.6 Backgrounds.................................................6 56 2.7 Performance.................................................9 57 3. ESP Payload...................................................10 58 3.1 ESP Environmental Considerations...........................10 59 3.2 Keying Material............................................10 60 4. Security Considerations.......................................11 61 5. References....................................................11 62 6. Acknowledgments...............................................12 63 7. Editors' Addresses............................................13 65 1. Introduction 67 The Encapsulating Security Payload (ESP) [Kent98] provides 68 confidentiality for IP datagrams by encrypting the payload data to 69 be protected. This specification describes the ESP use of CBC-mode 70 cipher algorithms. 72 While this document does not describe the use of the default cipher 73 algorithm DES, the reader should be familiar with that document. 74 [Madson98] 76 It is assumed that the reader is familiar with the terms and 77 concepts described in the "Security Architecture for the Internet 78 Protocol" [Atkinson95], "IP Security Document Roadmap" [Thayer97], 79 and "IP Encapsulating Security Payload (ESP)" [Kent98] documents. 81 Furthermore, this document is a companion to [Kent98] and MUST be 82 read in its context. 84 1.1 Specification of Requirements 86 The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD 87 NOT", and "MAY" that appear in this document are to be interpreted 88 as described in [Bradner97]. 90 Internet Draft The ESP CBC-Mode Cipher Algorithms Mar-98 92 2. Cipher Algorithms 94 All symmetric block cipher algorithms share common characteristics 95 and variables. These include mode, key size, weak keys, block 96 size, and rounds. All of which will be explained below. 98 While this document illustrates certain cipher algorithms such as 99 Blowfish [Schneier93], CAST-128 [Adams97], 3DES, IDEA [Lai], and 100 RC5 [Baldwin96], any other block cipher algorithm may be used with 101 ESP if all of the variables described within this document are 102 clearly defined. 104 2.1 Mode 106 All symmetric block cipher algorithms described or insinuated 107 within this document use Cipher Block Chaining (CBC) mode. This 108 mode requires an Initialization Vector (IV) that is the same size 109 as the block size. Use of a randomly generated IV prevents 110 generation of identical ciphertext from packets which have 111 identical data that spans the first block of the cipher algorithm's 112 blocksize. 114 The IV is XOR'd with the first plaintext block, before it is 115 encrypted. Then for successive blocks, the previous ciphertext 116 block is XOR'd with the current plaintext, before it is encrypted. 118 More information on CBC mode can be obtained in [Schneier95]. 120 2.2 Key Size 122 Some cipher algorithms allow for variable sized keys, while others 123 only allow a specific key size. The length of the key correlates 124 with the strength of that algorithm, thus larger keys are always 125 harder to break than shorter ones. 127 This document stipulates that all key sizes MUST be a multiple of 8 128 bits. 130 This document does specify the default key size for each cipher 131 algorithm. This size was chosen by consulting experts on the 132 algorithm and by balancing strength of the algorithm with 133 performance. 135 Internet Draft The ESP CBC-Mode Cipher Algorithms Mar-98 137 +==============+==================+=================+==========+ 138 | Algorithm | Key Sizes (bits) | Popular Sizes | Default | 139 +==============+==================+=================+==========+ 140 | CAST-128 [1] | 40 to 128 | 40, 64, 80, 128 | 128 | 141 +--------------+------------------+-----------------+----------+ 142 | RC5 | 40 to 2040 | 40, 128, 160 | 128 | 143 +--------------+------------------+-----------------+----------+ 144 | IDEA | 128 | 128 | 128 | 145 +--------------+------------------+-----------------+----------+ 146 | Blowfish | 40 to 448 | 128 | 128 | 147 +--------------+------------------+-----------------+----------+ 148 | 3DES [2] | 192 | 192 | 192 | 149 +--------------+------------------+-----------------+----------+ 151 Notes: 153 [1] With CAST-128, keys less than 128 bits MUST be padded with 154 zeros in the rightmost, or least significant, positions out to 128 155 bits since the CAST-128 key schedule assumes an input key of 128 156 bits. Thus if you had a key with a size of 80 bits '3B5D831CFE', 157 it would be padded to produce a key with a size of 128 bits 158 '3B5D831CFE000000'. 160 [2] The first 3DES key is taken from the first 64 bits, the second 161 from the next 64 bits, and the third from the last 64 bits. 162 Implementations MUST take into consideration the parity bits when 163 initially accepting a new set of keys. 165 The reader should note that the minimum key size for all of the 166 above cipher algorithms is 40 bits, and that the authors strongly 167 advise that implementations do NOT use key sizes smaller than 40 168 bits. 170 2.3 Weak Keys 172 Weak key checks SHOULD be performed. If such a key is found, the 173 key SHOULD be rejected and a new SA requested. Some cipher 174 algorithms have weak keys or keys that MUST not be used due to 175 their weak nature. 177 CAST-128: 179 No known weak keys. 181 Internet Draft The ESP CBC-Mode Cipher Algorithms Mar-98 183 RC5: 185 No known weak keys when used with 16 rounds. 187 IDEA: 189 IDEA has weak keys of the following form [Crypto93]: 191 0000,0000,0x00,0000,0000,000x,xxxx,x000 193 where "x" can be any hexadecimal number. 195 Keys of this form guarantee the value of bit-wise XOR of resultant 196 ciphertext pairs from the bit-wise XOR of certain plaintext pairs. 198 Blowfish: 200 Weak keys for Blowfish have been discovered. Weak keys are keys 201 that produce the identical entries in a given S-box. 202 Unfortunately, there is no way to test for weak keys before the S- 203 box values are generated. However, the chances of randomly 204 generating such a key are small. 206 3DES: 208 DES has 64 known weak keys, including so-called semi-weak keys and 209 possibly-weak keys [Schneier95, pp 280-282]. The likelihood of 210 picking one at random is negligible. 212 For DES-EDE3, there is no known need to reject weak or 213 complementation keys. Any weakness is obviated by the use of 214 multiple keys. 216 However, if the first two or last two independent 64-bit keys are 217 equal (k1 == k2 or k2 == k3), then the 3DES operation is simply the 218 same as DES. Implementers MUST reject keys that exhibit this 219 property. 221 Internet Draft The ESP CBC-Mode Cipher Algorithms Mar-98 223 2.4 Block Size and Padding 225 All of the algorithms described in this document use a block size 226 of eight octets (64 bits). 228 Padding is used to align the payload type and pad length octets as 229 specified in [Kent98]. Padding must be sufficient to align the 230 data to be encrypted to an eight octet (64 bit) boundary. 232 2.5 Rounds 234 This variable determines how many times a block is encrypted. 235 While this variable MAY be negotiated, a default value MUST always 236 exist when it is not negotiated. 238 +====================+============+======================+ 239 | Algorithm | Negotiable | Default Rounds | 240 +====================+============+======================+ 241 | CAST-128 | No | key<=80 bits, 12 | 242 | | | key>80 bits, 16 | 243 +--------------------+------------+----------------------+ 244 | RC5 | No | 16 | 245 +--------------------+------------+----------------------+ 246 | IDEA [1] | 4, 8 | 8 | 247 +--------------------+------------+----------------------+ 248 | Blowfish | No | 16 | 249 +--------------------+------------+----------------------+ 250 | 3DES | No | 48 (16x3) | 251 +--------------------+------------+----------------------+ 253 Notes: 254 [1] Although there are no known attacks against four round IDEA, 255 those choosing to use four round IDEA for performance reasons may 256 wish to use a shorter key lifetime (presumably via site specific 257 policy). 259 2.6 Backgrounds 261 CAST-128: 263 The CAST design procedure was originally developed by Carlisle 264 Adams and Stafford Travares at Queen's University, Kingston, 265 Ontario, Canada. Subsequent enhancements have been made over the 266 years by Carlisle Adams and Michael Wiener of Entrust Technologies. 267 CAST-128 is the result of applying the CAST Design Procedure as 268 outlined in [Adams97]. 270 Internet Draft The ESP CBC-Mode Cipher Algorithms Mar-98 272 RC5: 274 The RC5 encryption algorithm was developed by Ron Rivest for RSA 275 Data Security Inc. in order to address the need for a high- 276 performance software and hardware ciphering alternative to DES. 278 IDEA: 280 Xuejia Lai and James Massey developed the IDEA (International Data 281 Encryption Algorithm) algorithm. The algorithm is described in 282 detail in [Lai] and [Schneier]. 284 The IDEA algorithm is patented in Europe and in the United States 285 with patent application pending in Japan. Licenses are required 286 for commercial uses of IDEA. 288 For patent and licensing information, contact: 290 Ascom Systec AG, Dept. CMVV 291 Gewerbepark, CH-5506 292 Magenwil, Switzerland 293 Phone: +41 64 56 59 83 294 Fax: +41 64 56 59 90 295 idea@ascom.ch 296 http://www.ascom.ch/Web/systec/policy/normal/exhibit1.html 298 Blowfish: 300 Bruce Schneier of Counterpane Systems developed the Blowfish block 301 cipher algorithm. The algorithm is described in detail in 302 [Schneier93], [Schneier95] and [Schneier]. 304 3DES: 306 This DES variant, colloquially known as "Triple DES" or as DES- 307 EDE3, processes each block three times, each time with a different 308 key. This technique of using more than one DES operation was 309 proposed in [Tuchman79]. 311 Internet Draft The ESP CBC-Mode Cipher Algorithms Mar-98 313 P1 P2 Pi 314 | | | 315 IV->->(X) +>->->->(X) +>->->->(X) 316 v ^ v ^ v 317 +-----+ ^ +-----+ ^ +-----+ 318 k1->| E | ^ k1->| E | ^ k1->| E | 319 +-----+ ^ +-----+ ^ +-----+ 320 | ^ | ^ | 321 v ^ v ^ v 322 +-----+ ^ +-----+ ^ +-----+ 323 k2->| D | ^ k2->| D | ^ k2->| D | 324 +-----+ ^ +-----+ ^ +-----+ 325 | ^ | ^ | 326 v ^ v ^ v 327 +-----+ ^ +-----+ ^ +-----+ 328 k3->| E | ^ k3->| E | ^ k3->| E | 329 +-----+ ^ +-----+ ^ +-----+ 330 | ^ | ^ | 331 +>->->+ +>->->+ +>->-> 332 | | | 333 C1 C2 Ci 335 The DES-EDE3-CBC algorithm is a simple variant of the DES-CBC 336 algorithm [FIPS-46]. The "outer" chaining technique is used. 338 In DES-EDE3-CBC, an Initialization Vector (IV) is XOR'd with the 339 first 64-bit (8 byte) plaintext block (P1). The keyed DES function 340 is iterated three times, an encryption (Ek1) followed by a 341 decryption (Dk2) followed by an encryption (Ek3), and generates the 342 ciphertext (C1) for the block. Each iteration uses an independent 343 key: k1, k2 and k3. 345 For successive blocks, the previous ciphertext block is XOR'd with 346 the current plaintext (Pi). The keyed DES-EDE3 encryption function 347 generates the ciphertext (Ci) for that block. 349 To decrypt, the order of the functions is reversed: decrypt with 350 k3, encrypt with k2, decrypt with k1, and XOR the previous 351 ciphertext block. 353 Note that when all three keys (k1, k2 and k3) are the same, DES- 354 EDE3-CBC is equivalent to DES-CBC. This property allows the DES- 355 EDE3 hardware implementations to operate in DES mode without 356 modification. 358 For more explanation and implementation information for Triple DES, 359 see [Schneier95]. 361 Internet Draft The ESP CBC-Mode Cipher Algorithms Mar-98 363 2.7 Performance 365 For a comparison table of the speed of any of these and other 366 cipher algorithms, please see [Schneier97]. 368 CAST-128: 370 CAST runs approximately 3 times faster than a highly optimized DES 371 implementation and runs 5-6 times faster than the DES 372 implementations found in typical applications. This is based on a 373 non-optimized C++ implementation of CAST-128. It can therefore be 374 tuned to give even higher performance, if this is required. 376 RC5: 378 Benchmark numbers from RSA Data Security suggest that RC5-CBC runs 379 about twice as fast as Eric Young's DES-CBC implementation from 380 SSLeay on the popular 32-bit CPUs. 382 IDEA: 384 Normal eight round IDEA is approximately twice as fast as DES on 385 386 and 486 processors. However on a Pentium, both eight round 386 IDEA and 56 bit key, 16 round DES require about the same number of 387 clock cycles per byte encrypted. Four round IDEA is twice as fast 388 as eight round IDEA. 390 Blowfish: 392 Blowfish is designed to encrypt data very efficiently on 32 bit 393 processors. Although setting up the keys for Blowfish is complex 394 and time consuming, actual encryption is efficient. Sixteen round 395 Blowfish uses only 18 clock cycles per byte encrypted on a Pentium 396 versus 45 clock cycles for 16 round DES with a 56 bit key, and 108 397 for 48 round Triple-DES. 399 3DES: 401 Triple DES is approximately 2.5 times slower than "single" DES 402 (rather than 3 times), because inner permutations may be removed. 403 Phil Karn has tuned DES-EDE3-CBC software to achieve very fast 404 performance. Other DES speed estimates may be found at [Schneier, 405 page 279]. 407 Internet Draft The ESP CBC-Mode Cipher Algorithms Mar-98 409 3. ESP Payload 411 The ESP payload is made up of the IV followed by raw cipher-text. 412 Thus the payload field, as defined in [Kent98], is broken down 413 according to the following diagram: 415 +---------------+---------------+---------------+---------------+ 416 | | 417 + Initialization Vector (8 octets) + 418 | | 419 +---------------+---------------+---------------+---------------+ 420 | | 421 ~ Encrypted Payload (variable length) ~ 422 | | 423 +---------------------------------------------------------------+ 424 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 426 The IV field MUST be same size as the block size of the cipher 427 algorithm being used. The IV MUST be chosen at random. Common 428 practice is to use random data for the first IV and the last block 429 of encrypted data from an encryption process as the IV for the next 430 encryption process. 432 Including the IV in each datagram ensures that decryption of each 433 received datagram can be performed, even when some datagrams are 434 dropped, or datagrams are re-ordered in transit. 436 To avoid ECB encryption of very similar plaintext blocks in 437 different packets, implementations MUST NOT use a counter or other 438 low-Hamming distance source for IVs. 440 3.1 ESP Environmental Considerations 442 Currently, there are no known issues regarding interactions between 443 these algorithms and other aspects of ESP, such as use of certain 444 authentication schemes. 446 3.2 Keying Material 448 The minimum number of bits sent from the key exchange protocol to 449 this ESP algorithm must be greater or equal to the key size. 451 The cipher's encryption and decryption key is taken from the first 452 bits of the keying material, where represents the required 453 key size. 455 Internet Draft The ESP CBC-Mode Cipher Algorithms Mar-98 457 4. Security Considerations 459 Implementations are encouraged to use the largest key sizes they 460 can when taking into account performance considerations for their 461 particular hardware and software configuration. Note that 462 encryption necessarily impacts both sides of a secure channel, so 463 such consideration must take into account not only the client side, 464 but the server as well. 466 The case for using random values for IVs has been refined with the 467 following summary provided by Steve Bellovin. Refer to [Bell97] for 468 further information. 470 For further security considerations, the reader is encouraged to 471 read the documents that describe the actual cipher algorithms. 473 5. References 475 [Adams97] C. Adams, "The CAST-128 Encryption Algorithm", 476 RFC2144, 1997. 478 [Atkinson98]S. Kent, R. Atkinson, "Security Architecture for the 479 Internet Protocol", draft-ietf-ipsec-arch-sec-03 481 [Baldwin96] R.W. Baldwin, R. Rivest, "The RC5, RC5-CBC, RC5-CBC- 482 Pad, and RC5-CTS Algorithms", RFC2040, October 1996 484 [Bell97] S. Bellovin, "Probable Plaintext Cryptanalysis of the 485 IP Security Protocols", Proceedings of the Symposium 486 on Network and Distributed System Security, San Diego, 487 CA, pp. 155-160, February 1997 (also 488 http://www.research.att.com/~smb/probtxt.{ps, pdf}). 490 [Bradner97] S. Bradner, "Key words for use in RFCs to indicate 491 Requirement Levels", RFC2119, March 1997 493 [Crypto93] J. Daeman, R. Govaerts, J. Vandewalle, "Weak Keys for 494 IDEA", Advances in Cryptology, CRYPTO 93 Proceedings, 495 Springer-Verlag, pp. 224-230. 497 [FIPS-46] US National Bureau of Standards, "Data Encryption 498 Standard", Federal Information Processing Standard 499 (FIPS) Publication 46, January 1977. 501 [Kent98] S. Kent, Atkinson, R., "IP Encapsulating Security 502 Payload (ESP)", draft-ietf-ipsec-esp-v2-03 504 Internet Draft The ESP CBC-Mode Cipher Algorithms Mar-98 506 [Lai] X. Lai, "On the Design and Security of Block Ciphers", 507 ETH Series in Information Processing, v. 1, Konstanz: 508 Hartung-Gorre Verlag, 1992. 510 [Madson98] C. Madson, N. Dorswamy, "The ESP DES-CBC Cipher 511 Algorithm With Explicit IV", draft-ietf-ipsec-ciph- 512 des-expiv-02 514 [Schneier] B. Schneier, "Applied Cryptography Second Edition", 515 John Wiley & Sons, New York, NY, 1995. ISBN 0-471- 516 12845-7 518 [Schneier93]B. Schneier, "Description of a New Variable-Length 519 Key, 64-Bit Block Cipher", from "Fast Software 520 Encryption, Cambridge Security Workshop Proceedings", 521 Springer-Verlag, 1994, pp. 191-204. 522 http://www.counterpane.com/bfsverlag.html 524 [Schneier95]B. Schneier, "The Blowfish Encryption Algorithm - One 525 Year Later", Dr. Dobb's Journal, September 1995, 526 http://www.counterpane.com/bfdobsoyl.html 528 [Schneier97]B. Scheier, "Speed Comparisons of Block Ciphers on a 529 Pentium." February 1997, 530 http://www.counterpane.com/speed.html 532 [Thayer97] R. Thayer, N. Doraswamy, R. Glenn, "IP Security 533 Document Roadmap", draft-ietf-ipsec-doc-roadmap-02 535 [Tuchman79] Tuchman, W, "Hellman Presents No Shortcut Solutions to 536 DES", IEEE Spectrum, v. 16 n. 7, July 1979, pp. 40-41. 538 6. Acknowledgments 540 This document is a merger of most of the ESP cipher algorithm 541 documents. This merger was done to facilitate greater 542 understanding of the commonality of all of the ESP algorithms and 543 to further the development of these algorithm within ESP. 545 The content of this document is based on suggestions originally 546 from Stephen Kent and subsequent discussions from the IPSec mailing 547 list as well as other IPSec drafts. 549 For CAST, special thanks to Carlisle Adams and Paul Van Oorschot 550 both of Entrust Technologies who provided input and review. 552 For 3DES, thanks to all of the editors of the previous ESP 3DES 553 documents; W. Simpson, N. Doraswamy, P. Metzger, and P. Karn. 555 Internet Draft The ESP CBC-Mode Cipher Algorithms Mar-98 557 For RC5, thanks to Brett Howard from TimeStep for his original 558 work. 560 7. Editors' Addresses 562 Roy Pereira 563 564 TimeStep Corporation 565 +1 (613) 599-3610 x 4808 567 Rob Adams 568 569 Cisco Systems Inc. 570 +1 (408) 457-5397 572 Contributors: 574 Robert W. Baldwin 575 or 576 RSA Data Security, Inc. 577 +1 (415) 595-8782 579 Greg Carter 580 581 Entrust Technologies 582 +1 (613) 763-1358 584 Rodney Thayer 585 rodney@sabletech.com 586 Sable Technology Corporation 587 +1 (617) 332-7292 589 The IPSec working group can be contacted via the IPSec working 590 group's mailing list (ipsec@tis.com) or through its chairs: 592 Robert Moskowitz 593 rgm@icsa.net 594 International Computer Security Association 596 Theodore Y. Ts�o 597 tytso@MIT.EDU 598 Massachusetts Institute of Technology