[要約] 要約：RFC 4312は、Camellia暗号アルゴリズムとそのIPsecでの使用について説明しています。 目的：Camellia暗号アルゴリズムの詳細とIPsecでの使用方法を提供し、セキュリティの向上を促進することです。
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
Camellia cipherアルゴリズムと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).
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).
このドキュメントでは、セキュリティペイロードをカプセル化するIPSEC（ESP）のコンテキスト内での機密性メカニズムとして、明示的な初期化ベクトルを使用した、暗号ブロックチェーンモードでのCamelliaブロック暗号アルゴリズムの使用について説明します。
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ブロック暗号アルゴリズムの使用について説明します。
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は、EU Nessie（署名、整合性、暗号化のための新しいヨーロッパのスキーム）プロジェクト[nessie]によって推奨される暗号化原始として選択され、日本Cryptrec（日本の電子政府システムの暗号化技術のリストに含まれていました（日本Cryptrec）（暗号化の研究、評価委員会）[Cryptrec]。Camelliaは、ISO（ISO/IEC 18033）やIETF S/MIMEメールセキュリティワーキンググループ[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は、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.
Camelliaは、Feistel構造を持つ対称暗号です。Camilliaは、2000年にNTTとMitsubishi Electric Corporationによって共同で開発されました。すべての既知の暗号化攻撃に耐えるように設計されており、世界的な暗号化の専門家によって精査されています。Camelliaは、ソフトウェアとハードウェアの実装に適しており、AEに匹敵するソフトウェアとハードウェアの実装で暗号化速度を提供します。
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.
Camellia Homepage [Camellia-Web]には、詳細な仕様、セキュリティ分析、パフォーマンス数値、参照実装、テストベクトル、知的財産情報など、Camelliaに関する豊富な情報が含まれています。
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].
キーワードは「必要はない」、「必要」、「必須」、「shall」、「shall "、" bood "、" nove "、" becommended "、"、 "、" optional "、" optional "[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.
すべての対称ブロック暗号アルゴリズムは、モード、キーサイズ、弱いキー、ブロックサイズ、ラウンドなど、共通の特性と変数を共有します。次のセクションには、Camelliaの関連特性の説明が含まれています。
The algorithm specification and object identifiers are described in [Camellia-Desc].
アルゴリズムの仕様とオブジェクト識別子は、[Camellia-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.
NISTは、AESおよびその他のFIPSが承認した暗号の5つの操作モード[SP800-38A]を定義しています：CBC（暗号ブロックチェーン）、ECB（電子コードブック）、CFB（暗号フィードバック）、OFB（出力フィードバック）、およびCTR（カウンター（カウンター））。CBCモードはよく定義されており、対称的な暗号についてよく理解されており、現在、他のすべてのESP暗号に必要です。このドキュメントは、ESP内のCBCモードでのCamellia暗号の使用を指定しています。このモードには、ブロックサイズと同じ初期化ベクトル（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'dです。次に、連続したブロックの場合、以前の暗号テキストブロックは、暗号化される前に現在のプレーンテキストでXor'dです。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.
Camelliaは、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.
Camelliaは、定義されたキーサイズごとに異なる数のラウンドを使用しています。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).
Camelliaは、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オクテットの境界で終了することを確認するために追加のパディングは必要ありません。つまり、16オクセットのブロックサイズのサイズを維持することで、ESPパッドの長さと次のヘッダーフィールドが4オクテットの単語内で右に整列されることが保証されます）。16オクテットのブロックサイズが維持されている限り、[ESP]で指定されているように、追加のパディングを含めることができます。
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.
Camelliaのパフォーマンス数は[Camellia-Web]で入手できます。このWebサイトには、AES Cipherおよびその他のAESファイナリストとのパフォーマンス比較も含まれています。Nessie Project [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.
現在、特定の認証スキームの使用など、Camelliaと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、または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].
Camelliaは、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_CAMELLIAに22のESP変換識別子を割り当てました。
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].
Camellia [Cryptrec] [Nessie]でセキュリティの問題は見つかりませんでした。
IANA has assigned Encryption Algorithm ID = 8 to CAMELLIA-CBC.
IANAは、暗号化アルゴリズムID = 8をCamellia-CBCに割り当てました。
IANA has assigned ESP Transform Identifier = 22 to ESP_CAMELLIA.
IANAは、ESP変換識別子= 22をESP_Camelliaに割り当てました。
Portions of this text were unabashedly borrowed from [AES-IPSEC]. This work was done when the first author worked for NTT.
このテキストの一部は、[AES-IPSEC]からab然と借用されました。この作業は、最初の著者がNTTで働いたときに行われました。
[Camellia-Desc] Matsui, M., Nakajima, J., and S. Moriai, "A Description of the Camellia Encryption Algorithm", RFC 3713, April 2004.
[Camellia-desc] Matsui、M.、Nakajima、J。、およびS. Moriai、「Camellia暗号化アルゴリズムの説明」、RFC 3713、2004年4月。
[ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[ESP] Kent、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 Pub 197、「Advanced Encryption Standard（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] Frankel、S.、Glenn、R。、およびS. Kelly、「AES-CBC暗号アルゴリズムとIPSECでの使用」、RFC 3602、2003年9月。
[ARCH] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[Arch] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、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.
[Camellia-CMS] Moriai、S。およびA. Kato、「暗号化メッセージ構文（CMS）でのCamellia暗号化アルゴリズムの使用」、RFC 3657、2004年1月。
[Camellia-Web] Camellia web site: http://info.isl.ntt.co.jp/camellia/.
[Camellia-Web] Camellia Webサイト：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] 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.
[CRYPTREC]情報技術プロモーションエージェンシー（IPA）、日本、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.
[Ike] Harkins、D。およびD. Carrel、「The Internet Key Exchange（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.
[SP800-38A] Dworkin、M。、「操作のブロックモードの推奨 - 方法とテクニックの推奨」、NIST Special Publication 800-38A、2001年12月。
[NESSIE] The NESSIE project (New European Schemes for Signatures, Integrity and Encryption), http://www.cosic.esat.kuleuven.ac.be/nessie/.
[nessie]ネッシープロジェクト（署名、整合性、暗号化のための新しいヨーロッパのスキーム）、http：//www.cosic.esat.kuleuven.ac.be/nessie/。
[ROAD] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.
[Road] Thayer、R.、Doraswamy、N。、およびR. Glenn、「IP Security Document Roadmap」、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
Authors' Addresses
著者のアドレス
Akihiro Kato NTT Software Corporation
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.
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
正ayukiカンダ・ニッポン・テレグラフと電話会社
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).
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.
この文書は、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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。