idnits 2.17.1 draft-nakajima-camellia-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-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 10 longer pages, the longest (page 2) being 60 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 12 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (August 2000) is 8648 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) -- Looks like a reference, but probably isn't: '0x3d' on line 381 -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT J. Nakajima 3 Mitsubishi Electric Corporation 4 Expires February 2001 S. Moriai 5 Nippon Telegraph and Telephone Corporation 6 August 2000 8 A Description of the Camellia Encryption Algorithm 10 12 Status of this Memo 14 This document is an Internet-Draft and is NOT offered in accordance 15 with Section 10 of RFC2026, and the author does not provide the IETF 16 with any rights other than to publish as an Internet-Draft. 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 months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 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 a secret-key cryptosystem, Camellia; it is a 37 block cipher with 128-bit block size and 128-, 192-, and 256-bit 38 keys. The algorithm description is presented together with key 39 scheduling part and data randomizing part. 41 1. Introduction 43 This document describes the secret-key cryptosystem Camellia 44 [1][2][3], a block cipher with 128-bit block size and 128-, 192-, and 45 256-bit keys, i.e. the same interface specifications as the Advanced 46 Encryption Standard (AES). Camellia offers excellent efficiency on 47 both software and hardware platforms in addition to a high level of 48 security. It is confirmed that Camellia provides strong security 49 against differential and linear cryptanalysis. An optimized assembly 50 language implementation of Camellia can encrypt on a Pentium III 51 (800MHz) at the rate of more than 276 Mbits per second, which is much 52 faster than the speed of an optimized DES implementation. In 53 addition, another distinguishing feature is its small hardware 54 requirements. The hardware design, which includes both encryption 55 and decryption, occupies approximately 11K gates, which is, to the 56 best of our knowledge, the smallest among all existing 128-bit block 57 ciphers. 59 2. Algorithm Description 61 Camellia can be divided into "key scheduling part" and "data 62 randomizing part". 64 2.1 Terminology 66 The following operators are used in this document to describe the 67 algorithm. 69 & bitwise AND operation. 70 | bitwise OR operation. 71 ^ bitwise exclusive-OR operation. 72 << logically left shift operation. 73 >> logically right shift operation. 74 <<< left rotation operation. 75 ~y bitwise complement of y. 76 0x hexadecimal representation. 78 Note that the resultant values of logically left shift operation are 79 expanded their data width infinitely. 81 The constant values of MASK8, MASK32, MASK64, and MASK128 are defined as follows. 83 MASK8 = 0xff; 84 MASK32 = 0xffffffff; 85 MASK64 = 0xffffffffffffffff; 86 MASK128 = 0xffffffffffffffffffffffffffffffff; 88 2.2 Key Scheduling Part 90 In the key schedule part of Camellia, the 128-bit variables of KL and 91 KR are defined as follows. For 128-bit keys, the 128-bit key K is 92 used as KL and KR is 0. For 192-bit keys, the leftmost 128-bits of 93 key K are used as KL and the concatenation of the rightmost 64-bits of K 94 and the complement of the rightmost 64-bits of K are used as KR. For 95 256-bit keys, the leftmost 128-bits of key K are used as KL and the 96 rightmost 128-bits of K are used as KR. 98 128-bit key K: 99 KL = K; KR = 0; 101 192-bit key K: 102 KL = K >> 64; 103 KR = ((K & MASK64) << 64) | (~(K & MASK64)); 105 256-bit key K: 106 KL = K >> 128; 107 KR = K & MASK128; 109 The 128-bit variables KA and KB are generated from KL and KR as 110 follows. Note that KB is used only if the length of the secret key 111 is 192 or 256 bits. D1 and D2 are 64-bit temporary variables. 113 D1 = (KL ^ KR) >> 64; 114 D2 = (KL ^ KR) & MASK64; 115 D2 = D2 ^ F(D1, Sigma1); 116 D1 = D1 ^ F(D2, Sigma2); 117 D1 = D1 ^ (KL >> 64); 118 D2 = D2 ^ (KL & MASK64); 119 D2 = D2 ^ F(D1, Sigma3); 120 D1 = D1 ^ F(D2, Sigma4); 121 KA = (D1 << 64) | D2; 122 D1 = (KA ^ KR) >> 64; 123 D2 = (KA ^ KR) & MASK64; 124 D2 = D2 ^ F(D1, Sigma5); 125 D1 = D1 ^ F(D2, Sigma6); 126 KB = (D1 << 64) | D2; 128 The 64-bit constants Sigma1, Sigma2, ..., Sigma6 are used as "keys" 129 in the Feistel network. These constant values are, in hexadecimal 130 notation, as follows. 132 Sigma1 = 0xA09E667F3BCC908B; 133 Sigma2 = 0xB67AE8584CAA73B2; 134 Sigma3 = 0xC6EF372FE94F82BE; 135 Sigma4 = 0x54FF53A5F1D36F1C; 136 Sigma5 = 0x10E527FADE682D1D; 137 Sigma6 = 0xB05688C2B3E6C1FD; 139 The 64-bit subkeys are generated by rotating KL, KR, KA and KB and 140 taking the left- or right-half of them. 142 For 128-bit keys, subkeys are generated as follows. 144 kw1 = (KL <<< 0) >> 64; 145 kw2 = (KL <<< 0) & MASK64; 146 k1 = (KA <<< 0) >> 64; 147 k2 = (KA <<< 0) & MASK64; 148 k3 = (KL <<< 15) >> 64; 149 k4 = (KL <<< 15) & MASK64; 150 k5 = (KA <<< 15) >> 64; 151 k6 = (KA <<< 15) & MASK64; 152 ke1 = (KA <<< 30) >> 64; 153 ke2 = (KA <<< 30) & MASK64; 154 k7 = (KL <<< 45) >> 64; 155 k8 = (KL <<< 45) & MASK64; 156 k9 = (KA <<< 45) >> 64; 157 k10 = (KL <<< 60) & MASK64; 158 k11 = (KA <<< 60) >> 64; 159 k12 = (KA <<< 60) & MASK64; 160 ke3 = (KL <<< 77) >> 64; 161 ke4 = (KL <<< 77) & MASK64; 162 k13 = (KL <<< 94) >> 64; 163 k14 = (KL <<< 94) & MASK64; 164 k15 = (KA <<< 94) >> 64; 165 k16 = (KA <<< 94) & MASK64; 166 k17 = (KL <<< 111) >> 64; 167 k18 = (KL <<< 111) & MASK64; 168 kw3 = (KA <<< 111) >> 64; 169 kw4 = (KA <<< 111) & MASK64; 171 For 192- and 256-bit keys, subkeys are generated as follows. 173 kw1 = (KL <<< 0) >> 64; 174 kw2 = (KL <<< 0) & MASK64; 175 k1 = (KB <<< 0) >> 64; 176 k2 = (KB <<< 0) & MASK64; 177 k3 = (KR <<< 15) >> 64; 178 k4 = (KR <<< 15) & MASK64; 179 k5 = (KA <<< 15) >> 64; 180 k6 = (KA <<< 15) & MASK64; 181 ke1 = (KR <<< 30) >> 64; 182 ke2 = (KR <<< 30) & MASK64; 183 k7 = (KB <<< 30) >> 64; 184 k8 = (KB <<< 30) & MASK64; 185 k9 = (KL <<< 45) >> 64; 186 k10 = (KL <<< 45) & MASK64; 187 k11 = (KA <<< 45) >> 64; 188 k12 = (KA <<< 45) & MASK64; 189 ke3 = (KL <<< 60) >> 64; 190 ke4 = (KL <<< 60) & MASK64; 191 k13 = (KR <<< 60) >> 64; 192 k14 = (KR <<< 60) & MASK64; 193 k15 = (KB <<< 60) >> 64; 194 k16 = (KB <<< 60) & MASK64; 195 k17 = (KL <<< 77) >> 64; 196 k18 = (KL <<< 77) & MASK64; 197 ke5 = (KA <<< 77) >> 64; 198 ke6 = (KA <<< 77) & MASK64; 199 k19 = (KR <<< 94) >> 64; 200 k20 = (KR <<< 94) & MASK64; 201 k21 = (KA <<< 94) >> 64; 202 k22 = (KA <<< 94) & MASK64; 203 k23 = (KL <<< 111) >> 64; 204 k24 = (KL <<< 111) & MASK64; 205 kw3 = (KB <<< 111) >> 64; 206 kw4 = (KB <<< 111) & MASK64; 208 2.3 Data Randomizing Part 210 2.3.1 Encryption for 128-bit keys 212 128-bit plaintext M is divided into the left 64-bit D1 and the right 213 64-bit D2. 215 D1 = M >> 64; 216 D2 = M & MASK64; 217 D1 = D1 ^ kw1; // Prewhitening 218 D2 = D2 ^ kw2; 219 D2 = D2 ^ F(D1, k1); // Round 1 220 D1 = D1 ^ F(D2, k2); // Round 2 221 D2 = D2 ^ F(D1, k3); // Round 3 222 D1 = D1 ^ F(D2, k4); // Round 4 223 D2 = D2 ^ F(D1, k5); // Round 5 224 D1 = D1 ^ F(D2, k6); // Round 6 225 D1 = FL (D1, ke1); // FL 226 D2 = FLINV(D2, ke2); // FLINV 227 D2 = D2 ^ F(D1, k7 ); // Round 7 228 D1 = D1 ^ F(D2, k8 ); // Round 8 229 D2 = D2 ^ F(D1, k9 ); // Round 9 230 D1 = D1 ^ F(D2, k10); // Round 10 231 D2 = D2 ^ F(D1, k11); // Round 11 232 D1 = D1 ^ F(D2, k12); // Round 12 233 D1 = FL (D1, ke3); // FL 234 D2 = FLINV(D2, ke4); // FLINV 235 D2 = D2 ^ F(D1, k13); // Round 13 236 D1 = D1 ^ F(D2, k14); // Round 14 237 D2 = D2 ^ F(D1, k15); // Round 15 238 D1 = D1 ^ F(D2, k16); // Round 16 239 D2 = D2 ^ F(D1, k17); // Round 17 240 D1 = D1 ^ F(D2, k18); // Round 18 241 D2 = D2 ^ kw3; // Postwhitening 242 D1 = D1 ^ kw4; 244 128-bit ciphertext C is constructed from D1 and D2 as follows. 246 C = (D2 << 64) | D1; 248 2.3.2 Encryption for 192- and 256-bit keys 250 128-bit plaintext M is divided into the left 64-bit D1 and the 251 right 64-bit D2. 253 D1 = M >> 64; 254 D2 = M & MASK64; 255 D1 = D1 ^ kw1; // Prewhitening 256 D2 = D2 ^ kw2; 257 D2 = D2 ^ F(D1, k1); // Round 1 258 D1 = D1 ^ F(D2, k2); // Round 2 259 D2 = D2 ^ F(D1, k3); // Round 3 260 D1 = D1 ^ F(D2, k4); // Round 4 261 D2 = D2 ^ F(D1, k5); // Round 5 262 D1 = D1 ^ F(D2, k6); // Round 6 263 D1 = FL (D1, ke1); // FL 264 D2 = FLINV(D2, ke2); // FLINV 265 D2 = D2 ^ F(D1, k7 ); // Round 7 266 D1 = D1 ^ F(D2, k8 ); // Round 8 267 D2 = D2 ^ F(D1, k9 ); // Round 9 268 D1 = D1 ^ F(D2, k10); // Round 10 269 D2 = D2 ^ F(D1, k11); // Round 11 270 D1 = D1 ^ F(D2, k12); // Round 12 271 D1 = FL (D1, ke3); // FL 272 D2 = FLINV(D2, ke4); // FLINV 273 D2 = D2 ^ F(D1, k13); // Round 13 274 D1 = D1 ^ F(D2, k14); // Round 14 275 D2 = D2 ^ F(D1, k15); // Round 15 276 D1 = D1 ^ F(D2, k16); // Round 16 277 D2 = D2 ^ F(D1, k17); // Round 17 278 D1 = D1 ^ F(D2, k18); // Round 18 279 D1 = FL (D1, ke5); // FL 280 D2 = FLINV(D2, ke6); // FLINV 281 D2 = D2 ^ F(D1, k19); // Round 19 282 D1 = D1 ^ F(D2, k20); // Round 20 283 D2 = D2 ^ F(D1, k21); // Round 21 284 D1 = D1 ^ F(D2, k22); // Round 22 285 D2 = D2 ^ F(D1, k23); // Round 23 286 D1 = D1 ^ F(D2, k24); // Round 24 287 D2 = D2 ^ kw3; // Postwhitening 288 D1 = D1 ^ kw4; 290 128-bit ciphertext C is constructed from D1 and D2 as follows. 292 C = (D2 << 64) | D1; 294 2.3.3 Decryption 296 The decryption procedure of Camellia can be done in the same way as 297 the encryption procedure by reversing the order of the subkeys. That 298 is to say: 300 128-bit key: 301 kw1 <-> kw3 302 kw2 <-> kw4 303 k1 <-> k18 304 k2 <-> k17 305 k3 <-> k16 306 k4 <-> k15 307 k5 <-> k14 308 k6 <-> k13 309 k7 <-> k12 310 k8 <-> k11 311 k9 <-> k10 312 ke1 <-> ke4 313 ke2 <-> ke3 315 192- or 256-bit key: 316 kw1 <-> kw3 317 kw2 <-> kw4 318 k1 <-> k24 319 k2 <-> k23 320 k3 <-> k22 321 k4 <-> k21 322 k5 <-> k20 323 k6 <-> k19 324 k7 <-> k18 325 k8 <-> k17 326 k9 <-> k16 327 k10 <-> k15 328 k11 <-> k14 329 k12 <-> k13 330 ke1 <-> ke6 331 ke2 <-> ke5 332 ke3 <-> ke4 334 2.4 Components of Camellia 336 2.4.1 F-function 338 Function F takes two parameters. One is 64-bit wide input data, 339 namely F_IN. The other is 64-bit wide subkey, namely KE. F returns 340 64-bit wide data, namely F_OUT. 342 F(F_IN, KE) 343 begin 344 var x as 64-bit unsigned integer; 345 var t1, t2, t3, t4, t5, t6, t7, t8 as 8-bit unsigned integer; 346 var y1, y2, y3, y4, y5, y6, y7, y8 as 8-bit unsigned integer; 347 x = F_IN ^ KE; 348 t1 = x >> 56; 349 t2 = (x >> 48) & MASK8; 350 t3 = (x >> 40) & MASK8; 351 t4 = (x >> 32) & MASK8; 352 t5 = (x >> 24) & MASK8; 353 t6 = (x >> 16) & MASK8; 354 t7 = (x >> 8) & MASK8; 355 t8 = x & MASK8; 356 t1 = SBOX1[t1]; 357 t2 = SBOX2[t2]; 358 t3 = SBOX3[t3]; 359 t4 = SBOX4[t4]; 360 t5 = SBOX2[t5]; 361 t6 = SBOX3[t6]; 362 t7 = SBOX4[t7]; 363 t8 = SBOX1[t8]; 364 y1 = t1 ^ t3 ^ t4 ^ t6 ^ t7 ^ t8; 365 y2 = t1 ^ t2 ^ t4 ^ t5 ^ t7 ^ t8; 366 y3 = t1 ^ t2 ^ t3 ^ t5 ^ t6 ^ t8; 367 y4 = t2 ^ t3 ^ t4 ^ t5 ^ t6 ^ t7; 368 y5 = t1 ^ t2 ^ t6 ^ t7 ^ t8; 369 y6 = t2 ^ t3 ^ t5 ^ t7 ^ t8; 370 y7 = t3 ^ t4 ^ t5 ^ t6 ^ t8; 371 y8 = t1 ^ t4 ^ t5 ^ t6 ^ t7; 372 F_OUT = (y1 << 56) | (y2 << 48) | (y3 << 40) | (y4 << 32) 373 | (y5 << 24) | (y6 << 16) | (y7 << 8) | y8; 374 return FO_OUT; 375 end. 377 SBOX2, SBOX3, and SBOX4 are defined using SBOX1 as follows: 378 SBOX2[x] = SBOX1[x] <<< 1; 379 SBOX3[x] = SBOX1[x] <<< 7; 380 SBOX4[x] = SBOX1[x <<< 1]; 381 SBOX1 is defined by the following table. For example, SBOX1[0x3d] 382 equals 86. 384 SBOX1: 385 0 1 2 3 4 5 6 7 8 9 a b c d e f 386 00: 112 130 44 236 179 39 192 229 228 133 87 53 234 12 174 65 387 10: 35 239 107 147 69 25 165 33 237 14 79 78 29 101 146 189 388 20: 134 184 175 143 124 235 31 206 62 48 220 95 94 197 11 26 389 30: 166 225 57 202 213 71 93 61 217 1 90 214 81 86 108 77 390 40: 139 13 154 102 251 204 176 45 116 18 43 32 240 177 132 153 391 50: 223 76 203 194 52 126 118 5 109 183 169 49 209 23 4 215 392 60: 20 88 58 97 222 27 17 28 50 15 156 22 83 24 242 34 393 70: 254 68 207 178 195 181 122 145 36 8 232 168 96 252 105 80 394 80: 170 208 160 125 161 137 98 151 84 91 30 149 224 255 100 210 395 90: 16 196 0 72 163 247 117 219 138 3 230 218 9 63 221 148 396 a0: 135 92 131 2 205 74 144 51 115 103 246 243 157 127 191 226 397 b0: 82 155 216 38 200 55 198 59 129 150 111 75 19 190 99 46 398 c0: 233 121 167 140 159 110 188 142 41 245 249 182 47 253 180 89 399 d0: 120 152 6 106 231 70 113 186 212 37 171 66 136 162 141 250 400 e0: 114 7 185 85 248 238 172 10 54 73 42 104 60 56 241 164 401 f0: 64 40 211 123 187 201 67 193 21 227 173 244 119 199 128 158 403 2.4.2 FL- and FLINV-functions 405 Function FL takes two parameters. One is 64-bit wide input data, 406 namely FL_IN. The other is 64-bit wide subkey, namely KE. FL 407 returns 64-bit wide data, namely FL_OUT. 409 FL(FL_IN, KE) 410 begin 411 var x1, x2 as 32-bit unsigned integer; 412 var k1, k2 as 32-bit unsigned integer; 413 x1 = FL_IN >> 32; 414 x2 = FL_IN & MASK32; 415 k1 = KE >> 32; 416 k2 = KE & MASK32; 417 x2 = x2 ^ ((x1 & k1) <<< 1); 418 x1 = x1 ^ (x2 | k2); 419 FL_OUT = (x1 << 32) | x2; 420 end. 422 Function FLINV is the inverse function of FL. 424 FLINV(FLINV_IN, KE) 425 begin 426 var y1, y2 as 32-bit unsigned integer; 427 var k1, k2 as 32-bit unsigned integer; 428 y1 = FLINV_IN >> 32; 429 y2 = FLINV_IN & MASK32; 430 k1 = KE >> 32; 431 k2 = KE & MASK32; 432 y1 = y1 ^ (y2 | k2); 433 y2 = y2 ^ ((y1 & k1) <<< 1); 434 FLINV_OUT = (y1 << 32) | y2; 435 end. 437 3. Security Considerations 439 The recent advances in cryptanalytic techniques are remarkable. A 440 quantitative evaluation of security against powerful cryptanalytic 441 techniques such as differential cryptanalysis and linear 442 cryptanalysis is considered to be essential in designing any new 443 block cipher. We evaluated the security of Camellia by utilizing 444 state-of-the-art cryptanalytic techniques. We confirmed that 445 Camellia has no differential and linear characteristics that hold 446 with probability more than 2^(-128), which means that it is extremely 447 unlikely that differential and linear attacks will succeed against 448 the full 18-round Camellia. Moreover, Camellia was designed to offer 449 security against other advanced cryptanalytic attacks including 450 higher order differential attacks, interpolation attacks, related-key 451 attacks, truncated differential attacks, and so on [3]. 453 4. Intellectual Property Statement 455 Mitsubishi Electric Corporation (Mitsubishi Electric) and Nippon 456 Telegraph and Telephone Corporation (NTT) have filed patent 457 applications on the techniques used in Camellia. For more 458 information, please contact at MISTY@isl.melco.co.jp and/or 459 e2@isl.ntt.co.jp. 461 5. References 463 [1] K. Aoki, T. Ichikawa, M. Kanda, M. Matsui, S. Moriai, J. 464 Nakajima, and T. Tokita, ``Specification of Camellia --- a 465 128-bit Block Cipher,'' 2000. 466 http://info.isl.ntt.co.jp/camellia/ 468 [2] K. Aoki, T. Ichikawa, M. Kanda, M. Matsui, S. Moriai, J. 469 Nakajima, and T. Tokita, ``Camellia: A 128-Bit Block Cipher 470 Suitable for Multiple Platforms,'' 2000. 471 http://info.isl.ntt.co.jp/camellia/ 473 [3] K. Aoki, T. Ichikawa, M. Kanda, M. Matsui, S. Moriai, J. 474 Nakajima, and T. Tokita, ``Camellia: A 128-Bit Block Cipher 475 Suitable for Multiple Platforms --- Design and Analysis ---,'' 476 Workshop Record of SAC 2000, Seventh Annual Workshop on Selected 477 Areas in Cryptography, 14-15 August 2000, pp.41-54. (to appear 478 in Lecture Notes in Computer Science of Spring-Verlag) 480 6. Authors' Addresses 482 Junko Nakajima 483 Mitsubishi Electric Corporation, Information Technology R&D Center 484 5-1-1 Ofuna, Kamakura, Kanagawa 247-8501, Japan 485 Phone: +81-467-41-2181 486 FAX: +81-467-41-2185 487 EMail: june15@iss.isl.melco.co.jp 489 Shiho Moriai 490 NTT Laboratories 491 1-1 Hikarinooka, Yokosuka, 239-0847, Japan 492 Phone: +81-468-59-2007 493 FAX: +81-468-59-3858 494 EMail: shiho@isl.ntt.co.jp 496 Appendix A. Example Data of Camellia 498 Here is a test data for Camellia in hexadecimal form. 500 128-bit key 501 Key : 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 10 502 Plaintext : 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 10 503 Ciphertext: 67 67 31 38 54 96 69 73 08 57 06 56 48 ea be 43 505 192-bit key 506 Key : 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 10 507 : 00 11 22 33 44 55 66 77 508 Plaintext : 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 10 509 Ciphertext: b4 99 34 01 b3 e9 96 f8 4e e5 ce e7 d7 9b 09 b9 511 256-bit key 512 Key : 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 10 513 : 00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff 514 Plaintext : 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 10 515 Ciphertext: 9a cc 23 7d ff 16 d7 6c 20 ef 7c 91 9e 3a 75 09