idnits 2.17.1 draft-baldwin-rc5-00.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-25) 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** Bad filename characters: the document name given in the document, 'draft-baldwin-rc5-00.txt.', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-baldwin-rc5-00.txt.', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-baldwin-rc5-00.txt.', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-baldwin-rc5-00.txt.', but the file name used is 'draft-baldwin-rc5-00' == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 7 longer pages, the longest (page 4) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** 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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 1333: '...rs ANY DEFINED BY algorithm OPTIONAL...' RFC 2119 keyword, line 1355: '...v OCTET STRING OPTIONAL...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 490 has weird spacing: '... int i;...' == Line 578 has weird spacing: '...ed char cha...' == Line 579 has weird spacing: '...ed char inp...' == Line 963 has weird spacing: '... char key...' == Line 965 has weird spacing: '... char key...' == (9 more instances...) == 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 (March 1996) is 10268 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: '0' is mentioned on line 545, but not defined -- Looks like a reference, but probably isn't: 'T-1' on line 182 -- Looks like a reference, but probably isn't: 'N-1' on line 187 -- Looks like a reference, but probably isn't: 'BB-1' on line 193 -- Looks like a reference, but probably isn't: 'BB' on line 579 == Missing Reference: '402' is mentioned on line 1381, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '4') -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' Summary: 13 errors (**), 1 flaw (~~), 12 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT R. W. Baldwin 3 Expires September 1, 1996 RSA Data Security, Inc. 5 R. Rivest 6 MIT Laboratory for Computer Science 7 and RSA Data Security, Inc. 9 March 1996 11 The RC5, RC5-CBC, RC5-CBC-Pad, and RC5-CTS Algorithms 13 Status of this Memo 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its 17 areas, and its working groups. Note that other groups may also 18 distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet- 23 Drafts as reference material or to cite them other than as ``work 24 in progress.'' 26 To learn the current status of any Internet-Draft, please check 27 the ``1id-abstracts.txt'' listing contained in the Internet- 28 Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net 29 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East 30 Coast), or ftp.isi.edu (US West Coast). 32 The filename for this document is draft-baldwin-rc5-00.txt. 34 Acknowledgments 36 We would like to thank Steve Dusse, Victor Chang, Tim Mathews, 37 Brett Howard, and Burt Kaliski for helpful suggestions. 39 Table of Contents 41 1. Executive Summary 42 2. Overview 43 3. Terminology and Notation 44 4. Description of RC5 Keys 45 5. Description of RC5 Key Expansion 46 6. Description of RC5 Block Cipher 47 7. Description of RC5-CBC and RC5-CBC-Pad 48 8. Description of RC5-CTS 49 9. Test Program and Vectors 50 10. Security Considerations 51 11. ASN.1 Identifiers 52 draft RC5, RC5-CBC RC5-CBC-Pad, and RC5-CTS March 1996 54 1. Executive Summary 56 This document defines four ciphers with enough detail to ensure 57 interoperability between different implementations. The first 58 cipher is the raw RC5 block cipher. The RC5 cipher takes a fixed 59 size input block and produces a fixed sized output block using a 60 transformation that depends on a key. The second cipher, RC5-CBC, 61 is the Cipher Block Chaining (CBC) mode for RC5. It can process 62 messages whose length is a multiple of the RC5 block size. The 63 third cipher, RC5-CBC-Pad, handles plaintext of any length, though 64 the ciphertext will be longer than the plaintext by at most the 65 size of a single RC5 block. The RC5-CTS cipher is the Cipher Text 66 Stealing mode of RC5, which handles plaintext of any length and the 67 ciphertext length matches the plaintext length. 69 The RC5 cipher was invented by Professor Ronald L. Rivest of the 70 Massachusetts Institute of Technology in 1994. It is a very fast 71 and simple algorithm that is parameterized by the block size, the 72 number of rounds, and key length. These parameters can be adjusted 73 to meet different goals for security, performance, and 74 exportability. 76 RSA Data Security Incorporated has filed a patent application on 77 the RC5 cipher and for trademark protection for RC5, RC5-CBC, RC5- 78 CBC-Pad, RC5-CTS and assorted variations. 80 draft RC5, RC5-CBC RC5-CBC-Pad, and RC5-CTS March 1996 82 2. Overview 84 This memo is a restatement of existing published material. The 85 description of RC5 follows the notation and order of explanation 86 found in the original RC5 paper by Professor Rivest [2]. The CBC 87 mode appears in reference works such as the one by Bruce Schneier 88 [6]. The CBC-Pad mode is the same as in the Public Key 89 Cryptography Standard (PKCS) number five [5]. Sample C code [8] is 90 included for clarity only and is equivalent to the English language 91 descriptions. 93 The ciphers will be explained in a bottom up object-oriented 94 fashion. First, RC5 keys will be presented along with the key 95 expansion algorithm. Second, the RC5 block cipher is explained, 96 and finally, the RC5-CBC and RC5-CBC-Pad ciphers are specified. 97 For brevity, only the encryption process is described. Decryption 98 is achieved by inverting the steps of encryption. 100 The object-oriented description found here should make it easier to 101 implement interoperable systems, though it is not as terse as the 102 functional descriptions found in the references. There are two 103 classes of objects, keys and cipher algorithms. Both classes share 104 operations that create and destroy these objects in a manner that 105 ensures that secret information is not returned to the memory 106 manager. 108 Keys also have a "set" operation that copies a secret key into the 109 object. The "set" operation for the cipher objects defines the 110 number of rounds, and the initialization vector. 112 There are four operations for the cipher objects described in this 113 memo. There is binding a key to a cipher object, setting a new 114 initialization vector for a cipher object without changing the key, 115 encrypting part of a message (this would be performed multiple 116 times for long messages), and processing the last part of a message 117 which may add padding or check the length of the message. 119 draft RC5, RC5-CBC RC5-CBC-Pad, and RC5-CTS March 1996 121 In summary, the cipher will be explained in terms of these 122 operations: 124 RC5_Key_Create - Create a key object. 126 RC5_Key_Destroy - Destroy a key object. 128 RC5_Key_Set - Bind a user key to a key object. 130 RC5_CBC_Create - Create a cipher object. 132 RC5_CBC_Destroy - Destroy a cipher object. 134 RC5_CBC_Encrypt_Init - Bind a key object to a cipher object. 136 RC5_CBC_SetIV - Set a new IV without changing the key. 138 RC5_CBC_Encrypt_Update - Process part of a message. 140 RC5_CBC_Encrypt_Final- Process the end of a message. 142 draft RC5, RC5-CBC RC5-CBC-Pad, and RC5-CTS March 1996 144 3. Terminology and Notation 146 The term "word" refers to a string of bits of a particular length 147 that can be operated on as either an unsigned integer or as a bit 148 vector. For example a "word" might be 32 or 64 bits long depending 149 on the desired block size for the RC5 cipher. A 32 bit word will 150 produce a 64 bit block size. For best performance the RC5 word 151 size should match the register size of the CPU. The term "byte" 152 refers to eight bits. 154 The following variables will be used throughout this memo with 155 these meanings: 157 W This is the word size for RC5 measured in bits. It is half the 158 block size. The word sizes covered by this memo are 32 and 64. 160 WW This is the word size for RC5 measured in bytes. 162 B This is the block size for RC5 measured in bits. It is twice 163 the word size. When RC5 is used as a 64 bit block cipher, B is 164 64 and W is 32. 0 < B < 257. In the sample code, B, is used as 165 a variable instead of a cipher system parameter, but this usage 166 should be obvious from context. 168 BB This is the block size for RC5 measured in bytes. BB = B / 8. 170 b This is the byte length of the secret key. 0 <= b < 256. 172 K This is the secret key which is treated as a sequence of b 173 bytes indexed by: K[0], ..., K[b-1]. 175 R This is the number of rounds of the inner RC5 transform. 176 0 <= R < 256. 178 T This is the number of words in the expanded key table. It is 179 always 2*(R + 1). 1 < T < 513. 181 S This is the expanded key table which is treated as a sequence 182 of words indexed by: S[0], ..., S[T-1]. 184 N This is the byte length of the plaintext message. 186 P This is the plaintext message which is treated as a sequence of 187 N bytes indexed by: P[0], ..., P[N-1]. 189 C This is the ciphertext output which is treated as a sequence of 190 bytes indexed by: C[0], C[1], ... 192 I This is the initialization vector for the CBC mode which is 193 treated as a sequence of bytes indexed by: I[0], ..., I[BB-1]. 195 draft RC5, RC5-CBC RC5-CBC-Pad, and RC5-CTS March 1996 197 4. Description of RC5 Keys 199 Like most block ciphers, RC5 expands a small user key into a table 200 of internal keys. The byte length of the user key is one of the 201 parameters of the cipher, so the RC5 user key object must be able 202 to hold variable length keys. A possible structure for this in C 203 is: 205 /* Definition of RC5 user key object. */ 206 typedef struct rc5UserKey 207 { 208 int keyLength; /* In Bytes. */ 209 unsigned char *keyBytes; 210 } rc5UserKey; 212 The basic operations on a key are to create, destroy and set. To 213 avoid exposing key material to other parts of an application, the 214 destroy operation zeros the memory allocated for the key before 215 releasing it to the memory manager. A general key object may 216 support other operations such as generating a new random key and 217 deriving a key from key-agreement information. 219 4.1 Creating an RC5 Key 221 To create a key, the memory for the key object must be allocated 222 and initialized. The C code below assumes that a function called 223 "malloc" will return a block of uninitialized memory from the heap, 224 or zero indicating an error. 226 /* Allocate and initialize an RC5 user key. 227 * Return 0 if problems. 228 */ 229 rc5UserKey *RC5_Key_Create () 230 { 231 rc5UserKey *pKey; 233 pKey = (rc5UserKey *) malloc (sizeof(*pKey)); 234 if (pKey != ((rc5UserKey *) 0)) 235 { 236 pKey->keyLength = 0; 237 pKey->keyBytes = (unsigned char *) 0; 238 } 239 return (pKey); 240 } 241 draft RC5, RC5-CBC RC5-CBC-Pad, and RC5-CTS March 1996 243 4.2 Destroying an RC5 Key 245 To destroy a key, the memory must be zeroed and released to the 246 memory manager. The C code below assumes that a function called 247 "free" will return a block of memory to the heap. 249 /* Zero and free an RC5 user key. 250 */ 251 void RC5_Key_Destroy (pKey) 252 rc5UserKey *pKey; 253 { 254 unsigned char *to; 255 int count; 257 if (pKey == ((rc5UserKey *) 0)) 258 return; 259 if (pKey->keyBytes == ((unsigned char *) 0)) 260 return; 261 to = pKey->keyBytes; 262 for (count = 0 ; count < pKey->keyLength ; count++) 263 *to++ = (unsigned char) 0; 264 free (pKey->keyBytes); 265 pKey->keyBytes = (unsigned char *) 0; 266 pKey->keyLength = 0; 267 free (pKey); 268 } 269 draft RC5, RC5-CBC RC5-CBC-Pad, and RC5-CTS March 1996 271 4.3 Setting an RC5 Key 273 Setting the key object makes a copy of the secret key into a block 274 of memory allocated from the heap. 276 /* Set the value of an RC5 user key. 277 * Copy the key bytes so the caller can zero and 278 * free the original. 279 * Return zero if problems 280 */ 281 int RC5_Key_Set (pKey, keyLength, keyBytes) 282 rc5UserKey *pKey; 283 int keyLength; 284 unsigned char *keyBytes; 285 { 286 unsigned char *keyBytesCopy; 287 unsigned char *from, *to; 288 int count; 290 keyBytesCopy = (unsigned char *) malloc (keyLength); 291 if (keyBytesCopy == ((unsigned char *) 0)) 292 return (0); 293 from = keyBytes; 294 to = keyBytesCopy; 295 for (count = 0 ; count < keyLength ; count++) 296 *to++ = *from++; 297 pKey->keyLength = count; 298 pKey->keyBytes = keyBytesCopy; 299 return (1); 300 } 301 draft RC5, RC5-CBC RC5-CBC-Pad, and RC5-CTS March 1996 303 5. Description of RC5 Key Expansion 305 This section describes the key expansion algorithm. To be 306 specific, the sample code assumes that the block size is 64 bits. 307 Several programming parameters depend on the block size. 309 /* Definitions for RC5 as a 64 bit block cipher. */ 310 /* The "unsigned int" will be 32 bits on all but */ 311 /* the oldest compilers, which will make it 16 bits. */ 312 /* On a DEC Alpha "unsigned long" is 64 bits, not 32. */ 313 #define RC5_WORD unsigned int 314 #define W (32) 315 #define WW (W / 8) 316 #define ROT_MASK (W - 1) 317 #define BB ((2 * W) / 8) /* Bytes per block */ 319 /* Define macros used in multiple procedures. */ 320 /* These macros assumes ">>" is an unsigned operation, */ 321 /* and that x and s are of type RC5_WORD. */ 322 #define SHL(x,s) ((RC5_WORD)((x)<<((s)&ROT_MASK))) 323 #define SHR(x,s,w) ((RC5_WORD)((x)>>((w)-((s)&ROT_MASK)))) 324 #define ROTL(x,s,w) ((RC5_WORD)(SHL((x),(s))|SHR((x),(s),(w)))) 326 5.1 Definition of initialization constants 328 Two constants, Pw and Qw, are defined for any word size W by the 329 expressions: 331 Pw = Odd((e-2)*2**W) 333 Qw = Odd((phi-1)*2**W) 335 where e is the base of the natural logarithm (2.71828 ...), and phi 336 is the golden ratio (1.61803 ...), and 2**W is 2 raised to the 337 power of W, and Odd(x) is equal to x if x is odd, or equal to x 338 plus one if x is even. For W equal to 16, 32, and 64, the Pw and 339 Qw constants are the following hexadecimal values: 341 #define P16 0xb7e1 342 #define Q16 0x9e37 343 #define P32 0xb7e15163 344 #define Q32 0x9e3779b9 345 #define P64 0xb7e151628aed2a6b 346 #define Q64 0x9e3779b97f4a7c15 347 draft RC5, RC5-CBC RC5-CBC-Pad, and RC5-CTS March 1996 349 #if W == 16 350 #define Pw P16 /* Select 16 bit word size */ 351 #define Qw Q16 352 #endif 353 #if W == 32 354 #define Pw P32 /* Select 32 bit word size */ 355 #define Qw Q32 356 #endif 357 #if W == 64 358 #define Pw P64 /* Select 64 bit word size */ 359 #define Qw Q64 360 #endif 362 5.2 Interface definition 364 The key expansion routine converts the b-byte secret key, K, into 365 an expanded key, S, which is a sequence of T = 2*(R+1) words. The 366 expansion algorithm uses two constants that are derived from the 367 constants, e, and phi. These are used to initialize S, which is 368 then modified using K. A C code procedure header for this routine 369 could be: 371 /* Expand an RC5 user key. 372 */ 373 void RC5_Key_Expand (b, K, R, S) 374 int b; /* Byte length of secret key */ 375 char *K; /* Secret key */ 376 int R; /* Number of rounds */ 377 RC5_WORD *S; /* Expanded key buffer, 2*(R+1) words */ 378 { 380 5.3 Convert secret key from bytes to words 382 This step converts the b-byte key into a sequence of words stored 383 in the array L. On a little-endian processor this is accomplished 384 by zeroing the L array and copying in the b bytes of K. The 385 following C code will achieve this effect on all processors: 387 int i, j, k, LL, t, T; 388 RC5_WORD L[256/WW]; /* Based on max key size */ 389 RC5_WORD A, B; 391 /* LL is number of elements used in L. */ 392 LL = (b + WW - 1) / WW; 393 for (i = 0 ; i < LL ; i++) { 394 L[i] = 0; 395 } 396 for (i = 0 ; i < b ; i++) { 397 t = (K[i] & 0xFF) << (8*(i%4)); /* 0, 8, 16, 24*/ 398 L[i/WW] = L[i/WW] + t; 399 draft RC5, RC5-CBC RC5-CBC-Pad, and RC5-CTS March 1996 401 } 402 draft RC5, RC5-CBC RC5-CBC-Pad, and RC5-CTS March 1996 404 5.4 Initialize the expanded key table 406 This step fills in the S table with a fixed (key independent) 407 pseudo-random pattern using an arithmetic progression based on Pw 408 and Qw modulo 2**W. The element S[i] equals i*Qw + Pw modulo 2**W. 409 This table could be precomputed and copied as needed or computed on 410 the fly. In C code it can be computed by: 412 T = 2*(R+1); 413 S[0] = Pw; 414 for (i = 1 ; i < T ; i++) { 415 S[i] = S[i-1] + Qw; 416 } 418 5.5 Mix in the secret key 420 This step mixes the secret key, K, into the expanded key, S. First 421 the number of iterations of the mixing function, k, is set to three 422 times the maximum of the number of initialized elements of L, 423 called LL, and the number of elements in S, called T. Each 424 iteration is similar to an interation of the encryption inner loop 425 in that two variables A and B are updated by the first and second 426 halves of the iteration. 428 Initially A and B are zero as are the indexes into the S array, i, 429 and the L array, j. In the first half of the iteration, a partial 430 result is computed by summing S[i], A and B. The new value for A 431 is this partial result rotated left three bits. The A value is 432 then placed into S[i]. The second half of the iteration computes a 433 second partial result that is the sum of L[j], A and B. The second 434 partial result is then rotated left by A+B bit positions and set to 435 be the new value for B. The new B value is then placed into L[j]. 436 At the end of the iteration, i and j are incremented modulo the 437 size of their respective arrays. In C code: 439 i = j = 0; 440 A = B = 0; 441 if (LL > T) 442 k = 3 * LL; /* Secret key len > expanded key. */ 443 else 444 k = 3 * T; /* Secret key len < expanded key. */ 445 for ( ; k > 0 ; k--) { 446 A = ROTL(S[i] + A + B, 3, W); 447 S[i] = A; 448 B = ROTL(L[j] + A + B, A + B, W); 449 L[j] = B; 450 i = (i + 1) % T; 451 j = (j + 1) % LL; 452 } 453 return; 454 } /* End of RC5_Key_Expand */ 455 draft RC5, RC5-CBC RC5-CBC-Pad, and RC5-CTS March 1996 457 6. Description of RC5 Block Cipher 459 This section describes the RC5 block cipher by explaining the steps 460 required to perform an encryption of a single input block. The 461 decryption process is the reverse of these steps so it will not be 462 explained. The RC5 cipher is parameterized by a version number, V, 463 a round count, R, and a word size in bits, W. This description 464 corresponds to original version of RC5 (V = 16 decimal) and covers 465 any positive value for R and the values 16, 32, and 64 for W. 467 The inputs to this process are the expanded key table, S, the 468 number of rounds, R, the input buffer pointer, in, and the output 469 buffer pointer, out. A possible C code procedure header for this 470 would be: 472 void RC5_Block_Encrypt (S, R, in, out) 473 RC5_WORD *S; 474 int R; 475 char *in; 476 char *out; 477 { 479 6.1 Loading A and B values 481 This step converts input bytes into two unsigned integers called A 482 and B. When RC5 is used as a 64 bit block cipher A and B are 32 483 bit values. The first input byte becomes the least significant 484 byte of A, the fourth input byte becomes the most significant byte 485 of A, the fifth input byte becomes the least significant byte of B 486 and the last input byte becomes the most significant byte of B. 487 This conversion can be very efficient for little-endian processors 488 such as the Intel family. In C code this could be expressed as: 490 int i; 491 RC5_WORD A, B; 493 A = in[0] & 0xFF; 494 A += (in[1] & 0xFF) << 8; 495 A += (in[2] & 0xFF) << 16; 496 A += (in[3] & 0xFF) << 24; 497 B = in[4] & 0xFF; 498 B += (in[5] & 0xFF) << 8; 499 B += (in[6] & 0xFF) << 16; 500 B += (in[7] & 0xFF) << 24; 501 draft RC5, RC5-CBC RC5-CBC-Pad, and RC5-CTS March 1996 503 6.2 Iterating the round function 505 This step mixes the expanded key with the input to perform the 506 fundamental encryption operation. The first two words of the 507 expanded key are added to A and B respectively, and then the round 508 function is repeated R times. 510 The first half of the round function computes a new value for A 511 based on the values of A, B, and the next unused word in the 512 expanded key table. Specifically, A is XOR'ed with B and then this 513 first partial result is rotated to the left by an amount specified 514 by B to form the second partial result. The rotation is performed 515 on a W bit boundary (i.e., 32 bit rotation for the version of RC5 516 that has a 64 bit block size). The actual rotation amount only 517 depends on the least significant log base-2 of W bits of B. The 518 next unused word of the expanded key table is then added to the 519 second partial result and this becomes the new value for A. 521 The second half of the round function is identical except the roles 522 of A and B are switched. Specifically, B is exclusive or'ed with A 523 and then this first partial result is rotated to the left by an 524 amount specified by A to form the second partial result. The next 525 unused word of the expanded key table is then added to the second 526 partial result and this becomes the new value for B. 528 One way to express this in C code is: 530 A = A + S[0]; 531 B = B + S[1]; 532 for (i = 1 ; i <= R ; i++) { 533 A = A ^ B; 534 A = ROTL(A, B, W) + S[2*i]; 535 B = B ^ A; 536 B = ROTL(B, A, W) + S[(2*i)+1]; 537 } 539 6.3 Storing the A and B values 541 The final step is to convert A and B back into a sequence of bytes. 542 This is the inverse of the load operation. An expression of this 543 in C code could be: 545 out[0] = (A >> 0) & 0xFF; 546 out[1] = (A >> 8) & 0xFF; 547 out[2] = (A >> 16) & 0xFF; 548 out[3] = (A >> 24) & 0xFF; 549 out[4] = (B >> 0) & 0xFF; 550 out[5] = (B >> 8) & 0xFF; 551 out[6] = (B >> 16) & 0xFF; 552 out[7] = (B >> 24) & 0xFF; 553 return; 554 } /* End of RC5_Block_Encrypt */ 555 draft RC5, RC5-CBC RC5-CBC-Pad, and RC5-CTS March 1996 557 7. Description of RC5-CBC and RC5-CBC-Pad 559 This section describes the CBC and CBC-Pad modes of the RC5 cipher. 560 This description is based on the RC5 key objects and RC5 block 561 cipher described earlier. 563 7.1 Creating cipher objects 565 The cipher object needs to keep track of the padding mode, the 566 number of rounds, the expanded key, the initialization vector, the 567 CBC chaining block, and an input buffer. A possible structure 568 definition for this in C code would be: 570 /* Definition of the RC5 CBC algorithm object. 571 */ 572 typedef struct rc5CBCAlg 573 { 574 int Pad; /* 1 = RC5-CBC-Pad, 0 = RC5-CBC. */ 575 int R; /* Number of rounds. */ 576 RC5_WORD *S; /* Expanded key. */ 577 unsigned char I[BB]; /* Initialization vector. */ 578 unsigned char chainBlock[BB]; 579 unsigned char inputBlock[BB]; 580 int inputBlockIndex; /* Next inputBlock byte. */ 581 } rc5CBCAlg; 582 draft RC5, RC5-CBC RC5-CBC-Pad, and RC5-CTS March 1996 584 To create a cipher algorithm object, the parameters must be checked 585 and then space allocated for the expanded key table. The expanded 586 key is initialized using the method described earlier. Finally, 587 the state variables (padding mode, number of rounds, and the input 588 buffer) are set to their initial values. In C this could be 589 accomplished by: 591 /* Allocate and initialize the RC5 CBC algorithm object. 592 * Return 0 if problems. 593 */ 594 rc5CBCAlg *RC5_CBC_Create (Pad, R, Version, bb, I) 595 int Pad; /* 1 = RC5-CBC-Pad, 0 = RC5-CBC. */ 596 int R; /* Number of rounds. */ 597 int Version; /* RC5 version number. */ 598 int bb; /* Bytes per RC5 block == IV len. */ 599 char *I; /* CBC IV, bb bytes long. */ 600 { 601 rc5CBCAlg *pAlg; 602 int index; 604 if ((Version != RC5_FIRST_VERSION) || 605 (bb != BB) || (R < 0) || (255 < R)) 606 return ((rc5CBCAlg *) 0); 607 pAlg = (rc5CBCAlg *) malloc (sizeof(*pAlg)); 608 if (pAlg == ((rc5CBCAlg *) 0)) 609 return ((rc5CBCAlg *) 0); 610 pAlg->S = (RC5_WORD *) malloc (BB * (R + 1)); 611 if (pAlg->S == ((RC5_WORD *) 0)) { 612 free (pAlg); 613 return ((rc5CBCAlg *) 0); 614 } 615 pAlg->Pad = Pad; 616 pAlg->R = R; 617 pAlg->inputBlockIndex = 0; 618 for (index = 0 ; index < BB ; index++) 619 pAlg->I[index] = I[index]; 620 return (pAlg); 621 } 622 draft RC5, RC5-CBC RC5-CBC-Pad, and RC5-CTS March 1996 624 7.2 Destroying cipher objects 626 Destroying the cipher object is the inverse of creating it with 627 care being take to zero memory before returning it to the memory 628 manager. In C this could be accomplished by: 630 /* Zero and free an RC5 algorithm object. 631 */ 632 void RC5_CBC_Destroy (pAlg) 633 rc5CBCAlg *pAlg; 634 { 635 RC5_WORD *to; 636 int count; 638 if (pAlg == ((rc5CBCAlg *) 0)) 639 return; 640 if (pAlg->S == ((RC5_WORD *) 0)) 641 return; 642 to = pAlg->S; 643 for (count = 0 ; count < (1 + pAlg->R) ; count++) 644 { 645 *to++ = 0; /* Two expanded key words per round. */ 646 *to++ = 0; 647 } 648 free (pAlg->S); 649 for (count = 0 ; count < BB ; count++) 650 { 651 pAlg->I[count] = (unsigned char) 0; 652 pAlg->inputBlock[count] = (unsigned char) 0; 653 pAlg->chainBlock[count] = (unsigned char) 0; 654 } 655 pAlg->Pad = 0; 656 pAlg->R = 0; 657 pAlg->inputBlockIndex = 0; 658 free (pAlg); 659 } 660 draft RC5, RC5-CBC RC5-CBC-Pad, and RC5-CTS March 1996 662 7.3 Setting the IV for cipher objects 664 For CBC cipher objects, the state of the algorithm depends on the 665 expanded key, the CBC chain block, and any internally buffered 666 input. Often the same key is used with many messages that each 667 have a unique initialization vector. To avoid the overhead of 668 creating a new cipher object, it makes more sense to provide an 669 operation that allows the caller to change the initialization 670 vector for an existing cipher object. In C this could be 671 accomplished by the following code: 673 /* Setup a new initialization vector for a CBC operation 674 * and reset the CBC object. 675 * This can be called after Final without needing to 676 * call Init or Create again. 677 * Return zero if problems. 678 */ 679 int RC5_CBC_SetIV (pAlg, I) 680 rc5CBCAlg *pAlg; 681 char *I; /* CBC Initialization vector, BB bytes. */ 682 { 683 int index; 685 pAlg->inputBlockIndex = 0; 686 for (index = 0 ; index < BB ; index++) 687 { 688 pAlg->I[index] = pAlg->chainBlock[index] = I[index]; 689 pAlg->inputBlock[index] = (unsigned char) 0; 690 } 691 return (1); 692 } 693 draft RC5, RC5-CBC RC5-CBC-Pad, and RC5-CTS March 1996 695 7.4 Binding a key to a cipher object 697 The operation that binds a key to a cipher object performs the key 698 expansion. Key expansion could be an operation on keys, but that 699 would not work correctly for ciphers that modify the expanded key 700 as they operate. After expanding the key, this operation must 701 initialize the CBC chain block from the initialization vector and 702 prepare the input buffer to receive the first character. In C this 703 could be done by: 705 /* Initialize the encryption object with the given key. 706 * After this routine, the caller frees the key object. 707 * The IV for this CBC object can be changed by calling 708 * the SetIV routine. The only way to change the key is 709 * to destroy the CBC object and create a new one. 710 * Return zero if problems. 711 */ 712 int RC5_CBC_Encrypt_Init (pAlg, pKey) 713 rc5CBCAlg *pAlg; 714 rc5UserKey *pKey; 715 { 716 if ((pAlg == ((rc5CBCAlg *) 0)) || 717 (pKey == ((rc5UserKey *) 0))) 718 return (0); 719 RC5_Key_Expand (Key->keyLength, pKey->keyBytes, 720 pAlg->R, pAlg->S); 721 return (RC5_CBC_SetIV(pAlg, pAlg->I)); 722 } 723 draft RC5, RC5-CBC RC5-CBC-Pad, and RC5-CTS March 1996 725 7.5 Processing part of a message 727 The encryption process described here uses the Init-Update-Final 728 paradigm. The update operation can be performed on a sequence of 729 message parts in order to incrementally produce the ciphertext. 730 After the last part is processed, the Final operation is called to 731 pick up any plaintext bytes or padding that are buffered inside the 732 cipher object. An appropriate procedure header for this operation 733 would be: 735 /* Encrypt a buffer of plaintext. 736 * The plaintext and ciphertext buffers can be the same. 737 * The byte len of the ciphertext is put in *pCipherLen. 738 * Call this multiple times passing successive 739 * parts of a large message. 740 * After the last part has been passed to Update, 741 * call Final. 742 * Return zero if problems like output buffer too small. 743 */ 744 int RC5_CBC_Encrypt_Update (pAlg, N, P, 745 pCipherLen, maxCipherLen, C) 746 rc5CBCAlg *pAlg; /* Cipher algorithm object. */ 747 int N; /* Byte length of P. */ 748 char *P; /* Plaintext buffer. */ 749 int *pCipherLen;/* Gets byte len of C. */ 750 int maxCipherLen; /* Size of C. */ 751 char *C; /* Ciphertext buffer. */ 752 { 754 7.5.1 Output buffer size check. 756 The first step of plaintext processing is to make sure that the 757 output buffer is big enough hold the ciphertext. The ciphertext 758 will be produced in multiples of the block size and depends on the 759 number of plaintext characters passed to this operation plus any 760 characters that are in the cipher object's internal buffer. In C 761 code this would be: 763 int plainIndex, cipherIndex, j; 765 /* Check size of the output buffer. */ 766 if (maxCipherLen < (((pAlg->inputBlockIndex+N)/BB)*BB)) 767 { 768 *pCipherLen = 0; 769 return (0); 770 } 771 draft RC5, RC5-CBC RC5-CBC-Pad, and RC5-CTS March 1996 773 7.5.2 Divide plaintext into blocks 775 The next step is to add characters to the internal buffer until a 776 full block has been constructed. When that happens, the buffer 777 pointers are reset and the input buffer is exclusive-or'ed (XORed) 778 with the CBC chaining block. The byte order of the chaining block 779 is the same as the input block. For example, the ninth input byte 780 is XOR'ed with the first ciphertext byte. The result is then 781 passed to the RC5 block cipher which was described earlier. To 782 reduce data movement and byte alignment problems, the output of RC5 783 can be directly written into the CBC chaining block. Finally, this 784 output is copied to the ciphertext buffer provided by the user. 785 Before returning, the actual size of the ciphertext is passed back 786 to the caller. In C, this step can be performed by: 788 plainIndex = cipherIndex = 0; 789 while (plainIndex < N) 790 { 791 if (pAlg->inputBlockIndex < BB) 792 { 793 pAlg->inputBlock[pAlg->inputBlockIndex] 794 = P[plainIndex]; 795 pAlg->inputBlockIndex++; 796 plainIndex++; 797 } 798 if (pAlg->inputBlockIndex == BB) 799 { /* Have a complete input block, process it. */ 800 pAlg->inputBlockIndex = 0; 801 for (j = 0 ; j < BB ; j++) 802 { /* XOR in the chain block. */ 803 pAlg->inputBlock[j] = pAlg->inputBlock[j] 804 ^ pAlg->chainBlock[j]; 805 } 806 RC5_Block_Encrypt(pAlg->S, pAlg->R 807 pAlg->inputBlock, 808 pAlg->chainBlock); 809 for (j = 0 ; j < BB ; j++) 810 { /* Output the ciphertext. */ 811 C[cipherIndex] = pAlg->chainBlock[j]; 812 cipherIndex++; 813 } 814 } 815 } 816 *pCipherLen = cipherIndex; 817 return (1); 818 } /* End of RC5_CBC_Encrypt_Update */ 819 draft RC5, RC5-CBC RC5-CBC-Pad, and RC5-CTS March 1996 821 7.6 Final block processing 823 This step handles the last block of plaintext. For RC5-CBC, this 824 step just performs error checking to ensure that the plaintext 825 length was indeed a multiple of the block length. For RC5-CBC-Pad, 826 padding bytes are added to the plaintext. The pad bytes are all 827 the same and are set to a byte that represents the number of bytes 828 of padding. For example if there are eight bytes of padding, the 829 bytes will all have the hexadecimal value 0x08. There will be 830 between one and BB padding bytes, inclusive. In C code this would 831 be: 833 /* Produce the final block of ciphertext including any 834 * padding, and then reset the algorithm object. 835 * Return zero if problems. 836 */ 837 int RC5_CBC_Encrypt_Final (pAlg, pCipherLen, maxCipherLen, C) 838 rc5CBCAlg *pAlg; 839 int *pCipherLen; /* Gets byte len of C. */ 840 int maxCipherLen; /* Len of C buffer. */ 841 char *C; /* Ciphertext buffer. */ 842 { 843 int cipherIndex, j; 844 int padLength; 846 /* For non-pad mode error if input bytes buffered. */ 847 *pCipherLen = 0; 848 if ((pAlg->Pad == 0) && (pAlg->inputBlockIndex != 0)) 849 return (0); 851 if (pAlg->Pad == 0) 852 return (1); 853 if (maxCipherLen < BB) 854 return (0); 856 padLength = BB - pAlg->inputBlockIndex; 857 for (j = 0 ; j < padLength ; j++) 858 { 859 pAlg->inputBlock[pAlg->inputBlockIndex] 860 = (unsigned char) padLength; 861 pAlg->inputBlockIndex++; 862 } 863 draft RC5, RC5-CBC RC5-CBC-Pad, and RC5-CTS March 1996 865 for (j = 0 ; j < BB ; j++) 866 { /* XOR the chain block into the plaintext block. */ 867 pAlg->inputBlock[j] = pAlg->inputBlock[j] 868 ^ pAlg->chainBlock[j]; 869 } 870 RC5_Block_Encrypt(pAlg->S, pAlg->R, 871 pAlg->inputBlock, pAlg->chainBlock); 872 cipherIndex = 0; 873 for (j = 0 ; j < BB ; j++) 874 { /* Output the ciphertext. */ 875 C[cipherIndex] = pAlg->chainBlock[j]; 876 cipherIndex++; 877 } 878 *pCipherLen = cipherIndex; 880 /* Reset the CBC algorithm object. */ 881 return (RC5_CBC_SetIV(pAlg, pAlg->I)); 882 } /* End of RC5_CBC_Encrypt_Final */ 883 draft RC5, RC5-CBC RC5-CBC-Pad, and RC5-CTS March 1996 885 8. Description of RC5-CTS 887 The Cipher Text Stealing (CTS) mode for block ciphers is described 888 by Schneier on pages 195 and 196 of [6]. This mode handles any 889 length of plaintext and produces ciphertext whose length matches 890 the plaintext length. The CTS mode behaves like the CBC mode for 891 all but the last two blocks of the plaintext. The following steps 892 describe how to handle the last two portions of the plaintext, 893 called Pn-1 and Pn, where the length of Pn-1 equals the block size, 894 BB, and the length of the last block, Pn, is Ln bytes. Notice that 895 Ln ranges from 1 to BB, inclusive, so Pn could in fact be a 896 complete block. 898 1. Exclusive-or Pn-1 with the previous ciphertext 899 block, Cn-2, to create Xn-1. 901 2. Encrypt Xn-1 to create En-1. 903 3. Select the first Ln bytes of En-1 to create Cn. 905 4. Pad Pn with zeros at the end to create P of length BB. 907 5. Exclusive-or En-1 with P to create to create Dn. 909 6. Encrypt Dn to create Cn-1 911 7. The last two parts of the ciphertext are Cn-1 and 912 Cn respectively. 914 To implement CTS encryption, the RC5-CTS object must hold on to 915 (buffer) at most 2*BB bytes of plaintext and process them specially 916 when the RC5_CTS_Encrypt_Final routine is called. 918 The following steps describe how to decrypt Cn-1 and Cn. 920 1. Decrypt Cn-1 to create Dn. 922 2. Pad Cn with zeros at the end to create C of length BB. 924 3. Exclusive-or Dn with C to create Xn. 926 4. Select the first Ln bytes of Xn to create Pn. 928 5. Append the tail (BB minus Ln) bytes of Xn to Cn 929 to create En. 931 6. Decrypt En to create Pn-1. 933 7. The last two parts of the plaintext are Pn-1 and 934 Pn respectively. 936 draft RC5, RC5-CBC RC5-CBC-Pad, and RC5-CTS March 1996 938 9. Test Program and Vectors 940 To help confirm the correctness of an implementation, this section 941 gives a test program and results from a set of test vectors. 943 9.1 Test Program 945 The following test program written in C reads test vectors from its 946 input stream and writes results on its output stream. The 947 following subsections give a set of test vectors for inputs and the 948 resulting outputs. 950 #include 952 #define BLOCK_LENGTH (8 /* bytes */) 953 #define MAX_KEY_LENGTH (64 /* bytes */) 954 #define MAX_PLAIN_LENGTH (128 /* bytes */) 955 #define MAX_CIPHER_LENGTH(MAX_PLAIN_LENGTH + BLOCK_LENGTH) 956 #define MAX_ROUNDS (20) 957 #define MAX_S_LENGTH (2 * (MAX_ROUNDS + 1)) 959 typedef struct test_vector 960 { 961 int padding_mode; 962 int rounds; 963 char keytext[2*MAX_KEY_LENGTH+1]; 964 int key_length; 965 char key[MAX_KEY_LENGTH]; 966 char ivtext[2*BLOCK_LENGTH+1]; 967 int iv_length; 968 char iv[BLOCK_LENGTH]; 969 char plaintext[2*MAX_PLAIN_LENGTH+1]; 970 int plain_length; 971 char plain[MAX_PLAIN_LENGTH]; 972 char ciphertext[2*MAX_CIPHER_LENGTH+1]; 973 int cipher_length; 974 char cipher[MAX_CIPHER_LENGTH]; 975 RC5_WORD S[MAX_S_LENGTH]; 976 } test_vector; 977 draft RC5, RC5-CBC RC5-CBC-Pad, and RC5-CTS March 1996 979 void show_banner() 980 { 981 (void) printf("RC5 CBC Tester.\n"); 982 (void) printf("Each input line should contain the following\n"); 983 (void) printf("test parameters separated by a single space:\n"); 984 (void) printf("- Padding mode flag. Use 1 for RC5_CBC_Pad, else 985 0.\n"); 986 (void) printf("- Number of rounds for RC5.\n"); 987 (void) printf("- Key bytes in hexadecimal. Two characters per 988 byte like '01'.\n"); 989 (void) printf("- IV bytes in hexadecimal. Must be 16 hex 990 characters.\n"); 991 (void) printf("- Plaintext bytes in hexadecimal.\n"); 992 (void) printf("An end of file or format error terminates the 993 tester.\n"); 994 (void) printf("\n"); 995 } 996 draft RC5, RC5-CBC RC5-CBC-Pad, and RC5-CTS March 1996 998 /* Convert a buffer from ascii hex to bytes. 999 * Set pTo_length to the byte length of the result. 1000 * Return 1 if everything went OK. 1001 */ 1002 int hex_to_bytes (from, to, pTo_length) 1003 char *from, *to; 1004 int *pTo_length; 1005 { 1006 char *pHex; /* Ptr to next hex character. */ 1007 char *pByte; /* Ptr to next resulting byte. */ 1008 int byte_length = 0; 1009 int value; 1011 pByte = to; 1012 for (pHex = from ; *pHex != 0 ; pHex += 2) { 1013 if (1 != sscanf(pHex, "%02x", &value)) 1014 return (0); 1015 *pByte++ = ((char)(value & 0xFF)); 1016 byte_length++; 1017 } 1018 *pTo_length = byte_length; 1019 return (1); 1020 } 1022 /* Convert a buffer from bytes to ascii hex. 1023 * Return 1 if everything went OK. 1024 */ 1025 int bytes_to_hex (from, from_length, to) 1026 char *from, *to; 1027 int from_length; 1028 { 1029 char *pHex; /* Ptr to next hex character. */ 1030 char *pByte; /* Ptr to next resulting byte. */ 1031 int value; 1033 pHex = to; 1034 for (pByte = from ; from_length > 0 ; from_length--) { 1035 value = *pByte++ & 0xFF; 1036 (void) sprintf(pHex, "%02x", value); 1037 pHex += 2; 1038 } 1039 return (1); 1040 } 1041 draft RC5, RC5-CBC RC5-CBC-Pad, and RC5-CTS March 1996 1043 /* Return 1 if get a valid test vector. */ 1044 int get_test_vector(ptv) 1045 test_vector *ptv; 1046 { 1047 if (1 != scanf("%d", &ptv->padding_mode)) 1048 return (0); 1049 if (1 != scanf("%d", &ptv->rounds)) 1050 return (0); 1051 if ((ptv->rounds < 0) || (MAX_ROUNDS < ptv->rounds)) 1052 return (0); 1053 if (1 != scanf("%s", &ptv->keytext)) 1054 return (0); 1055 if (1 != hex_to_bytes(ptv->keytext, ptv->key, 1056 &ptv->key_length)) 1057 return (0); 1058 if (1 != scanf("%s", &ptv->ivtext)) 1059 return (0); 1060 if (1 != hex_to_bytes(ptv->ivtext, ptv->iv, 1061 &ptv->iv_length)) 1062 return (0); 1063 if (BLOCK_LENGTH != ptv->iv_length) 1064 return (0); 1065 if (1 != scanf("%s", &ptv->plaintext)) 1066 return (0); 1067 if (1 != hex_to_bytes(ptv->plaintext, ptv->plain, 1068 &ptv->plain_length)) 1069 return (0); 1070 return (1); 1071 } 1072 draft RC5, RC5-CBC RC5-CBC-Pad, and RC5-CTS March 1996 1074 void run_test (ptv) 1075 test_vector *ptv; 1076 { 1077 rc5UserKey *pKey; 1078 rc5CBCAlg *pAlg; 1079 int numBytesOut; 1081 pKey = RC5_Key_Create (); 1082 RC5_Key_Set (pKey, ptv->key_length, ptv->key); 1084 pAlg = RC5_CBC_Create (ptv->padding_mode, 1085 ptv->rounds, 1086 RC5_FIRST_VERSION, 1087 BB, 1088 ptv->iv); 1089 (void) RC5_CBC_Encrypt_Init (pAlg, pKey); 1090 ptv->cipher_length = 0; 1091 (void) RC5_CBC_Encrypt_Update (pAlg, 1092 ptv->plain_length, ptv->plain, 1093 &(numBytesOut), 1094 MAX_CIPHER_LENGTH - ptv->cipher_length, 1095 &(ptv->cipher[ptv->cipher_length])); 1096 ptv->cipher_length += numBytesOut; 1097 (void) RC5_CBC_Encrypt_Final (pAlg, 1098 &(numBytesOut), 1099 MAX_CIPHER_LENGTH - ptv->cipher_length, 1100 &(ptv->cipher[ptv->cipher_length])); 1101 ptv->cipher_length += numBytesOut; 1102 bytes_to_hex (ptv->cipher, ptv->cipher_length, 1103 ptv->ciphertext); 1104 RC5_Key_Destroy (pKey); 1105 RC5_CBC_Destroy (pAlg); 1106 } 1107 draft RC5, RC5-CBC RC5-CBC-Pad, and RC5-CTS March 1996 1109 void show_results (ptv) 1110 test_vector *ptv; 1111 { 1112 if (ptv->padding_mode) 1113 printf ("RC5_CBC_Pad "); 1114 else 1115 printf ("RC5_CBC "); 1116 printf ("R = %2d ", ptv->rounds); 1117 printf ("Key = %s ", ptv->keytext); 1118 printf ("IV = %s ", ptv->ivtext); 1119 printf ("P = %s ", ptv->plaintext); 1120 printf ("C = %s", ptv->ciphertext); 1121 printf ("\n"); 1122 } 1124 int main(argc, argv) 1125 int argc; 1126 char *argv[]; 1127 { 1128 test_vector tv; 1129 test_vector *ptv = &tv; 1131 show_banner(); 1132 while (get_test_vector(ptv)) { 1133 run_test(ptv); 1134 show_results(ptv); 1135 } 1136 return (0); 1137 } 1138 draft RC5, RC5-CBC RC5-CBC-Pad, and RC5-CTS March 1996 1140 9.2 Test vectors 1142 The following text is an input file to the test program presented 1143 in the previous subsection. The output is given in the next 1144 subsection. 1146 0 00 00 0000000000000000 0000000000000000 1147 0 00 00 0000000000000000 ffffffffffffffff 1148 0 00 00 0000000000000001 0000000000000000 1149 0 00 00 0000000000000000 0000000000000001 1150 0 00 00 0102030405060708 1020304050607080 1151 0 01 11 0000000000000000 0000000000000000 1152 0 02 00 0000000000000000 0000000000000000 1153 0 02 00000000 0000000000000000 0000000000000000 1154 0 08 00 0000000000000000 0000000000000000 1155 0 08 00 0102030405060708 1020304050607080 1156 0 12 00 0102030405060708 1020304050607080 1157 0 16 00 0102030405060708 1020304050607080 1158 0 08 01020304 0000000000000000 ffffffffffffffff 1159 0 12 01020304 0000000000000000 ffffffffffffffff 1160 0 16 01020304 0000000000000000 ffffffffffffffff 1161 0 12 0102030405060708 0000000000000000 ffffffffffffffff 1162 0 08 0102030405060708 0102030405060708 1020304050607080 1163 0 12 0102030405060708 0102030405060708 1020304050607080 1164 0 16 0102030405060708 0102030405060708 1020304050607080 1165 0 08 01020304050607081020304050607080 1166 0102030405060708 1020304050607080 1167 0 12 01020304050607081020304050607080 1168 0102030405060708 1020304050607080 1169 0 16 01020304050607081020304050607080 1170 0102030405060708 1020304050607080 1172 0 12 0102030405 0000000000000000 ffffffffffffffff 1173 0 08 0102030405 0000000000000000 ffffffffffffffff 1174 0 08 0102030405 7875dbf6738c6478 0808080808080808 1175 1 08 0102030405 0000000000000000 ffffffffffffffff 1177 0 08 0102030405 0000000000000000 0000000000000000 1178 0 08 0102030405 7cb3f1df34f94811 1122334455667701 1180 1 08 0102030405 0000000000000000 1181 ffffffffffffffff7875dbf6738c647811223344556677 1182 draft RC5, RC5-CBC RC5-CBC-Pad, and RC5-CTS March 1996 1184 9.3 Test results 1186 The following text is the output produced by the test program run 1187 on the inputs given in the previous subsection. 1189 RC5 CBC Tester. 1190 Each input line should contain the following 1191 test parameters separated by a single space: 1192 - Padding mode flag. Use 1 for RC5_CBC_Pad, else 0. 1193 - Number of rounds for RC5. 1194 - Key bytes in hexadecimal. Two characters per byte 1195 like '01'. 1196 - IV bytes in hexadecimal. Must be 16 hex characters. 1197 - Plaintext bytes in hexadecimal. 1198 An end of file or format error terminates the tester. 1200 RC5_CBC R = 0 Key = 00 IV = 0000000000000000 1201 P = 0000000000000000 C = 7a7bba4d79111d1e 1202 RC5_CBC R = 0 Key = 00 IV = 0000000000000000 1203 P = ffffffffffffffff C = 797bba4d78111d1e 1204 RC5_CBC R = 0 Key = 00 IV = 0000000000000001 1205 P = 0000000000000000 C = 7a7bba4d79111d1f 1206 RC5_CBC R = 0 Key = 00 IV = 0000000000000000 1207 P = 0000000000000001 C = 7a7bba4d79111d1f 1208 RC5_CBC R = 0 Key = 00 IV = 0102030405060708 1209 P = 1020304050607080 C = 8b9ded91ce7794a6 1210 RC5_CBC R = 1 Key = 11 IV = 0000000000000000 1211 P = 0000000000000000 C = 2f759fe7ad86a378 1212 RC5_CBC R = 2 Key = 00 IV = 0000000000000000 1213 P = 0000000000000000 C = dca2694bf40e0788 1214 RC5_CBC R = 2 Key = 00000000 IV = 0000000000000000 1215 P = 0000000000000000 C = dca2694bf40e0788 1216 RC5_CBC R = 8 Key = 00 IV = 0000000000000000 1217 P = 0000000000000000 C = dcfe098577eca5ff 1218 RC5_CBC R = 8 Key = 00 IV = 0102030405060708 1219 P = 1020304050607080 C = 9646fb77638f9ca8 1220 RC5_CBC R = 12 Key = 00 IV = 0102030405060708 1221 P = 1020304050607080 C = b2b3209db6594da4 1222 RC5_CBC R = 16 Key = 00 IV = 0102030405060708 1223 P = 1020304050607080 C = 545f7f32a5fc3836 1224 RC5_CBC R = 8 Key = 01020304 IV = 0000000000000000 1225 P = ffffffffffffffff C = 8285e7c1b5bc7402 1226 RC5_CBC R = 12 Key = 01020304 IV = 0000000000000000 1227 P = ffffffffffffffff C = fc586f92f7080934 1228 RC5_CBC R = 16 Key = 01020304 IV = 0000000000000000 1229 P = ffffffffffffffff C = cf270ef9717ff7c4 1230 RC5_CBC R = 12 Key = 0102030405060708 IV = 0000000000000000 1231 P = ffffffffffffffff C = e493f1c1bb4d6e8c 1232 draft RC5, RC5-CBC RC5-CBC-Pad, and RC5-CTS March 1996 1234 RC5_CBC R = 8 Key = 0102030405060708 IV = 0102030405060708 1235 P = 1020304050607080 C = 5c4c041e0f217ac3 1236 RC5_CBC R = 12 Key = 0102030405060708 IV = 0102030405060708 1237 P = 1020304050607080 C = 921f12485373b4f7 1238 RC5_CBC R = 16 Key = 0102030405060708 IV = 0102030405060708 1239 P = 1020304050607080 C = 5ba0ca6bbe7f5fad 1240 RC5_CBC R = 8 Key = 01020304050607081020304050607080 1241 IV = 0102030405060708 1242 P = 1020304050607080 C = c533771cd0110e63 1243 RC5_CBC R = 12 Key = 01020304050607081020304050607080 1244 IV = 0102030405060708 1245 P = 1020304050607080 C = 294ddb46b3278d60 1246 RC5_CBC R = 16 Key = 01020304050607081020304050607080 1247 IV = 0102030405060708 1248 P = 1020304050607080 C = dad6bda9dfe8f7e8 1249 RC5_CBC R = 12 Key = 0102030405 IV = 0000000000000000 1250 P = ffffffffffffffff C = 97e0787837ed317f 1251 RC5_CBC R = 8 Key = 0102030405 IV = 0000000000000000 1252 P = ffffffffffffffff C = 7875dbf6738c6478 1253 RC5_CBC R = 8 Key = 0102030405 IV = 7875dbf6738c6478 1254 P = 0808080808080808 C = 8f34c3c681c99695 1255 RC5_CBC_Pad R = 8 Key = 0102030405 IV = 0000000000000000 1256 P = ffffffffffffffff C = 7875dbf6738c64788f34c3c681c99695 1257 RC5_CBC R = 8 Key = 0102030405 IV = 0000000000000000 1258 P = 0000000000000000 C = 7cb3f1df34f94811 1259 RC5_CBC R = 8 Key = 0102030405 IV = 7cb3f1df34f94811 1260 P = 1122334455667701 C = 7fd1a023a5bba217 1261 RC5_CBC_Pad R = 8 Key = 0102030405 IV = 0000000000000000 1262 P = ffffffffffffffff7875dbf6738c647811223344556677 1263 C = 7875dbf6738c64787cb3f1df34f948117fd1a023a5bba217 1264 draft RC5, RC5-CBC RC5-CBC-Pad, and RC5-CTS March 1996 1266 10. Security Considerations 1268 The RC5 cipher is relatively new so critical reviews are still 1269 being performed. However, the cipher's simple structure makes it 1270 easy to analyze and hopefully easier to assess its strength. 1271 Reviews so far are very promising. 1273 Early results [1] suggest that for RC5 with a 64 bit block size (32 1274 bit word size), 12 rounds will suffice to resist linear and 1275 differential cyptanalysis. The 128 bit block version has not been 1276 studied as much as the 64 bit version, but it appears that 16 1277 rounds would be an appropriate minimum. Block sizes less than 64 1278 bits are academically interesting but should not be used for 1279 cryptographic security. Greater security can be achieved by 1280 increasing the number of rounds at the cost of decreasing the 1281 throughput of the cipher. 1283 The length of the secret key helps determine the cipher's 1284 resistance to brute force key searching attacks. A key length of 1285 128 bits should give adequate protection against brute force key 1286 searching by a well funded opponent for a couple decades [7]. For 1287 RC5 with 12 rounds, the key setup time and data encryption time are 1288 the same for all key lengths less than 832 bits, so there is no 1289 performance reason for choosing short keys. For larger keys, the 1290 key expansion step will run slower because the user key table, L, 1291 will be longer than the expanded key table, S. However, the 1292 encryption time will be unchanged since it is only a function of 1293 the number of rounds. 1295 To comply with export regulations it may be necessary to choose 1296 keys that only have 40 unknown bits. A poor way to do this would 1297 be to choose a simple 5 byte key. This should be avoided because 1298 it would be easy for an opponent to pre-compute key searching 1299 information. Another common mechanism is to pick a 128 bit key and 1300 publish the first 88 bits. This method reveals a large number of 1301 the entries in the user key table, L, and the question of whether 1302 RC5 key expansion provides adequate security in this situation has 1303 not been studied, though it may be fine. A conservative way to 1304 conform to a 40 bit limitation is to pick a seed value of 128 bits, 1305 publish 88 bits of this seed, run the entire seed through a hash 1306 function like MD5 [4], and use the 128 bit output of the hash 1307 function as the RC5 key. 1309 In the case of 40 unknown key bits with 88 known key bits (i.e., 88 1310 salt bits) there should still be 12 or more rounds for the 64 bit 1311 block version of RC5, otherwise the value of adding salt bits to 1312 the key is likely to be lost. 1314 draft RC5, RC5-CBC RC5-CBC-Pad, and RC5-CTS March 1996 1316 The lifetime of the key also influences security. For high 1317 security applications, the key to any 64 bit block cipher should be 1318 changed after encrypting 2**32 blocks (2**64 blocks for a 128 bit 1319 block cipher). This helps to guard against linear and differential 1320 cryptanalysis. For the case of 64 bit blocks, this rule would 1321 recommend changing the key after 2**40 (i.e. 10**12) bytes are 1322 encrypted. See Schneier [6] page 183 for further discussion. 1324 11. ASN.1 Identifiers 1326 For applications that use ASN.1 descriptions, it is necessary to 1327 define the algorithm identifier for these ciphers along with their 1328 parameter block formats. The ASN.1 definition of an algorithm 1329 identifier already exists and is listed below for reference. 1331 AlgorithmIdentifier ::= SEQUENCE { 1332 algorithm OBJECT IDENTIFIER, 1333 parameters ANY DEFINED BY algorithm OPTIONAL 1334 } 1336 The values for the algorithm field are: 1338 RC5_CBC OBJECT IDENTIFIER ::= 1339 { iso (1) member-body (2) US (840) rsadsi (113549) 1340 encryptionAlgorithm (3) RC5CBC (8) } 1342 RC5_CBC_Pad OBJECT IDENTIFIER ::= 1343 { iso (1) member-body (2) US (840) rsadsi (113549) 1344 encryptionAlgorithm (3) RC5CBCPAD (9) } 1346 The structure of the parameters field for these algorithms is given 1347 below. NOTE: if the iv field is not included, then the 1348 initialization vector defaults to a block of zeros whose size 1349 depends on the blockSizeInBits field. 1351 RC5_CBC_Parameters ::= SEQUENCE { 1352 version INTEGER (v1_0(16)), 1353 rounds INTEGER (8..127), 1354 blockSizeInBits INTEGER (64, 128), 1355 iv OCTET STRING OPTIONAL 1356 } 1357 draft RC5, RC5-CBC RC5-CBC-Pad, and RC5-CTS March 1996 1359 References 1361 [1] Kaliski, Burton S., and Yinqun Lisa Yin, "On Differential and 1362 Linear Cryptanalysis of the RC5 Encryption Algorithm", In Advances 1363 in Cryptology - Crypto '95, pages 171-184, Springer-Verlag, New 1364 York, 1995. 1366 [2] Rivest, Ronald L., "The RC5 Encryption Algorithm", In 1367 Proceedings of the Second International Workshop on Fast Software 1368 Encryption, pages 86-96, Leuven Belgium, December 1994. 1370 [3] Rivest, Ronald L., "RC5 Encryption Algorithm", In Dr. Dobbs 1371 Journal, number 226, pages 146-148, January 1995. 1373 [4] Rivest, Ronald L., "The MD5 Message-Digest Algorithm", RFC 1374 1321. 1376 [5] RSA Laboratories, "Public Key Cryptography Standards (PKCS)", 1377 RSA Data Security Inc. See ftp.rsa.com. 1379 [6] Schneier, Bruce, "Applied Cryptography", Second Edition, John 1380 Wiley and Sons, New York, 1996. Errata: on page 195, line 13, the 1381 reference number should be [402]. 1383 [7] Business Software Alliance, Matt Blaze et al., "Minimum Key 1384 Length for Symmetric Ciphers to Provide Adequate Commercial 1385 Security", http://www.bsa.org/bsa/cryptologists.html. 1387 [8] RSA Data Security Inc., "RC5 Reference Code in C", See the web 1388 site: www.rsa.com, for availability. Not available with the first 1389 draft of this document. 1391 Author's Address 1393 Robert W. Baldwin 1394 RSA Data Security, Inc. 1395 100 Marine Parkway 1396 Redwood City, CA 94065 1397 Phone: (415) 595-8782 1398 Fax: (415) 595-1873 1399 EMail: baldwin@rsa.com, or baldwin@lcs.mit.edu 1401 Ronald L. Rivest 1402 Massachusetts Institute of Technology 1403 Laboratory for Computer Science 1404 NE43-324 1405 545 Technology Square 1406 Cambridge, MA 02139-1986 1407 Phone: (617) 253-5880 1408 EMail: rivest@theory.lcs.mit.edu 1410 This is an internet-draft that expires on September 1, 1996.