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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（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).
この文書では、IPsecカプセル化セキュリティペイロード（ESP）のコンテキスト内で機密性の仕組みとして、明示的な初期化ベクトルと、暗号ブロック連鎖モードで椿ブロック暗号アルゴリズムの使用を記載しています。
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).
この文書では、IPsecカプセル化セキュリティペイロード（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].
椿は、プロジェクト[NESSIE]（署名、整合性と暗号化のための新しいヨーロッパのスキーム）EU NESSIEの推奨する暗号プリミティブとして選ばれた、日本CRYPTREC（によって選択された日本の電子政府システムのための暗号技術のリストに含まれていました暗号技術、評価委員会）[CRYPTREC]。椿は、ISO（ISO / IEC 18033）およびIETF S / MIMEメールのセキュリティワーキンググループ[椿-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].
椿は、128ビットのブロックサイズと128、192、および256ビットの鍵長、即ち、高度暗号化標準（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.
椿はFeistel構造を持つ対称暗号です。 Camilliaは、それはすべての既知の暗号解読の攻撃に耐えるように設計されていた2000年にNTTと三菱電機が共同で開発した、そしてそれは、世界中の暗号専門家によって精査されています。椿は、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].
このドキュメントの残りの部分では、IPsec ESPの文脈の中で椿の使用を指定します。 ESPの各種セキュリティサービスを提供するために一緒に収まる方法の詳細については、[ARCH]、[ESP]、および[ROAD]を参照してください。
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].
この文書に表示されたキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "SHALL"、 "SHOULD"、 "ないもの"、 "推奨" "ない（SHOULD NOT）"、 "MAY"、および "オプション" [RFC-2119]に記載されているように解釈されるべきです。
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].
アルゴリズム仕様とオブジェクト識別子は、[椿-DESC]に記載されています。
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.
CBC（暗号ブロック連鎖）、ECB（電子ブック）、CFB（暗号フィードバック）、OFB（出力フィードバック）、及びCTR（カウンター：NISTは、AES及び他のFIPS承認の暗号[SP800-38a]のための操作の5つのモードが定義されています）。 CBCモードでは、明確に定義され、よく対称暗号のために理解され、それは現在、他のすべてのESP暗号のために必要とされます。この文書では、ESP内のCBCモードの椿暗号の使用を指定します。このモードは、ブロックサイズと同じで初期化ベクトル（IV）のサイズを必要とします。ランダムに生成されたIVの使用は、暗号アルゴリズムのブロックサイズの最初のブロックにまたがる同一のデータを持つパケットから、同一の暗号文の生成を防ぐことができます。
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].
CBC IVは、それが暗号化される前に、最初の平文ブロックとのXORをとります。それが暗号化される前に続いて、連続するブロックのために、前の暗号文ブロックは、現在、プレーンテキストとのXORをとります。 CBCモードの詳細は[SP800-38a、CRYPTO-S]で得ることができます。
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.
128ビット、192ビット、256ビット：椿は3つの主要なサイズをサポートしています。デフォルトのキーサイズは128ビットであり、すべての実装がこのキーサイズをサポートしなければなりません。また、実装は192ビット、256ビットのキーサイズをサポートするかもしれません。
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.
椿は、定義された鍵サイズのそれぞれについてラウンドの異なる番号を使用します。 128ビットのキーを使用した場合、実装は18ラウンドを使用しなければなりません。 192ビットの鍵を使用した場合、実装は24ラウンドを使用しなければなりません。 256ビットの鍵を使用した場合、実装は24ラウンドを使用しなければなりません。
At the time of writing this document, there are no known weak keys for Camellia.
この文書を書いている時点では、ツバキのための既知の弱いキーが存在しません。
Camellia uses a block size of sixteen octets (128 bits).
椿は、16個のオクテット（128ビット）のブロックサイズを使用します。
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.
パディングは、16オクテット（128ビット）のブロック・サイズを維持するためにアルゴリズムによって必要とされます。 [ESP]で指定されるようにパディングが追加されなければならない、（ESPパッド長と次ヘッダフィールドを含む）データを暗号化するように16オクテットの倍数です。
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.
そのため、アルゴリズム固有のパディングの要件のため、追加のパディングは暗号文が4オクテット境界で終了していることを保証するために必要とされません。すなわち）ESPパッドの長さと次ヘッダフィールドは4オクテットワード内で右に整列されることが16オクテットブロックサイズ保証を維持すること、です。 [ESP]で指定されるように、追加のパディングがあれば、16オクテットのブロックサイズが維持されるように、含まれてもよいです。
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.
椿のパフォーマンス実績は、[椿-ウェブ]でご利用いただけます。このウェブサイトはまた、AES暗号と他のAESのファイナリストとの性能比較を含んでいます。 NESSIEプロジェクト[NESSIE]は独立して最適化の実装のパフォーマンスを報告しています。
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:
ESPペイロードは、生の暗号文に続くIVで構成されています。したがって、[ESP]で定義されるようにペイロードフィールドは、以下の図に従って分解されます。
+---------------+---------------+---------------+---------------+
| |
+ 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.
IVフィールドが使用されている暗号アルゴリズムのブロックサイズと同じサイズでなければなりません。 IVはランダムに選択されなければならない、と予測不可能でなければなりません。
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.
各データグラムにIVを含むことは、それぞれがいくつかのデータグラムを落としたり輸送中に再注文された場合でも、データグラムを解読することができる受信ことを保証します。
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.
異なるパケットの非常に似通った平文ブロックのCBC暗号化を避けるために、実装は、カウンターやのIVのための他の低ハミング距離のソースを使用してはなりません。
Currently, there are no known issues regarding interactions between the Camellia and other aspects of ESP, such as the use of certain authentication schemes.
現在、特定の認証スキームの使用など椿やESPの他の側面の間の相互作用、に関する既知の問題はありません。
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.
ESPアルゴリズムに鍵交換プロトコルから送信されたビットの最小数は、キーのサイズより大きいか等しくなければなりません。暗号の暗号化および復号化鍵を鍵素材の最初の128、192、または256ビットから取り出されます。
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].
椿は、AES暗号と同じAPIを追跡するために設計されました。したがって、このセクションは、フェーズ1の識別子及びフェーズ2の識別子を定義します。 IKEとの相互作用に関連する任意の他の考慮事項は、AES暗号の場合と同様です。詳細は[AES-IPSEC]で見つけることができます。
For Phase 1 negotiations, IANA has assigned an Encryption Algorithm ID of 8 for CAMELLIA-CBC.
フェーズ1つのネゴシエーションのために、IANAがcamellia-CBCのための8の暗号化アルゴリズムIDが割り当てられています。
For Phase 2 negotiations, IANA has assigned an ESP Transform Identifier of 22 for ESP_CAMELLIA.
フェーズ2つのネゴシエーションのために、IANAは、ESPはESP_CAMELLIAための22の識別子を変換割り当てました。
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.
実装は、彼らは、彼らの特定のハードウェアおよびソフトウェアの構成のためのアカウントのパフォーマンスに関する考慮事項を考慮することができ、最大のキーサイズを使用することをお勧めします。こうした配慮は、アカウントにクライアント側でなく、サーバーだけでなくを取る必要がありますので、その暗号化が必ずしも、安全なチャネルの両側に影響します。しかし、128ビットのキーサイズは、予見可能な将来のために安全であると考えています。
No security problem has been found on Camellia [CRYPTREC][NESSIE].
セキュリティ上の問題は椿[CRYPTREC] [NESSIE]で発見されていなかったん。
IANA has assigned Encryption Algorithm ID = 8 to CAMELLIA-CBC.
IANAがcamellia-CBCに暗号化アルゴリズムID = 8を割り当てています。
IANA has assigned ESP Transform Identifier = 22 to ESP_CAMELLIA.
IANAは、ESP ESP_CAMELLIAに識別子= 22を変換割り当てました。
Portions of this text were unabashedly borrowed from [AES-IPSEC].
This work was done when the first author worked for NTT.
[Camellia-Desc] Matsui, M., Nakajima, J., and S. Moriai, "A Description of the Camellia Encryption Algorithm", RFC 3713, April 2004.
[椿-DESC]松井、M.、中島、J.、およびS. Moriai、 "椿暗号化アルゴリズムの説明"、RFC 3713、2004年4月。
[ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[ESP]ケント、S.、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 4303、2005年12月。
[AES] NIST, FIPS PUB 197, "Advanced Encryption Standard (AES)," November 2001. http://csrc.nist.gov/publications/fips/fips197/ fips-197.{ps,pdf}.
[AES] NIST、FIPSパブ197、 "高度暗号化標準（AES）、" 2001年11月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.
[AES-IPSEC]フランケル、S.、グレン、R.、およびS.ケリー、 "AES-CBC暗号アルゴリズムおよびIPSecでの使用、" RFC 3602、2003年9月。
[ARCH] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[ARCH]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[Camellia-CMS] Moriai, S. and A. Kato, "Use of the Camellia Encryption Algorithm in Cryptographic Message Syntax (CMS)", RFC 3657, January 2004.
[椿-CMS] Moriai、S.およびA.加藤、 "暗号メッセージ構文（CMS）で椿暗号化アルゴリズムの使用"、RFC 3657、2004年1月。
[Camellia-Web] Camellia web site: http://info.isl.ntt.co.jp/camellia/.
[椿-ウェブ]カメリアウェブサイト：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.
[CRYPTO-S]シュナイアー、B.、 "応用暗号第二版"、John Wiley＆Sons、ニューヨーク、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.
[CRYPTREC]情報処理推進機構（IPA）、日本、CRYPTREC。 http://www.ipa.go.jp/security/enc/CRYPTREC/インデックスe.html。
[IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[IKE]ハーキンとD.とD.カレル、 "インターネットキー交換（IKE）"、RFC 2409、1998年11月。
[SP800-38a] Dworkin, M., "Recommendation for Block Cipher Modes of Operation - Methods and Techniques", NIST Special Publication 800-38A, December 2001.
、は、NIST Special Publication 800-38A、2001年12月 - [SP800-38a] Dworkin、M.、 "方法と技術の動作のブロック暗号モードのための勧告"。
[NESSIE] The NESSIE project (New European Schemes for Signatures, Integrity and Encryption), http://www.cosic.esat.kuleuven.ac.be/nessie/.
、http://www.cosic.esat.kuleuven.ac.be/nessie/ [NESSIE] NESSIEプロジェクト（署名、整合性と暗号化のための新しいヨーロッパのスキーム）。
[ROAD] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.
[ROAD]セイヤー、R.、Doraswamy、N.、およびR.グレン、 "IPセキュリティドキュメントロードマップ"、RFC 2411、1998年11月。
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
Authors' Addresses
著者のアドレス
Akihiro Kato NTT Software Corporation
あきひろ かと んっｔ そｆとぁれ こｒぽらちおん
Phone: +81-45-212-7934 Fax: +81-45-212-7410 EMail: akato@po.ntts.co.jp
電話：+ 81-45-212-7934ファックス：+ 81-45-212-7410 Eメール：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
日本電信電話株式会社神田masayiki
Phone: +81-46-859-2437 Fax: +81-46-859-3365 EMail: kanda@isl.ntt.co.jp
電話：+ 81-46-859-2437ファックス：+ 81-46-859-3365 Eメール：kanda@isl.ntt.co.jp
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78および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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。