Camellia for IPsec: The Camellia Cipher Algorithm and Its Use With IPsec
How to use the Camellia block cipher in CBC mode to keep IPsec ESP packets confidential.
Kato, A., Moriai, S., and M. Kanda, "The Camellia Cipher Algorithm and Its Use With IPsec", RFC 4312, DOI 10.17487/RFC4312, December 2005, <https://www.rfc-editor.org/info/rfc4312>.
@misc{rfc4312,
series = {Request for Comments},
number = 4312,
howpublished = {RFC 4312},
publisher = {RFC Editor},
doi = {10.17487/RFC4312},
url = {https://www.rfc-editor.org/info/rfc4312},
author = {A. Kato and S. Moriai and M. Kanda},
title = {{The Camellia Cipher Algorithm and Its Use With IPsec}},
pagetotal = 8,
year = 2005,
month = dec,
} RFC text
Contents
Network Working Group A. Kato
Request for Comments: 4312 NTT Software Corporation
Category: Standards Track S. Moriai
Sony Computer Entertainment Inc.
M. Kanda
Nippon Telegraph and Telephone Corporation
December 2005
The Camellia Cipher Algorithm and Its Use With IPsec
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes the use of the Camellia block cipher
algorithm in Cipher Block Chaining Mode, with an explicit
Initialization Vector, as a confidentiality mechanism within the
context of the IPsec Encapsulating Security Payload (ESP).
1. Introduction
This document describes the use of the Camellia block cipher
algorithm in Cipher Block Chaining Mode, with an explicit
Initialization Vector, as a confidentiality mechanism within the
context of the IPsec Encapsulating Security Payload (ESP).
Camellia was selected as a recommended cryptographic primitive by the
EU NESSIE (New European Schemes for Signatures, Integrity and
Encryption) project [NESSIE] and was included in the list of
cryptographic techniques for Japanese e-Government systems that was
selected by the Japan CRYPTREC (Cryptography Research, Evaluation
Committees) [CRYPTREC]. Camellia has been submitted to several other
standardization bodies, such as ISO (ISO/IEC 18033) and the IETF
S/MIME Mail Security Working Group [Camellia-CMS].
Camellia supports 128-bit block size and 128-, 192-, and 256-bit key
lengths, i.e., the same interface specifications as the Advanced
Encryption Standard (AES) [AES].
Camellia is a symmetric cipher with a Feistel structure. Camillia
was developed jointly by NTT and Mitsubishi Electric Corporation in
2000. It was designed to withstand all known cryptanalytic attacks,
and it has been scrutinized by worldwide cryptographic experts.
Camellia is suitable for implementation in software and hardware,
offering encryption speed in software and hardware implementations
that is comparable to AES.
The Camellia homepage [Camellia-Web] contains a wealth of information
about camellia, including detailed specification, security analysis,
performance figures, reference implementation, test vectors, and
intellectual property information.
The remainder of this document specifies the use of Camellia within
the context of IPsec ESP. For further information on how the various
pieces of ESP fit together to provide security services, please refer
to [ARCH], [ESP], and [ROAD].
1.1. Specification of Requirements
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" that
appear in this document are to be interpreted as described in
[RFC-2119].
2. The Camellia Cipher Algorithm
All symmetric block cipher algorithms share common characteristics
and variables, including mode, key size, weak keys, block size, and
rounds. The following sections contain descriptions of the relevant
characteristics of Camellia.
The algorithm specification and object identifiers are described in
[Camellia-Desc].
2.1. Mode
NIST has defined five modes of operation for AES and other FIPS-
approved ciphers [SP800-38a]: CBC (Cipher Block Chaining), ECB
(Electronic CodeBook), CFB (Cipher FeedBack), OFB (Output FeedBack),
and CTR (Counter). The CBC mode is well defined and well understood
for symmetric ciphers, and it is currently required for all other ESP
ciphers. This document specifies the use of the Camellia cipher in
CBC mode within ESP. This mode requires an Initialization Vector
(IV) size that is the same as the block size. Use of a randomly
generated IV prevents generation of identical cipher text from
packets that have identical data spanning the first block of the
cipher algorithm's block size.
The CBC IV is XOR'd with the first plaintext block before it is
encrypted. Then, for successive blocks, the previous cipher text
block is XOR'd with the current plain text before it is encrypted.
More information on CBC mode can be obtained in [SP800-38a,
CRYPTO-S].
2.2. Key Size
Camellia supports three key sizes: 128 bits, 192 bits, and 256 bits.
The default key size is 128 bits, and all implementations MUST
support this key size. Implementations MAY also support key sizes of
192 bits and 256 bits.
Camellia uses a different number of rounds for each of the defined
key sizes. When a 128-bit key is used, implementations MUST use 18
rounds. When a 192-bit key is used, implementations MUST use 24
rounds. When a 256-bit key is used, implementations MUST use 24
rounds.
2.3. Weak Keys
At the time of writing this document, there are no known weak keys
for Camellia.
2.4. Block Size and Padding
Camellia uses a block size of sixteen octets (128 bits).
Padding is required by the algorithms to maintain a 16-octet
(128-bit) block size. Padding MUST be added, as specified in [ESP],
such that the data to be encrypted (which includes the ESP Pad Length
and Next Header fields) is a multiple of 16 octets.
Because of the algorithm-specific padding requirement, no additional
padding is required to ensure that the ciphertext terminates on a
4-octet boundary. That is, maintaining a 16-octet block size
guarantees that the ESP Pad Length and Next Header fields will be
right-aligned within a 4-octet word). Additional padding MAY be
included, as specified in [ESP], as long as the 16-octet block size
is maintained.
2.5. Performance
Performance figures of Camellia are available at [Camellia-Web].
This web site also includes performance comparison with the AES
cipher and other AES finalists. The NESSIE project [NESSIE] has
reported performance of Optimized Implementations independently.
3. ESP Payload
The ESP payload is made up of the IV followed by raw cipher-text.
Thus, the payload field, as defined in [ESP], is broken down
according to the following diagram:
+---------------+---------------+---------------+---------------+
| |
+ Initialization Vector (16 octets) +
| |
+---------------+---------------+---------------+---------------+
| |
~ Encrypted Payload (variable length, a multiple of 16 octets) ~
| |
+---------------------------------------------------------------+
The IV field MUST be the same size as the block size of the cipher
algorithm being used. The IV MUST be chosen at random, and MUST be
unpredictable.
Including the IV in each datagram ensures that each received datagram
can be decrypted, even when some datagrams are dropped or re-ordered
in transit.
To avoid CBC encryption of very similar plaintext blocks in different
packets, implementations MUST NOT use a counter or other low
Hamming-distance source for IVs.
3.1. ESP Algorithmic Interactions
Currently, there are no known issues regarding interactions between
the Camellia and other aspects of ESP, such as the use of certain
authentication schemes.
3.2. Keying Material
The minimum number of bits sent from the key exchange protocol to the
ESP algorithm must be greater than or equal to the key size. The
cipher's encryption and decryption key is taken from the first 128,
192, or 256 bits of the keying material.
4. Interaction with Internet Key Exchange [IKE]
Camellia was designed to follow the same API as the AES cipher.
Therefore, this section defines only Phase 1 Identifier and Phase 2
Identifier. Any other consideration related to interaction with IKE
is the same as that of the AES cipher. Details can be found in
[AES-IPSEC].
4.1. Phase 1 Identifier
For Phase 1 negotiations, IANA has assigned an Encryption Algorithm
ID of 8 for CAMELLIA-CBC.
4.2. Phase 2 Identifier
For Phase 2 negotiations, IANA has assigned an ESP Transform
Identifier of 22 for ESP_CAMELLIA.
5. Security Considerations
Implementations are encouraged to use the largest key sizes they can,
taking into account performance considerations for their particular
hardware and software configuration. Note that encryption
necessarily affects both sides of a secure channel, so such
consideration must take into account not only the client side, but
also the server. However, a key size of 128 bits is considered
secure for the foreseeable future.
No security problem has been found on Camellia [CRYPTREC][NESSIE].
6. IANA Considerations
IANA has assigned Encryption Algorithm ID = 8 to CAMELLIA-CBC.
IANA has assigned ESP Transform Identifier = 22 to ESP_CAMELLIA.
7. Acknowledgements
Portions of this text were unabashedly borrowed from [AES-IPSEC].
This work was done when the first author worked for NTT.
8. References
8.1. Normative References
[Camellia-Desc] Matsui, M., Nakajima, J., and S. Moriai, "A
Description of the Camellia Encryption Algorithm",
RFC 3713, April 2004.
[ESP] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
8.2. Informative References
[AES] NIST, FIPS PUB 197, "Advanced Encryption Standard
(AES)," November 2001.
http://csrc.nist.gov/publications/fips/fips197/
fips-197.{ps,pdf}.
[AES-IPSEC] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC
Cipher Algorithm and Its Use With IPsec," RFC 3602,
September 2003.
[ARCH] Kent, S. and R. Atkinson, "Security Architecture for
the Internet Protocol", RFC 2401, November 1998.
[Camellia-CMS] Moriai, S. and A. Kato, "Use of the Camellia
Encryption Algorithm in Cryptographic Message Syntax
(CMS)", RFC 3657, January 2004.
[Camellia-Web] Camellia web site:
http://info.isl.ntt.co.jp/camellia/.
[CRYPTO-S] Schneier, B., "Applied Cryptography Second Edition",
John Wiley & Sons, New York, NY, 1995, ISBN 0-471-
12845-7.
[CRYPTREC] Information-technology Promotion Agency (IPA),
Japan, CRYPTREC.
http://www.ipa.go.jp/security/enc/CRYPTREC/ index-
e.html.
[IKE] Harkins, D. and D. Carrel, "The Internet Key
Exchange (IKE)", RFC 2409, November 1998.
[SP800-38a] Dworkin, M., "Recommendation for Block Cipher Modes
of Operation - Methods and Techniques", NIST Special
Publication 800-38A, December 2001.
[NESSIE] The NESSIE project (New European Schemes for
Signatures, Integrity and Encryption),
http://www.cosic.esat.kuleuven.ac.be/nessie/.
[ROAD] Thayer, R., Doraswamy, N., and R. Glenn, "IP
Security Document Roadmap", RFC 2411, November 1998.
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Authors' Addresses
Akihiro Kato
NTT Software Corporation
Phone: +81-45-212-7934
Fax: +81-45-212-7410
EMail: akato@po.ntts.co.jp
Shiho Moriai
Sony Computer Entertainment Inc.
Phone: +81-3-6438-7523
Fax: +81-3-6438-8629
EMail: camellia@isl.ntt.co.jp (Camellia team)
shiho@rd.scei.sony.co.jp (Shiho Moriai)
Masayuki Kanda
Nippon Telegraph and Telephone Corporation
Phone: +81-46-859-2437
Fax: +81-46-859-3365
EMail: kanda@isl.ntt.co.jp
Full Copyright Statement
Copyright (C) The Internet Society (2005).
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.
AI ELI5
On this page
§1Why Camellia in IPsec
RFC 4312 describes the use of the Camellia block cipher in Cipher Block Chaining (CBC) mode, with an explicit Initialization Vector, as a confidentiality mechanism inside the IPsec Encapsulating Security Payload (ESP).
The RFC says Camellia was selected as a recommended primitive by the EU NESSIE project and included in the list of cryptographic techniques for Japanese e-Government systems selected by CRYPTREC. It supports a 128-bit block size and 128-, 192- and 256-bit key lengths, the same interface as the Advanced Encryption Standard (AES). It is a symmetric cipher with a Feistel structure, developed jointly by NTT and Mitsubishi Electric Corporation in 2000.
The document uses the RFC 2119 keywords (MUST, SHOULD, MAY) to say what an implementation has to do.
Camellia is a lock that works just like another famous lock called AES. This memo says how to use it on IPsec, the system that protects Internet messages.
§2Camellia Characteristics
The RFC walks through the usual properties of a block cipher. For mode, it picks CBC, calling it well defined and well understood, and noting it is currently required for all other ESP ciphers. CBC needs an IV the same size as the block. The IV is XORed with the first plaintext block before encryption, and each later plaintext block is XORed with the previous ciphertext block.
Camellia supports three key sizes: 128, 192 and 256 bits. The default is 128 bits, and all implementations MUST support it. Supporting 192 and 256 bits is optional (MAY). The number of rounds depends on the key size, and implementations MUST use it.
The RFC states that at the time of writing there were no known weak keys for Camellia. For performance it only points to the Camellia web site and to NESSIE's independent report, and gives no numbers of its own.
Camellia scrambles data in chunks, and each chunk is mixed with the scrambled chunk before it. Everyone must support the standard key size, and bigger keys are optional extras.
§2.2Key Sizes and Rounds
Key length decides how many rounds of scrambling the cipher performs. The RFC uses MUST for each pairing.
- 128-bit key: 18 rounds (mandatory to support)
- 192-bit key: 24 rounds (optional)
- 256-bit key: 24 rounds (optional)
For the keying material, the amount of key bits handed from the key exchange protocol to ESP must be at least the key size. The encryption and decryption key is taken from the first 128, 192 or 256 bits of that material.
A longer secret key makes the scrambling go around more times. The shortest key is the one every device must know how to use.
| Key size | Rounds | Support |
|---|---|---|
| 128 bits | 18 | MUST support (default) |
| 192 bits | 24 | MAY support |
| 256 bits | 24 | MAY support |
§3ESP Payload Layout and Padding
The ESP payload is the IV followed by the raw ciphertext. The IV is 16 octets, the same as the block size, and the encrypted payload that follows is variable in length but always a multiple of 16 octets.
The IV MUST be chosen at random and MUST be unpredictable. Implementations MUST NOT use a counter or other low Hamming-distance source for IVs, so that very similar plaintext blocks in different packets are not encrypted in a similar way. A random IV also prevents identical ciphertext from packets whose data is identical across the first block.
Because the IV travels in every datagram, each received datagram can be decrypted even when some datagrams are dropped or re-ordered in transit.
Padding MUST be added, as specified in the ESP document, so that the data to be encrypted (including the ESP Pad Length and Next Header fields) is a multiple of 16 octets. That also keeps those two fields right-aligned in a 4-octet word, so no extra padding is needed for a 4-octet boundary. Extra padding MAY be added as long as the 16-octet block size is kept.
The RFC notes no known issues between Camellia and other parts of ESP, such as the authentication schemes used with it.
Every packet carries its own random starting number so it can be unlocked on its own, even if its neighbors go missing. The data is padded out so it fits neatly into 16-byte boxes.
§4Negotiating Camellia with IKE
Camellia follows the same API as AES, so the RFC defines only two identifiers for the Internet Key Exchange (IKE). Anything else about how IKE interacts with the cipher is the same as for AES, which the RFC leaves to the AES-CBC document, RFC 3602.
- Phase 1: Encryption Algorithm ID
8, forCAMELLIA-CBC. - Phase 2: ESP Transform Identifier
22, forESP_CAMELLIA.
IANA has assigned both values.
Before two computers talk secretly, they agree on which code to use. These two numbers are how they say "let's use Camellia."
§5Security Considerations
Implementations are encouraged to use the largest key sizes they can, weighing performance on their particular hardware and software. Encryption affects both ends of a secure channel, so the cost on the server side counts as well as the client side. Even so, the RFC says a key size of 128 bits is considered secure for the foreseeable future.
It also reports that no security problem has been found on Camellia, citing CRYPTREC and NESSIE.
Bigger keys are safer but slower, and both sides of the conversation pay the cost. The standard size is thought to be safe for a long time.