idnits 2.17.1 draft-nakajima-camellia-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 12) being 59 lines 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.) ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- 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 (December 2003) is 7428 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: '0x3d' is mentioned on line 402, but not defined Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT M. Matsui 3 J. Nakajima 4 Mitsubishi Electric Corporation 5 Expires June 2004 S. Moriai 6 Sony Computer Entertainmemt Inc. 7 December 2003 9 A Description of the Camellia Encryption Algorithm 11 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 This document describes the Camellia encryption algorithm. Camellia 37 is a block cipher with 128-bit block size and 128-, 192-, and 38 256-bit keys. The algorithm description is presented together with 39 key scheduling part and data randomizing part. 41 Note: 42 This work was done when the second author worked for NTT. 44 1. Introduction 46 1.1 Camellia 48 Camellia was jointly developed by Nippon Telegraph and Telephone 49 Corporation and Mitsubishi Electric Corporation in 2000 51 [CamelliaSpec]. Camellia specifies the 128-bit block size and 128-, 52 192-, and 256-bit key sizes, the same interface as the Advanced 53 Encryption Standard (AES). Camellia is characterized by its 54 suitability for both software and hardware implementations as well 55 as its high level of security. From a practical viewpoint, it is 56 designed to enable flexibility in software and hardware 57 implementations on 32-bit processors widely used over the Internet 58 and many applications, 8-bit processors used in smart cards, 59 cryptographic hardware, embedded systems, and so on [CamelliaTech]. 60 Moreover, its key setup time is excellent, and its key agility is 61 superior to that of AES. 63 Camellia has been scrutinized by the wide cryptographic community 64 during several projects for evaluating crypto algorithms. In 65 particular, Camellia was selected as a recommended cryptographic 66 primitive by the EU NESSIE (New European Schemes for Signatures, 67 Integrity and Encryption) project [NESSIE] and also included in 68 the list of cryptographic techniques for Japanese e-Government 69 systems which were selected by the Japan CRYPTREC (Cryptography 70 Research and Evaluation Committees) [CRYPTREC]. 72 1.2 Terminology 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD 75 NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in 76 uppercase, as shown) are to be interpreted as described in 77 [RFC2119]. 79 2. Algorithm Description 81 Camellia can be divided into "key scheduling part" and "data 82 randomizing part". 84 2.1 Terminology 86 The following operators are used in this document to describe the 87 algorithm. 89 & bitwise AND operation. 90 | bitwise OR operation. 91 ^ bitwise exclusive-OR operation. 92 << logical left shift operation. 93 >> logical right shift operation. 94 <<< left rotation operation. 95 ~y bitwise complement of y. 96 0x hexadecimal representation. 98 Note that the logical left shift operation is done with the infinite 99 data width. 101 The constant values of MASK8, MASK32, MASK64, and MASK128 are defined 102 as follows. 104 MASK8 = 0xff; 105 MASK32 = 0xffffffff; 106 MASK64 = 0xffffffffffffffff; 107 MASK128 = 0xffffffffffffffffffffffffffffffff; 109 2.2 Key Scheduling Part 111 In the key schedule part of Camellia, the 128-bit variables of KL 112 and KR are defined as follows. For 128-bit keys, the 128-bit key K 113 is used as KL and KR is 0. For 192-bit keys, the leftmost 128-bits 114 of key K are used as KL and the concatenation of the rightmost 115 64-bits of K and the complement of the rightmost 64-bits of K are 116 used as KR. For 256-bit keys, the leftmost 128-bits of key K are 117 used as KL and the rightmost 128-bits of K are used as KR. 119 128-bit key K: 120 KL = K; KR = 0; 122 192-bit key K: 123 KL = K >> 64; 124 KR = ((K & MASK64) << 64) | (~(K & MASK64)); 126 256-bit key K: 127 KL = K >> 128; 128 KR = K & MASK128; 130 The 128-bit variables KA and KB are generated from KL and KR as 131 follows. Note that KB is used only if the length of the secret key 132 is 192 or 256 bits. D1 and D2 are 64-bit temporary variables. 134 D1 = (KL ^ KR) >> 64; 135 D2 = (KL ^ KR) & MASK64; 136 D2 = D2 ^ F(D1, Sigma1); 137 D1 = D1 ^ F(D2, Sigma2); 138 D1 = D1 ^ (KL >> 64); 139 D2 = D2 ^ (KL & MASK64); 140 D2 = D2 ^ F(D1, Sigma3); 141 D1 = D1 ^ F(D2, Sigma4); 142 KA = (D1 << 64) | D2; 143 D1 = (KA ^ KR) >> 64; 144 D2 = (KA ^ KR) & MASK64; 145 D2 = D2 ^ F(D1, Sigma5); 146 D1 = D1 ^ F(D2, Sigma6); 147 KB = (D1 << 64) | D2; 149 The 64-bit constants Sigma1, Sigma2, ..., Sigma6 are used as "keys" 150 in the Feistel network. These constant values are, in hexadecimal 151 notation, as follows. 153 Sigma1 = 0xA09E667F3BCC908B; 154 Sigma2 = 0xB67AE8584CAA73B2; 155 Sigma3 = 0xC6EF372FE94F82BE; 156 Sigma4 = 0x54FF53A5F1D36F1C; 157 Sigma5 = 0x10E527FADE682D1D; 158 Sigma6 = 0xB05688C2B3E6C1FD; 159 The 64-bit subkeys are generated by rotating KL, KR, KA and KB and 160 taking the left- or right-half of them. 162 For 128-bit keys, subkeys are generated as follows. 164 kw1 = (KL <<< 0) >> 64; 165 kw2 = (KL <<< 0) & MASK64; 166 k1 = (KA <<< 0) >> 64; 167 k2 = (KA <<< 0) & MASK64; 168 k3 = (KL <<< 15) >> 64; 169 k4 = (KL <<< 15) & MASK64; 170 k5 = (KA <<< 15) >> 64; 171 k6 = (KA <<< 15) & MASK64; 172 ke1 = (KA <<< 30) >> 64; 173 ke2 = (KA <<< 30) & MASK64; 174 k7 = (KL <<< 45) >> 64; 175 k8 = (KL <<< 45) & MASK64; 176 k9 = (KA <<< 45) >> 64; 177 k10 = (KL <<< 60) & MASK64; 178 k11 = (KA <<< 60) >> 64; 179 k12 = (KA <<< 60) & MASK64; 180 ke3 = (KL <<< 77) >> 64; 181 ke4 = (KL <<< 77) & MASK64; 182 k13 = (KL <<< 94) >> 64; 183 k14 = (KL <<< 94) & MASK64; 184 k15 = (KA <<< 94) >> 64; 185 k16 = (KA <<< 94) & MASK64; 186 k17 = (KL <<< 111) >> 64; 187 k18 = (KL <<< 111) & MASK64; 188 kw3 = (KA <<< 111) >> 64; 189 kw4 = (KA <<< 111) & MASK64; 191 For 192- and 256-bit keys, subkeys are generated as follows. 193 kw1 = (KL <<< 0) >> 64; 194 kw2 = (KL <<< 0) & MASK64; 195 k1 = (KB <<< 0) >> 64; 196 k2 = (KB <<< 0) & MASK64; 197 k3 = (KR <<< 15) >> 64; 198 k4 = (KR <<< 15) & MASK64; 199 k5 = (KA <<< 15) >> 64; 200 k6 = (KA <<< 15) & MASK64; 201 ke1 = (KR <<< 30) >> 64; 202 ke2 = (KR <<< 30) & MASK64; 203 k7 = (KB <<< 30) >> 64; 204 k8 = (KB <<< 30) & MASK64; 205 k9 = (KL <<< 45) >> 64; 206 k10 = (KL <<< 45) & MASK64; 207 k11 = (KA <<< 45) >> 64; 208 k12 = (KA <<< 45) & MASK64; 209 ke3 = (KL <<< 60) >> 64; 210 ke4 = (KL <<< 60) & MASK64; 211 k13 = (KR <<< 60) >> 64; 212 k14 = (KR <<< 60) & MASK64; 213 k15 = (KB <<< 60) >> 64; 214 k16 = (KB <<< 60) & MASK64; 215 k17 = (KL <<< 77) >> 64; 216 k18 = (KL <<< 77) & MASK64; 217 ke5 = (KA <<< 77) >> 64; 218 ke6 = (KA <<< 77) & MASK64; 219 k19 = (KR <<< 94) >> 64; 220 k20 = (KR <<< 94) & MASK64; 221 k21 = (KA <<< 94) >> 64; 222 k22 = (KA <<< 94) & MASK64; 223 k23 = (KL <<< 111) >> 64; 224 k24 = (KL <<< 111) & MASK64; 225 kw3 = (KB <<< 111) >> 64; 226 kw4 = (KB <<< 111) & MASK64; 228 2.3 Data Randomizing Part 230 2.3.1 Encryption for 128-bit keys 232 128-bit plaintext M is divided into the left 64-bit D1 and the right 233 64-bit D2. 235 D1 = M >> 64; 236 D2 = M & MASK64; 237 D1 = D1 ^ kw1; // Prewhitening 238 D2 = D2 ^ kw2; 239 D2 = D2 ^ F(D1, k1); // Round 1 240 D1 = D1 ^ F(D2, k2); // Round 2 241 D2 = D2 ^ F(D1, k3); // Round 3 242 D1 = D1 ^ F(D2, k4); // Round 4 243 D2 = D2 ^ F(D1, k5); // Round 5 244 D1 = D1 ^ F(D2, k6); // Round 6 245 D1 = FL (D1, ke1); // FL 246 D2 = FLINV(D2, ke2); // FLINV 247 D2 = D2 ^ F(D1, k7 ); // Round 7 248 D1 = D1 ^ F(D2, k8 ); // Round 8 249 D2 = D2 ^ F(D1, k9 ); // Round 9 250 D1 = D1 ^ F(D2, k10); // Round 10 251 D2 = D2 ^ F(D1, k11); // Round 11 252 D1 = D1 ^ F(D2, k12); // Round 12 253 D1 = FL (D1, ke3); // FL 254 D2 = FLINV(D2, ke4); // FLINV 255 D2 = D2 ^ F(D1, k13); // Round 13 256 D1 = D1 ^ F(D2, k14); // Round 14 257 D2 = D2 ^ F(D1, k15); // Round 15 258 D1 = D1 ^ F(D2, k16); // Round 16 259 D2 = D2 ^ F(D1, k17); // Round 17 260 D1 = D1 ^ F(D2, k18); // Round 18 261 D2 = D2 ^ kw3; // Postwhitening 262 D1 = D1 ^ kw4; 264 128-bit ciphertext C is constructed from D1 and D2 as follows. 266 C = (D2 << 64) | D1; 268 2.3.2 Encryption for 192- and 256-bit keys 270 128-bit plaintext M is divided into the left 64-bit D1 and the 271 right 64-bit D2. 273 D1 = M >> 64; 274 D2 = M & MASK64; 275 D1 = D1 ^ kw1; // Prewhitening 276 D2 = D2 ^ kw2; 277 D2 = D2 ^ F(D1, k1); // Round 1 278 D1 = D1 ^ F(D2, k2); // Round 2 279 D2 = D2 ^ F(D1, k3); // Round 3 280 D1 = D1 ^ F(D2, k4); // Round 4 281 D2 = D2 ^ F(D1, k5); // Round 5 282 D1 = D1 ^ F(D2, k6); // Round 6 283 D1 = FL (D1, ke1); // FL 284 D2 = FLINV(D2, ke2); // FLINV 285 D2 = D2 ^ F(D1, k7 ); // Round 7 286 D1 = D1 ^ F(D2, k8 ); // Round 8 287 D2 = D2 ^ F(D1, k9 ); // Round 9 288 D1 = D1 ^ F(D2, k10); // Round 10 289 D2 = D2 ^ F(D1, k11); // Round 11 290 D1 = D1 ^ F(D2, k12); // Round 12 291 D1 = FL (D1, ke3); // FL 292 D2 = FLINV(D2, ke4); // FLINV 293 D2 = D2 ^ F(D1, k13); // Round 13 294 D1 = D1 ^ F(D2, k14); // Round 14 295 D2 = D2 ^ F(D1, k15); // Round 15 296 D1 = D1 ^ F(D2, k16); // Round 16 297 D2 = D2 ^ F(D1, k17); // Round 17 298 D1 = D1 ^ F(D2, k18); // Round 18 299 D1 = FL (D1, ke5); // FL 300 D2 = FLINV(D2, ke6); // FLINV 301 D2 = D2 ^ F(D1, k19); // Round 19 302 D1 = D1 ^ F(D2, k20); // Round 20 303 D2 = D2 ^ F(D1, k21); // Round 21 304 D1 = D1 ^ F(D2, k22); // Round 22 305 D2 = D2 ^ F(D1, k23); // Round 23 306 D1 = D1 ^ F(D2, k24); // Round 24 307 D2 = D2 ^ kw3; // Postwhitening 308 D1 = D1 ^ kw4; 310 128-bit ciphertext C is constructed from D1 and D2 as follows. 312 C = (D2 << 64) | D1; 314 2.3.3 Decryption 316 The decryption procedure of Camellia can be done in the same way as 317 the encryption procedure by reversing the order of the subkeys. 319 That is to say: 321 128-bit key: 322 kw1 <-> kw3 323 kw2 <-> kw4 324 k1 <-> k18 325 k2 <-> k17 326 k3 <-> k16 327 k4 <-> k15 328 k5 <-> k14 329 k6 <-> k13 330 k7 <-> k12 331 k8 <-> k11 332 k9 <-> k10 333 ke1 <-> ke4 334 ke2 <-> ke3 336 192- or 256-bit key: 337 kw1 <-> kw3 338 kw2 <-> kw4 339 k1 <-> k24 340 k2 <-> k23 341 k3 <-> k22 342 k4 <-> k21 343 k5 <-> k20 344 k6 <-> k19 345 k7 <-> k18 346 k8 <-> k17 347 k9 <-> k16 348 k10 <-> k15 349 k11 <-> k14 350 k12 <-> k13 351 ke1 <-> ke6 352 ke2 <-> ke5 353 ke3 <-> ke4 355 2.4 Components of Camellia 357 2.4.1 F-function 359 Function F takes two parameters. One is 64-bit wide input data, 360 namely F_IN. The other is 64-bit wide subkey, namely KE. F returns 361 64-bit wide data, namely F_OUT. 363 F(F_IN, KE) 364 begin 365 var x as 64-bit unsigned integer; 366 var t1, t2, t3, t4, t5, t6, t7, t8 as 8-bit unsigned integer; 367 var y1, y2, y3, y4, y5, y6, y7, y8 as 8-bit unsigned integer; 368 x = F_IN ^ KE; 369 t1 = x >> 56; 370 t2 = (x >> 48) & MASK8; 371 t3 = (x >> 40) & MASK8; 372 t4 = (x >> 32) & MASK8; 373 t5 = (x >> 24) & MASK8; 374 t6 = (x >> 16) & MASK8; 375 t7 = (x >> 8) & MASK8; 376 t8 = x & MASK8; 377 t1 = SBOX1[t1]; 378 t2 = SBOX2[t2]; 379 t3 = SBOX3[t3]; 380 t4 = SBOX4[t4]; 381 t5 = SBOX2[t5]; 382 t6 = SBOX3[t6]; 383 t7 = SBOX4[t7]; 384 t8 = SBOX1[t8]; 385 y1 = t1 ^ t3 ^ t4 ^ t6 ^ t7 ^ t8; 386 y2 = t1 ^ t2 ^ t4 ^ t5 ^ t7 ^ t8; 387 y3 = t1 ^ t2 ^ t3 ^ t5 ^ t6 ^ t8; 388 y4 = t2 ^ t3 ^ t4 ^ t5 ^ t6 ^ t7; 389 y5 = t1 ^ t2 ^ t6 ^ t7 ^ t8; 390 y6 = t2 ^ t3 ^ t5 ^ t7 ^ t8; 391 y7 = t3 ^ t4 ^ t5 ^ t6 ^ t8; 392 y8 = t1 ^ t4 ^ t5 ^ t6 ^ t7; 393 F_OUT = (y1 << 56) | (y2 << 48) | (y3 << 40) | (y4 << 32) 394 | (y5 << 24) | (y6 << 16) | (y7 << 8) | y8; 395 return FO_OUT; 396 end. 398 SBOX2, SBOX3, and SBOX4 are defined using SBOX1 as follows: 399 SBOX2[x] = SBOX1[x] <<< 1; 400 SBOX3[x] = SBOX1[x] <<< 7; 401 SBOX4[x] = SBOX1[x <<< 1]; 402 SBOX1 is defined by the following table. For example, SBOX1[0x3d] 403 equals 86. 405 SBOX1: 406 0 1 2 3 4 5 6 7 8 9 a b c d e f 407 00: 112 130 44 236 179 39 192 229 228 133 87 53 234 12 174 65 408 10: 35 239 107 147 69 25 165 33 237 14 79 78 29 101 146 189 409 20: 134 184 175 143 124 235 31 206 62 48 220 95 94 197 11 26 410 30: 166 225 57 202 213 71 93 61 217 1 90 214 81 86 108 77 411 40: 139 13 154 102 251 204 176 45 116 18 43 32 240 177 132 153 412 50: 223 76 203 194 52 126 118 5 109 183 169 49 209 23 4 215 413 60: 20 88 58 97 222 27 17 28 50 15 156 22 83 24 242 34 414 70: 254 68 207 178 195 181 122 145 36 8 232 168 96 252 105 80 415 80: 170 208 160 125 161 137 98 151 84 91 30 149 224 255 100 210 416 90: 16 196 0 72 163 247 117 219 138 3 230 218 9 63 221 148 417 a0: 135 92 131 2 205 74 144 51 115 103 246 243 157 127 191 226 418 b0: 82 155 216 38 200 55 198 59 129 150 111 75 19 190 99 46 419 c0: 233 121 167 140 159 110 188 142 41 245 249 182 47 253 180 89 420 d0: 120 152 6 106 231 70 113 186 212 37 171 66 136 162 141 250 421 e0: 114 7 185 85 248 238 172 10 54 73 42 104 60 56 241 164 422 f0: 64 40 211 123 187 201 67 193 21 227 173 244 119 199 128 158 424 2.4.2 FL- and FLINV-functions 425 Function FL takes two parameters. One is 64-bit wide input data, 426 namely FL_IN. The other is 64-bit wide subkey, namely KE. FL 427 returns 64-bit wide data, namely FL_OUT. 429 FL(FL_IN, KE) 430 begin 431 var x1, x2 as 32-bit unsigned integer; 432 var k1, k2 as 32-bit unsigned integer; 433 x1 = FL_IN >> 32; 434 x2 = FL_IN & MASK32; 435 k1 = KE >> 32; 436 k2 = KE & MASK32; 437 x2 = x2 ^ ((x1 & k1) <<< 1); 438 x1 = x1 ^ (x2 | k2); 439 FL_OUT = (x1 << 32) | x2; 440 end. 442 Function FLINV is the inverse function of FL. 444 FLINV(FLINV_IN, KE) 445 begin 446 var y1, y2 as 32-bit unsigned integer; 447 var k1, k2 as 32-bit unsigned integer; 448 y1 = FLINV_IN >> 32; 449 y2 = FLINV_IN & MASK32; 450 k1 = KE >> 32; 451 k2 = KE & MASK32; 452 y1 = y1 ^ (y2 | k2); 453 y2 = y2 ^ ((y1 & k1) <<< 1); 454 FLINV_OUT = (y1 << 32) | y2; 455 end. 457 3. Object Identifiers 459 The Object Identifier for Camellia with 18 rounds and 128-bit key in 460 Cipher Block Chaining (CBC) mode is as follows: 462 id-camellia128-cbc OBJECT IDENTIFIER ::= 463 { iso(1) member-body(2) 392 200011 61 security(1) 464 algorithm(1) symmetric-encryption-algorithm(1) 465 camellia128-cbc(2) } 467 The Object Identifier for Camellia with 24 rounds and 192-bit key in 468 Cipher Block Chaining (CBC) mode is as follows: 470 id-camellia192-cbc OBJECT IDENTIFIER ::= 471 { iso(1) member-body(2) 392 200011 61 security(1) 472 algorithm(1) symmetric-encryption-algorithm(1) 473 camellia192-cbc(3) } 475 The Object Identifier for Camellia with 24 rounds and 256-bit key in 476 Cipher Block Chaining (CBC) mode is as follows: 478 id-camellia256-cbc OBJECT IDENTIFIER ::= 479 { iso(1) member-body(2) 392 200011 61 security(1) 480 algorithm(1) symmetric-encryption-algorithm(1) 481 camellia256-cbc(4) } 483 The above alogrithms need Initialization Vector (IV) as like as other 484 algorithms, such as DES-CBC, DES-EDE3-CBC, MISTY1-CBC and so on. To 485 determine the value of IV, the above algorithms take parameter as: 487 CamelliaCBCParameter ::= CamelliaIV -- Initialization Vector 489 CamelliaIV ::= OCTET STRING (SIZE(16)) 491 When these object identifiers are used, plaintext is padded before 492 encrypt it. At least 1 padding octet is appended at the end of the 493 plaintext to make the length of the plaintext to the multiple of 16 494 octets. The value of these octets is as same as the number of 495 appended octets. (e.g., If 10 octets are needed to pad, the value is 496 0x0a.) 498 4. Security Considerations 500 The recent advances in cryptanalytic techniques are remarkable. A 501 quantitative evaluation of security against powerful cryptanalytic 502 techniques such as differential cryptanalysis and linear 503 cryptanalysis is considered to be essential in designing any new 504 block cipher. We evaluated the security of Camellia by utilizing 505 state-of-the-art cryptanalytic techniques. We confirmed that 506 Camellia has no differential and linear characteristics that hold 507 with probability more than 2^(-128), which means that it is extremely 508 unlikely that differential and linear attacks will succeed against 509 the full 18-round Camellia. Moreover, Camellia was designed to offer 510 security against other advanced cryptanalytic attacks including 511 higher order differential attacks, interpolation attacks, related-key 512 attacks, truncated differential attacks, and so on [Camellia]. 514 5. Intellectual Property Statement 516 The IETF takes no position regarding the validity or scope of any 517 intellectual property or other rights that might be claimed to 518 pertain to the implementation or use of the technology described in 519 this document or the extent to which any license under such rights 520 might or might not be available; neither does it represent that it 521 has made any effort to identify any such rights. Information on the 522 IETF's procedures with respect to rights in standards-track and 523 standards-related documentation can be found in BCP-11. Copies of 524 claims of rights made available for publication and any assurances of 525 licenses to be made available, or the result of an attempt made to 526 obtain a general license or permission for the use of such 527 proprietary rights by implementors or users of this specification can 528 be obtained from the IETF Secretariat. 530 The IETF invites any interested party to bring to its attention any 531 copyrights, patents or patent applications, or other proprietary 532 rights which may cover technology that may be required to practice 533 this standard. Please address the information to the IETF Executive 534 Director. 536 The IETF has been notified of intellectual property rights claimed in 537 regard to some or all of the specification contained in this 538 document. For more information consult the online list of claimed 539 rights. 541 6. Informative References 543 [CamelliaSpec] K. Aoki, T. Ichikawa, M. Kanda, M. Matsui, S. Moriai, 544 J. Nakajima, and T. Tokita, "Specification of Camellia --- a 545 128-bit Block Cipher". http://info.isl.ntt.co.jp/camellia/ 547 [CamelliaTech] K. Aoki, T. Ichikawa, M. Kanda, M. Matsui, S. Moriai, 548 J. Nakajima, and T. Tokita, "Camellia: A 128-Bit Block Cipher 549 Suitable for Multiple Platforms". 550 http://info.isl.ntt.co.jp/camellia/ 552 [Camellia] K. Aoki, T. Ichikawa, M. Kanda, M. Matsui, S. Moriai, J. 553 Nakajima, and T. Tokita, "Camellia: A 128-Bit Block Cipher 554 Suitable for Multiple Platforms - Design and Analysis -", In 555 Selected Areas in Cryptography, 7th Annual International 556 Workshop, SAC 2000, Waterloo, Ontario, Canada, August 2000, 557 Proceedings, Lecture Notes in Computer Science 2012, pp.39-56, 558 Springer-Verlag, 2001. 560 [CRYPTREC] "CRYPTREC Advisory Committee Report FY2002", Ministry 561 of Public Management, Home Affairs, Posts and 562 Telecommunications, and Ministry of Economy, Trade and 563 Industry, March 2003. 564 http://www.soumu.go.jp/joho_tsusin/security/cryptrec.html 565 CRYPTREC home page by Information-technology Promotion Agency, 566 Japan (IPA). 567 http://www.ipa.go.jp/security/enc/CRYPTREC/index-e.html 569 [NESSIE] New European Schemes for Signatures, Integrity and 570 Encryption (NESSIE) project. http://www.cryptonessie.org 572 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 573 Requirement Levels", BCP 14, RFC 2119, March 1997. 575 Appendix A. Example Data of Camellia 577 Here is a test data for Camellia in hexadecimal form. 579 128-bit key 580 Key : 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 10 581 Plaintext : 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 10 582 Ciphertext: 67 67 31 38 54 96 69 73 08 57 06 56 48 ea be 43 584 192-bit key 585 Key : 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 10 586 : 00 11 22 33 44 55 66 77 588 Plaintext : 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 10 589 Ciphertext: b4 99 34 01 b3 e9 96 f8 4e e5 ce e7 d7 9b 09 b9 591 256-bit key 592 Key : 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 10 593 : 00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff 594 Plaintext : 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 10 595 Ciphertext: 9a cc 23 7d ff 16 d7 6c 20 ef 7c 91 9e 3a 75 09 597 Authors' Addresses 599 Mitsuru Matsui & Junko Nakajima 600 Mitsubishi Electric Corporation, Information Technology R&D Center 601 5-1-1 Ofuna, Kamakura, Kanagawa 247-8501, Japan 602 Phone: +81-467-41-2190 603 FAX: +81-467-41-2185 604 Email: matsui@iss.isl.melco.co.jp 606 Shiho Moriai 607 Sony Computer Entertainment Inc. 608 Phone: +81-3-6438-7523 609 FAX: +81-3-6438-8629 610 Email: camellia@isl.ntt.co.jp (Camellia team) 611 shiho@rc.scei.sony.co.jp (Shiho Moriai)