idnits 2.17.1 draft-simpson-ipsec-cbcs-01.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-03-28) 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. == Mismatching filename: the document gives the document name as 'draft-simpson-cbcs-01', but the file name used is 'draft-simpson-ipsec-cbcs-01' == 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (July 1998) is 9388 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'DayDreamer' is mentioned on line 2, but not defined == Missing Reference: 'VK83' is mentioned on line 266, but not defined -- Looks like a reference, but probably isn't: '1' on line 531 -- Looks like a reference, but probably isn't: '0' on line 526 -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO-8732' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-81' -- Possible downref: Non-RFC (?) normative reference: ref. 'MOV97' ** Obsolete normative reference: RFC 1827 (Obsoleted by RFC 2406) -- Possible downref: Non-RFC (?) normative reference: ref. 'RFC-wwww' -- Possible downref: Non-RFC (?) normative reference: ref. 'Schneier95' Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W A Simpson [DayDreamer] 3 Internet Draft 4 expires in six months July 1998 6 ESP with Cipher Block CheckSums (CBCS) 7 draft-simpson-cbcs-01.txt 9 Status of this Memo 11 This document is an Internet-Draft. Internet Drafts are working doc- 12 uments of the Internet Engineering Task Force (IETF), its Areas, and 13 its Working Groups. Note that other groups may also distribute work- 14 ing documents as Internet Drafts. 16 Internet Drafts are draft documents valid for a maximum of six 17 months, and may be updated, replaced, or obsoleted by other documents 18 at any time. It is not appropriate to use Internet Drafts as refer- 19 ence material, or to cite them other than as a ``working draft'' or 20 ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow 24 Directories on: 26 ftp.is.co.za (Africa) 27 nic.nordu.net (Northern Europe) 28 ftp.nis.garr.it (Southern Europe) 29 ftp.ietf.org (Eastern USA) 30 ftp.isi.edu (Western USA) 31 munnari.oz.au (Pacific Rim) 33 Distribution of this memo is unlimited. 35 Copyright Notice 37 Copyright (C) William Allen Simpson (1994-1995, 1997-1998). All 38 Rights Reserved. 40 Abstract 42 This document describes the Cipher Block Chaining mode with addi- 43 tional single or double parallel CheckSums for integrity, used with a 44 number of Internet Encapsulating Security Payload (ESP) transforms. 45 This version is described in terms of 64-bit block ciphers, but can 46 be expanded to other block sizes. 48 1. Introduction 50 The Encapsulating Security Payload (ESP) [RFC-1827x] provides confi- 51 dentiality for IP datagrams by encrypting the payload data to be pro- 52 tected. This specification describes the ESP use of the Cipher Block 53 Chaining (CBC) mode, with an added checksum for integrity. 55 CBC is used to mask patterns of identical blocks within the same 56 datagram. Together with an Initialization Variable (IV) that is dif- 57 ferent for every datagram, identical plaintext payloads will each 58 encrypt to different ciphertext payloads. As an added benefit, when 59 the cipher output is effectively random in appearance (a characteris- 60 tic of a good cipher), masking the plaintext with previous ciphertext 61 will easily strengthen the entropy of the next input to the cipher. 63 A pair of checksums are added to detect changes to the ciphertext, 64 providing a modest degree of integrity in a single pass over the 65 data, rather than using a separate pass with a stronger algorithm. 66 This combination is intended to be reasonably simple to implement, 67 either serially in software or in parallel hardware for performance. 69 Although a simple checksum over multiple blocks would not normally be 70 considered cryptographically secure, the use of a cipher in the mid- 71 dle provides a background of highly random internal chaining. These 72 random blocks are used as a masking function to inhibit determination 73 of the internal state of the checksums. 75 CBC was first defined for DES in [FIPS-81], and generalized by 76 [ISO-8732] and [ISO/IEC-10116]. For a technical exposition on CBC, 77 see [MOV97]. For more explanation and implementation information for 78 CBC, and a useful comparison with other modes of operation, see 79 [Schneier95]. 81 Although this algorithm is described in terms of 64-bit (8 byte) 82 blocks with 128-bit (16 byte) internal chaining values, this could be 83 expanded to other block sizes. 85 1.1. Design Goals 87 Unlike the CBC stream orientation, CBCS is intended from its incep- 88 tion to be used with the Internet Protocol (IP) datagram network. 89 This environment provides specific limitations on the scope of vul- 90 nerability. 92 Each IP datagram has a length limitation of 576 bytes, unless a 93 larger size is explicitly indicated by the transport layer. Future 94 IP versions extend this length to 1500 bytes. The CBCS integrity is 95 designed to reliably detect any multiple bit change within the 96 11,680-bit payload, with an order of at least 1/2**16 probability of 97 failure. This is considerably stronger than the 1/2**7 probability 98 provided by the IP, TCP and UDP checksums. 100 Given that ESP provides a Sequence Number range of 2**32-1, and the 101 window of acceptable values is in the range 2**5 to 2**8, CBCS is 102 intended to be computationally infeasible to predictably and unde- 103 tectably modify a datagram in transit during the time provided by the 104 communication bandwidth-delay product. 106 Software processing cost should be less than half as much as crypto- 107 graphic hashing algorithms (such as MD5 or SHA1) on a little-endian 108 machine, much better on a 32-bit big-endian machine, and nearly neg- 109 ligible on a 64-bit big-endian machine. 111 Hardware performance will benefit from the removal of multiple algo- 112 rithm passes over the same data. The hardware resources required are 113 considerably less than required for MD5 or SHA1. 115 1.2. Primary CheckSum 117 The primary checksum involves feed-forward through the encryption 118 function, in the same fashion as CBC, through XOR with the plaintext. 119 Any single or multiple bit change in a cipher block (or the datagram 120 IV) will result in a large unpredicatable change to all following 121 cipher blocks. 123 The primary checksum may be used alone. Its strength is based on an 124 integrity secret-key, the related blocksize of the cipher, and is 125 dependent on the strength of the cipher itself. 127 1.3. Secondary CheckSum 129 The secondary checksum involves only the checksum of successive 130 ciphertext blocks. Any single bit change in a cipher block (or the 131 datagram IV) will result in a small unpredicatable change to all fol- 132 lowing cipher blocks. Multiple bit changes in carefully chosen pairs 133 can be used to reduce the unpredictability. 135 The secondary checksum is probably too weak to be used alone. Its 136 strength is based on an integrity secret-key, the related blocksize 137 of the cipher, and the unpredictability of the cipher output. 139 However, it can be combined with the primary checksum to double the 140 amount of internal chaining for the integrity function. 142 2. Description 144 IVa P1 P2 Pi 145 | | | | 146 +-----+ v +-----+ v +-----+ v 147 Sa->| S |->(X)->| S |->->(X)->| S |->->(X)-> 148 +-----+ | +-----+ | +-----+ | 149 v ^ v ^ v 150 +-----+ ^ +-----+ ^ +-----+ 151 k->| E | ^ k->| E | ^ k->| E | 152 +-----+ ^ +-----+ ^ +-----+ 153 | ^ | ^ | 154 IVb +->->->+ +->->->+ +->->-> 155 | | | | 156 +-----+ v +-----+ v +-----+ v 157 Sb->| S |->(X)->| S |->->(X)->| S |->->(X)-> 158 +-----+ | +-----+ | +-----+ | 159 v ^ v ^ v 160 +->->->+ +->->->+ +->->-> 161 | | | 162 C1 C2 Ci 164 The Cipher Block CheckSums (CBCS) mode is a simple variant of the CBC 165 mode [RFC-wwww]. 167 For each datagram, the checksums are initialized with separate seeds 168 (Sa, Sb). An Initialization Variable (IV) is split into two parts 169 (IVa, IVb) which are separately summed into the primary and secondary 170 checksums respectively. 172 The primary checksum output XOR masks (X) the first plaintext block 173 (P1). The keyed encryption function (Ek) is followed by another XOR 174 mask (X) with the secondary checksum output, which generates the 175 ciphertext (C1) for the block. 177 For successive blocks, the previous output of the encryption function 178 (before masking) is summed into the primary checksum, and the previ- 179 ous ciphertext block (after masking) is summed into the secondary 180 checksum. The primary checksum output XOR masks (X) the current 181 plaintext (Pi). The keyed encryption function (Ek) is followed by 182 another XOR mask (X) with the secondary checksum output, which gener- 183 ates the ciphertext (Ci) for that block. 185 C1 C2 Ci 186 | | | 187 IVb +->->->+ +->->->+ +->->-> 188 | | v | v | 189 +-----+ v +-----+ v +-----+ v 190 Sb->| S |->(X)->| S |->->(X)->| S |->->(X)-> 191 +-----+ | +-----+ | +-----+ | 192 v v v 193 +->->->+ +->->->+ +->->-> 194 v v v v v 195 +-----+ v +-----+ v +-----+ 196 k->| D | v k->| D | v k->| D | 197 +-----+ v +-----+ v +-----+ 198 IVa v v v v v 199 | | v | v | 200 +-----+ v +-----+ v +-----+ v 201 Sa->| S |->(X)->| S |->->(X)->| S |->->(X)-> 202 +-----+ | +-----+ | +-----+ | 203 P1 P2 Pi 205 To decrypt, the order of the manipulations is reversed (as shown). 207 Design Notes: 209 The (X) is a crude symbol indicating XOR of the two blocks, but 210 the checksum block is passed unaltered to the next checksum stage. 212 The checksums could be seeded with the encryption key. However, 213 additional keying material is relatively easy to generate, and 214 should provide an increase in the security of the integrity check. 216 Commonly, only one IV of the block size is available. The check- 217 sums could both use the same IV, but separate IVs should provide 218 an increase in the security. 220 Using the plaintext was considered as the addend to the secondary 221 checksum, but this was rejected in fear of revealing some bits of 222 the plaintext, or a cipher relationship between the plaintext and 223 the ciphertext. 225 3. Initialization Variable 227 CBCS requires an Initialization Variable (IV). The IV conceals ini- 228 tial blocks that repeat in multiple datagrams. 230 For ESP, each datagram generates its IV from material carried in the 231 datagram. This ensures that decryption of the received datagram can 232 be performed, even when some datagrams are lost, duplicated, or re- 233 ordered in transit. 235 For 64-bit block ciphers: 237 The primary 64-bit IVa is generated from the 32-bit Security 238 Parameters Index (SPI) field followed by (concatenated with) the 239 32-bit Sequence Number (SN) field. Then, the bit-wise complement 240 of the 32-bit Sequence Number (SN) value is XOR'd with the first 241 32-bits (SPI): 243 (SPI ^ -SN) || SN 245 The secondary 64-bit IVb is the complement of IVa: 247 (-SPI ^ SN) || -SN 249 The SPI and SN are processed in big-endian order. That is, the 250 most significant byte is the first byte in network transmission 251 order. 253 Security Notes: 255 Each IV is intended to be unique over the lifetime of the ESP 256 cipher session-key(s). A counter is most commonly used to gener- 257 ate the IV, providing an easy method to prevent repetition. 259 However, cryptanalysis might be aided by the rare serendipitous 260 occurrence when the counter repeatedly changes in exactly the same 261 fashion as corresponding bit positions in the first block. Design 262 of specific IV generation techniques must take this into account. 264 Ideally, the IV would be based on explicit fields carried in each 265 datagram, but generated pseudo-randomly and protected from disclo- 266 sure [VK83]. This completely protects the first block from unde- 267 tectable modification. 269 Incorporating the ESP Security Parameters Index (SPI) and the 270 anti-replay ESP Sequence Number (SN) together can provide both 271 uniqueness and mutual protection between the first block and the 272 ESP header. Modification of the SPI to alter the decryption 273 key(s) will prevent correct decryption of the first block. Modi- 274 fication of the SN to avoid anti-replay measures will also prevent 275 correct decryption of the first block. The first block is most 276 likely to contain datagram headers required for delivery. 277 Attempts to modify the IV to deliberately redirect transport head- 278 ers will also likely be detected by the transport checksums. 280 Inclusion of the bit-wise complement of SN ensures that bit 281 changes are reflected twice in the IV. 283 The checksum step with an undisclosed seed is intended to generate 284 unpredictable initial values. 286 4. Integrity 288 Unlike CBC alone, CBCS provides integrity for the datagram. A single 289 ciphertext bit change will affect the current block, and every fol- 290 lowing block. The final checksum will give a highly probable indica- 291 tion of the alteration. 293 4.1. CheckSum Steps 295 The checksum summation functions are calculated in three steps: 297 1) addition modulo 2**N with end around carry; 299 2) count of the number of 1-bits in the sum; 301 3) left circular rotation of the sum by the bit count. 303 This technique can be generalized to both 32-bit and 64-bit regis- 304 ters, over block sizes of 64-bits, 96-bits, 128-bits, and more. 306 All checksum operations are processed in big-endian order. That is, 307 the first byte of a block in transmission order is treated as the 308 most significant byte for addition and left circular rotation. 310 Design Notes: 312 End around carry is a common feature of protocol checksums. For 313 example, for 2**8, 254 + 1 -> 255, 255 + 1 -> 1. 315 4.2. Single 32-bit CheckSum (CBCS1-32) 317 For ESP with only a primary 64-bit checksum, an optional 32-bit 318 Authenticator (when provided) is calculated in six final steps: 320 a) add and rotate a 64-bit count of the number of processed bits, 321 including the IV, as described for the checksum; 323 b) split the checksum into two 32-bit halves; 324 c) multiply the two 32-bit halves, yielding a 64-bit product; 326 d) rotate the product by its bit count, as described for the check- 327 sum; 329 e) split the product again into two 32-bit halves; 331 f) XOR the 32-bit halves, yielding a final 32-bit Authenticator 332 value. 334 The Authenticator is deposited in big-endian order. That is, the 335 most significant byte is the first byte in network transmission 336 order. 338 Design Notes: 340 The multiply is intended to confuse and diffuse the semi- 341 independent halves, while the rotations and XOR prevent determina- 342 tion of the final internal state of the checksum. 344 4.3. Double 32-bit CheckSum (CBCS2-32) 346 For ESP with both primary and secondary 64-bit checksums, an optional 347 32-bit Authenticator (when provided) is calculated in seven final 348 steps: 350 a) to each checksum, add and rotate a 64-bit count of the number of 351 processed bits, including the IV, as described for the checksum; 353 b) add and rotate the two checksums, as described for the checksum; 355 c) split the 64-bit sum into two 32-bit halves; 357 d) multiply the two 32-bit halves, yielding a 64-bit product; 359 e) rotate the product by its bit count, as described for the check- 360 sum; 362 f) split the product again into two 32-bit halves; 364 g) XOR the 32-bit halves, yielding a final 32-bit Authenticator 365 value. 367 The Authenticator is deposited in big-endian order. That is, the 368 most significant byte is the first byte in network transmission 369 order. 371 Design Notes: 373 The addition and multiply are intended to confuse and diffuse the 374 independent checksums, in much the same fashion as the Single 375 32-bit CheckSum. 377 4.4. Double 64-bit CheckSum (CBCS2-64) 379 For ESP with both primary and secondary 64-bit checksums, an optional 380 64-bit Authenticator (when provided) is calculated in five final 381 steps: 383 a) to each checksum, add and rotate a 64-bit count of the number of 384 processed bits, including the IV, as described for the checksum; 386 b) multiply the two checksums, yielding a 128-bit product; 388 c) split the product into two 64-bit halves; 390 d) rotate each half of the product by its bit count, as described for 391 the checksum; 393 e) add the halves modulo 2**64 with end around carry, yielding a 394 final 64-bit Authenticator value. 396 The Authenticator is deposited in big-endian order. That is, the 397 most significant byte is the first byte in network transmission 398 order. 400 Design Notes: 402 The larger multiply is intended to more effectively diffuse the 403 checksums, while the rotations and addition prevent determination 404 of the final internal state of the checksums. 406 5. Collisions 408 This checksum technique is hoped to prevent linear cryptanalysis by 409 incorporating a non-linear rotation function. In case this hope 410 proves illusive, the analysis in [RFC-wwww] should be considered. 412 A. Rotation Probability 414 Assuming that the cipher produces a uniformly random distribution, 415 the probability for rotation in 32-bits (4,294,967,296) is: 417 0, 32: 1 418 1, 31: 32 419 2, 30: 496 420 3, 29: 4,960 421 4, 28: 35,960 422 5, 27: 201,376 423 6, 26: 906,192 424 7, 25: 3,365,856 425 8, 24: 10,518,300 426 9, 23: 28,048,800 427 10, 22: 64,512,240 428 11, 21: 129,024,480 429 12, 20: 225,792,840 430 13, 19: 347,373,600 431 14, 18: 471,435,600 432 15, 17: 565,722,720 433 16: 601,080,390 435 B. Code Samples 437 Here are a few extracts of code to illustrate basic concepts, based 438 on examples graciously provided by Niels Provos. 440 B.1. Bit Count 442 When a population count is not natively available in the machine 443 instructions, adding the counts per byte can be significantly faster 444 than testing each bit. Machines with byte extract and translate 445 instructions will improve performance. 447 uint8 bit8ones[] = 448 { /* 1 2 3 4 5 6 7 8 9 a b c d e f */ 449 0, 1, 1, 2, 1, 2, 2, 3, 1, 2, 2, 3, 2, 3, 3, 4, 450 1, 2, 2, 3, 2, 3, 3, 4, 2, 3, 3, 4, 3, 4, 4, 5, 451 1, 2, 2, 3, 2, 3, 3, 4, 2, 3, 3, 4, 3, 4, 4, 5, 452 2, 3, 3, 4, 3, 4, 4, 5, 3, 4, 4, 5, 4, 5, 5, 6, 453 1, 2, 2, 3, 2, 3, 3, 4, 2, 3, 3, 4, 3, 4, 4, 5, 454 2, 3, 3, 4, 3, 4, 4, 5, 3, 4, 4, 5, 4, 5, 5, 6, 455 2, 3, 3, 4, 3, 4, 4, 5, 3, 4, 4, 5, 4, 5, 5, 6, 456 3, 4, 4, 5, 4, 5, 5, 6, 4, 5, 5, 6, 5, 6, 6, 7, 458 1, 2, 2, 3, 2, 3, 3, 4, 2, 3, 3, 4, 3, 4, 4, 5, 459 2, 3, 3, 4, 3, 4, 4, 5, 3, 4, 4, 5, 4, 5, 5, 6, 460 2, 3, 3, 4, 3, 4, 4, 5, 3, 4, 4, 5, 4, 5, 5, 6, 461 3, 4, 4, 5, 4, 5, 5, 6, 4, 5, 5, 6, 5, 6, 6, 7, 462 2, 3, 3, 4, 3, 4, 4, 5, 3, 4, 4, 5, 4, 5, 5, 6, 463 3, 4, 4, 5, 4, 5, 5, 6, 4, 5, 5, 6, 5, 6, 6, 7, 464 3, 4, 4, 5, 4, 5, 5, 6, 4, 5, 5, 6, 5, 6, 6, 7, 465 4, 5, 5, 6, 5, 6, 6, 7, 5, 6, 6, 7, 6, 7, 7, 8, 466 }; 468 static int 469 bit32count( uint32 n ) 470 { 471 int result = bit8ones[ n & 0xff ]; 472 n >>= 8; 473 result += bit8ones[ n & 0xff ]; 474 n >>= 8; 475 result += bit8ones[ n & 0xff ]; 476 n >>= 8; 477 return (result + bit8ones[ n & 0xff ]); 478 } 480 B.2. Variable Rotation 482 When a rotation is not natively available in the machine instruc- 483 tions, it can be emulated with an appropriate combination of shifts. 484 Where a fixed shift is faster than a variable shift, 65 switch-cases 485 can improve performance. 487 static void 488 bit64rotation32( uint32 *cs ) 489 { 490 uint32 csy = cs[1]; 491 uint32 csz = cs[0]; 492 int bcv = bit32count(csz) + bit32count(csy); 494 if ( bcv < 32 ) 495 { 496 /* 0..31 */ 497 cs[0] = (csz << bcv) | (csy >> (32-bcv)); 498 cs[1] = (csy << bcv) | (csz >> (32-bcv)); 499 } 500 else if ( bcv == 32 ) 501 { 502 /* fast swap */ 503 cs[0] = csy; 504 cs[1] = csz; 505 } 506 else 507 { 508 /* 33..64 swap */ 509 cs[0] = (csy << (bcv-32)) | (csz >> (64-bcv)); 510 cs[1] = (csz << (bcv-32)) | (csy >> (64-bcv)); 511 } 512 } 514 B.3. Addition with End Around Carry 516 Addition with carry is usually natively available in the machine 517 instructions. 519 static void 520 bit64addition32( uint32 *cs, uint32 *addend ) 521 { 522 uint32 topy = cs[1] | addend[1]; 523 uint32 topz = cs[0] | addend[0]; 525 cs[0] += addend[0]; 526 if ( cs[0] < topz ) 527 { 528 cs[1]++; 529 } 530 cs[1] += addend[1]; 531 if ( cs[1] < topy ) 532 { 533 cs[0]++; 534 } 535 } 537 Operational Considerations 539 The specification provides only a few manually configurable parame- 540 ters: 542 Primary Seed 543 A primary seed is configured in order prior to any keys. The 544 value is the same size as the block size of the cipher algorithm. 546 Secondary Seed 547 An optional secondary seed is configured in order following any 548 keys. The value is the same size as the block size of the cipher 549 algorithm. 551 The configured seed values are interpreted in big-endian order. That 552 is, the most significant byte of the seed is the leading byte. 554 Security Considerations 556 Specific security limitations are described as notes in the relevant 557 sections. 559 Acknowledgements 561 Some of the text of this specification was derived from earlier work 562 by William Allen Simpson and Perry Metzger in multiple Request for 563 Comments. 565 The checksum technique is based upon a common use of the CDC 6000 566 series 60-bit registers for "normal" protocols. Fortuitously, those 567 machines featured both fast variable rotate and a population count 568 instruction. 570 Niels Provos and David Wagner provided useful critiques of earlier 571 versions of this document. 573 References 575 [ISO-8732] "Banking -- Key management (wholesale)", International 576 Organization for Standardization, 1988. 578 [ISO/IEC-10116] 579 "Information Processing -- Modes of Operation for an n- 580 bit block cipher algorithm", International Organization 581 for Standardization, 1991. 583 [FIPS-81] US National Bureau of Standards, "DES Modes of Opera- 584 tion", Federal Information Processing Standard Publica- 585 tion 81, December 1980. 587 [MOV97] Menezes, A.J., van Oorschot, P., and Vanstone, S., "Hand- 588 book of Applied Cryptography", CRC Press, 1997. 590 [RFC-1827x] Simpson, W., "IP Encapsulating Security Protocol (ESP) 591 for implementors", work in progress. 593 [RFC-wwww] Simpson, W.A, "ESP with Cipher Block Chaining (CBC)", 594 work in progress. 596 [Schneier95] 597 Schneier, B., "Applied Cryptography Second Edition", John 598 Wiley & Sons, New York, NY, 1995. ISBN 0-471-12845-7. 600 Contacts 602 Comments about this document should be discussed on the ipsec@tis.com 603 mailing list. 605 Questions about this document can also be directed to: 607 William Allen Simpson 608 DayDreamer 609 Computer Systems Consulting Services 610 1384 Fontaine 611 Madison Heights, Michigan 48071 613 wsimpson@UMich.edu 614 wsimpson@GreenDragon.com (preferred) 616 Full Copyright Statement 618 Copyright (C) William Allen Simpson (1994-1995, 1997-1998). All 619 Rights Reserved. 621 This document and translations of it may be copied and furnished to 622 others, and derivative works that comment on or otherwise explain it 623 or assist in its implementation may be prepared, copied, published 624 and distributed, in whole or in part, without restriction of any 625 kind, provided that the above copyright notice and this paragraph are 626 included on all such copies and derivative works. However, this doc- 627 ument itself may not be modified in any way, except as required to 628 translate it into languages other than English. 630 This document and the information contained herein is provided on an 631 "AS IS" basis and the author(s) DISCLAIM ALL WARRANTIES, EXPRESS OR 632 IMPLIED, INCLUDING (BUT NOT LIMITED TO) ANY WARRANTY THAT THE USE OF 633 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 634 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.