Network Working Group M. Matsui Request for Comments: 3713 J. Nakajima Category: Informational Mitsubishi Electric Corporation S. Moriai Sony Computer Entertainment Inc. April 2004
A Description of the Camellia Encryption Algorithm
Status of this Memo
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document describes the Camellia encryption algorithm. Camellia is a block cipher with 128-bit block size and 128-, 192-, and 256-bit keys. The algorithm description is presented together with key scheduling part and data randomizing part.
Camellia was jointly developed by Nippon Telegraph and Telephone Corporation and Mitsubishi Electric Corporation in 2000 [CamelliaSpec]. Camellia specifies the 128-bit block size and 128-, 192-, and 256-bit key sizes, the same interface as the Advanced Encryption Standard (AES). Camellia is characterized by its suitability for both software and hardware implementations as well as its high level of security. From a practical viewpoint, it is designed to enable flexibility in software and hardware implementations on 32-bit processors widely used over the Internet and many applications, 8-bit processors used in smart cards, cryptographic hardware, embedded systems, and so on [CamelliaTech]. Moreover, its key setup time is excellent, and its key agility is superior to that of AES.
Matsui, et al. Informational [Page 1]
RFC 3713 Camellia Encryption Algorithm April 2004
Camellia has been scrutinized by the wide cryptographic community during several projects for evaluating crypto algorithms. In particular, Camellia was selected as a recommended cryptographic primitive by the EU NESSIE (New European Schemes for Signatures, Integrity and Encryption) project [NESSIE] and also included in the list of cryptographic techniques for Japanese e-Government systems which were selected by the Japan CRYPTREC (Cryptography Research and Evaluation Committees) [CRYPTREC].
The following operators are used in this document to describe the algorithm.
& bitwise AND operation. | bitwise OR operation. ^ bitwise exclusive-OR operation. << logical left shift operation. >> logical right shift operation. <<< left rotation operation. ~y bitwise complement of y. 0x hexadecimal representation.
Note that the logical left shift operation is done with the infinite data width.
The constant values of MASK8, MASK32, MASK64, and MASK128 are defined as follows.
In the key schedule part of Camellia, the 128-bit variables of KL and KR are defined as follows. For 128-bit keys, the 128-bit key K is used as KL and KR is 0. For 192-bit keys, the leftmost 128-bits of key K are used as KL and the concatenation of the rightmost 64-bits of K and the complement of the rightmost 64-bits of K are used as KR. For 256-bit keys, the leftmost 128-bits of key K are used as KL and the rightmost 128-bits of K are used as KR.
The 128-bit variables KA and KB are generated from KL and KR as follows. Note that KB is used only if the length of the secret key is 192 or 256 bits. D1 and D2 are 64-bit temporary variables. F- function is described in Section 2.4.
128-bit plaintext M is divided into the left 64-bit D1 and the right 64-bit D2.
D1 = M >> 64; D2 = M & MASK64;
Encryption is performed using an 18-round Feistel structure with FL- and FLINV-functions inserted every 6 rounds. F-function, FL-function, and FLINV-function are described in Section 2.4.
128-bit plaintext M is divided into the left 64-bit D1 and the right 64-bit D2.
D1 = M >> 64; D2 = M & MASK64;
Encryption is performed using a 24-round Feistel structure with FL- and FLINV-functions inserted every 6 rounds. F-function, FL-function, and FLINV-function are described in Section 2.4.
The recent advances in cryptanalytic techniques are remarkable. A quantitative evaluation of security against powerful cryptanalytic techniques such as differential cryptanalysis and linear cryptanalysis is considered to be essential in designing any new block cipher. We evaluated the security of Camellia by utilizing state-of-the-art cryptanalytic techniques. We confirmed that Camellia has no differential and linear characteristics that hold with probability more than 2^(-128), which means that it is extremely unlikely that differential and linear attacks will succeed against the full 18-round Camellia. Moreover, Camellia was designed to offer security against other advanced cryptanalytic attacks including higher order differential attacks, interpolation attacks, related-key attacks, truncated differential attacks, and so on [Camellia].
[CamelliaSpec] Aoki, K., Ichikawa, T., Kanda, M., Matsui, M., Moriai, S., Nakajima, J. and T. Tokita, "Specification of Camellia --- a 128-bit Block Cipher". http://info.isl.ntt.co.jp/camellia/
[CamelliaTech] Aoki, K., Ichikawa, T., Kanda, M., Matsui, M., Moriai, S., Nakajima, J. and T. Tokita, "Camellia: A 128-Bit Block Cipher Suitable for Multiple Platforms". http://info.isl.ntt.co.jp/camellia/
[Camellia] Aoki, K., Ichikawa, T., Kanda, M., Matsui, M., Moriai, S., Nakajima, J. and T. Tokita, "Camellia: A 128-Bit Block Cipher Suitable for Multiple Platforms - Design and Analysis -", In Selected Areas in Cryptography, 7th Annual International Workshop, SAC 2000, Waterloo, Ontario, Canada, August 2000, Proceedings, Lecture Notes in Computer Science 2012, pp.39-56, Springer- Verlag, 2001.
Matsui, et al. Informational [Page 11]
RFC 3713 Camellia Encryption Algorithm April 2004
[CRYPTREC] "CRYPTREC Advisory Committee Report FY2002", Ministry of Public Management, Home Affairs, Posts and Telecommunications, and Ministry of Economy, Trade and Industry, March 2003. http://www.soumu.go.jp/joho_tsusin/security/ cryptrec.html, CRYPTREC home page by Information-technology Promotion Agency, Japan (IPA) http://www.ipa.go.jp/security/enc/CRYPTREC/index- e.html
[NESSIE] New European Schemes for Signatures, Integrity and Encryption (NESSIE) project. http://www.cryptonessie.org
[RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version 1.5", RFC 2315, March 1998.
Here are test data for Camellia in hexadecimal form.
128-bit key Key : 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 10 Plaintext : 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 10 Ciphertext: 67 67 31 38 54 96 69 73 08 57 06 56 48 ea be 43
192-bit key Key : 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 10 : 00 11 22 33 44 55 66 77 Plaintext : 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 10 Ciphertext: b4 99 34 01 b3 e9 96 f8 4e e5 ce e7 d7 9b 09 b9
256-bit key Key : 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 10 : 00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff Plaintext : 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 10 Ciphertext: 9a cc 23 7d ff 16 d7 6c 20 ef 7c 91 9e 3a 75 09
Matsui, et al. Informational [Page 13]
RFC 3713 Camellia Encryption Algorithm April 2004
Acknowledgements
Shiho Moriai worked for NTT when this document was developed.
Authors' Addresses
Mitsuru Matsui Mitsubishi Electric Corporation Information Technology R&D Center 5-1-1 Ofuna, Kamakura Kanagawa 247-8501, Japan
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the Internet Society.