[要約] RFC 2451は、ESP CBC-Mode Cipher Algorithmsに関する仕様を定義しており、IPsecプロトコルで使用される暗号アルゴリズムに関する情報を提供しています。このRFCの目的は、セキュリティの向上と暗号化アルゴリズムの標準化を促進することです。
Network Working Group R. Pereira
Request for Comments: 2451 TimeStep Corporation
Category: Standards Track R. Adams
Cisco Systems Inc.
November 1998
The ESP CBC-Mode Cipher Algorithms
ESP CBCモード暗号アルゴリズム
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 (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
Abstract
概要
This document describes how to use CBC-mode cipher algorithms with the IPSec ESP (Encapsulating Security Payload) Protocol. It not only clearly states how to use certain cipher algorithms, but also how to use all CBC-mode cipher algorithms.
このドキュメントでは、IPSec ESP（カプセル化セキュリティペイロード）プロトコルでCBCモードの暗号化アルゴリズムを使用する方法について説明します。特定の暗号アルゴリズムの使用方法だけでなく、すべてのCBCモード暗号アルゴリズムの使用方法も明確に述べています。
Table of Contents
目次
1. Introduction...................................................2
1.1 Specification of Requirements...............................2
1.2 Intellectual Property Rights Statement......................2
2. Cipher Algorithms..............................................2
2.1 Mode........................................................3
2.2 Key Size....................................................3
2.3 Weak Keys...................................................4
2.4 Block Size and Padding......................................5
2.5 Rounds......................................................6
2.6 Backgrounds.................................................6
2.7 Performance.................................................8
3. ESP Payload....................................................8
3.1 ESP Environmental Considerations............................9
3.2 Keying Material.............................................9
4. Security Considerations........................................9
5. References....................................................10
6. Acknowledgments...............................................11
7. Editors' Addresses............................................12
8. Full Copyright Statement......................................14
The Encapsulating Security Payload (ESP) [Kent98] provides confidentiality for IP datagrams by encrypting the payload data to be protected. This specification describes the ESP use of CBC-mode cipher algorithms.
カプセル化セキュリティペイロード（ESP）[Kent98]は、保護されるペイロードデータを暗号化することにより、IPデータグラムの機密性を提供します。この仕様では、CBCモードの暗号アルゴリズムのESP使用について説明しています。
While this document does not describe the use of the default cipher algorithm DES, the reader should be familiar with that document. [Madson98]
このドキュメントではデフォルトの暗号アルゴリズムDESの使用については説明していませんが、読者はそのドキュメントに精通している必要があります。 [Madson98]
It is assumed that the reader is familiar with the terms and concepts described in the "Security Architecture for the Internet Protocol" [Atkinson95], "IP Security Document Roadmap" [Thayer97], and "IP Encapsulating Security Payload (ESP)" [Kent98] documents.
「インターネットプロトコルのセキュリティアーキテクチャ」[Atkinson95]、「IPセキュリティドキュメントロードマップ」[Thayer97]、および「IPカプセル化セキュリティペイロード（ESP）」[Kent98 ]ドキュメント。
Furthermore, this document is a companion to [Kent98] and MUST be read in its context.
さらに、このドキュメントは[Kent98]の仲間であり、そのコンテキストで読む必要があります。
The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", and "MAY" that appear in this document are to be interpreted as described in [Bradner97].
このドキュメントに表示されるキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHOULD」、「SHOULD NOT」、および「MAY」は、[Bradner97]の説明に従って解釈されます。
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 Secretariat.
IETFは、このドキュメントに記載されているテクノロジーの実装または使用に関連すると主張される可能性がある知的財産またはその他の権利の有効性または範囲、またはそのような権利に基づくライセンスが適用されるまたは適用されない範囲に関して、いかなる立場も取らない。利用可能。また、そのような権利を特定するために何らかの努力をしたことも表していません。標準化過程および標準化関連文書の権利に関するIETFの手順に関する情報は、BCP-11にあります。公開のために利用可能になった権利の主張と利用可能になるライセンスの保証のコピー、またはこの仕様の実装者またはユーザーによる一般的なライセンスまたはそのような所有権の使用の許可を得ようとした試みの結果を入手できます。 IETF事務局から。
All symmetric block cipher algorithms share common characteristics and variables. These include mode, key size, weak keys, block size, and rounds. All of which will be explained below.
すべての対称ブロック暗号アルゴリズムは、共通の特性と変数を共有しています。これらには、モード、キーサイズ、弱いキー、ブロックサイズ、ラウンドが含まれます。以下にそのすべてを説明します。
While this document illustrates certain cipher algorithms such as Blowfish [Schneier93], CAST-128 [Adams97], 3DES, IDEA [Lai] [MOV], and RC5 [Baldwin96], any other block cipher algorithm may be used with ESP if all of the variables described within this document are clearly defined.
このドキュメントでは、Blowfish [Schneier93]、CAST-128 [Adams97]、3DES、IDEA [Lai] [MOV]、RC5 [Baldwin96]などの特定の暗号アルゴリズムについて説明していますが、ESPで他のすべてのブロック暗号アルゴリズムを使用できる場合は、このドキュメントで説明されている変数は明確に定義されています。
All symmetric block cipher algorithms described or insinuated within this document use Cipher Block Chaining (CBC) mode. This mode requires an Initialization Vector (IV) that is the same size as the block size. Use of a randomly generated IV prevents generation of identical ciphertext from packets which have identical data that spans the first block of the cipher algorithm's blocksize.
このドキュメント内で説明または示唆されているすべての対称ブロック暗号アルゴリズムは、暗号ブロック連鎖（CBC）モードを使用します。このモードでは、ブロックサイズと同じサイズの初期化ベクトル（IV）が必要です。ランダムに生成されたIVを使用すると、暗号アルゴリズムのブロックサイズの最初のブロックにまたがる同一のデータを持つパケットから同一の暗号文が生成されるのを防ぎます。
The IV is XOR'd with the first plaintext block, before it is encrypted. Then for successive blocks, the previous ciphertext block is XOR'd with the current plaintext, before it is encrypted.
IVは、暗号化される前に、最初の平文ブロックとXORされます。次に、連続するブロックの場合、前の暗号文ブロックは、暗号化される前に現在の平文とXORされます。
More information on CBC mode can be obtained in [Schneier95].
CBCモードの詳細については、[Schneier95]を参照してください。
Some cipher algorithms allow for variable sized keys, while others only allow a specific key size. The length of the key correlates with the strength of that algorithm, thus larger keys are always harder to break than shorter ones.
一部の暗号化アルゴリズムは可変サイズの鍵を許可しますが、他の暗号化アルゴリズムは特定の鍵サイズのみを許可します。キーの長さはそのアルゴリズムの強度と相関関係があるため、大きいキーは短いキーより常に壊れにくいです。
This document stipulates that all key sizes MUST be a multiple of 8 bits.
このドキュメントでは、すべてのキーサイズが8ビットの倍数でなければならないことを規定しています。
This document does specify the default key size for each cipher algorithm. This size was chosen by consulting experts on the algorithm and by balancing strength of the algorithm with performance.
このドキュメントでは、各暗号化アルゴリズムのデフォルトの鍵サイズを指定しています。このサイズは、アルゴリズムの専門家に相談し、アルゴリズムの強度とパフォーマンスのバランスをとることによって選択されました。
+==============+==================+=================+==========+
| Algorithm | Key Sizes (bits) | Popular Sizes | Default |
+==============+==================+=================+==========+
| CAST-128 [1] | 40 to 128 | 40, 64, 80, 128 | 128 |
+--------------+------------------+-----------------+----------+
| RC5 | 40 to 2040 | 40, 128, 160 | 128 |
+--------------+------------------+-----------------+----------+
| IDEA | 128 | 128 | 128 |
+--------------+------------------+-----------------+----------+
| Blowfish | 40 to 448 | 128 | 128 |
+--------------+------------------+-----------------+----------+
| 3DES [2] | 192 | 192 | 192 |
+--------------+------------------+-----------------+----------+
Notes:
ノート：
[1] With CAST-128, keys less than 128 bits MUST be padded with zeros in the rightmost, or least significant, positions out to 128 bits since the CAST-128 key schedule assumes an input key of 128 bits. Thus if you had a key with a size of 80 bits '3B5D831CFE', it would be padded to produce a key with a size of 128 bits '3B5D831CFE000000'.
[1] CAST-128では、CAST-128のキースケジュールが128ビットの入力キーを想定しているため、128ビット未満のキーは、右端または最下位の位置にゼロを埋めて128ビットに配置する必要があります。したがって、80ビットのサイズのキー「3B5D831CFE」がある場合、128ビットのサイズのキー「3B5D831CFE000000」を生成するためにパディングされます。
[2] The first 3DES key is taken from the first 64 bits, the second from the next 64 bits, and the third from the last 64 bits. Implementations MUST take into consideration the parity bits when initially accepting a new set of keys. Each of the three keys is really 56 bits in length with the extra 8 bits used for parity.
[2] 最初の3DES鍵は最初の64ビットから取得され、2番目は次の64ビットから取得され、3番目は最後の64ビットから取得されます。実装では、最初に新しいキーのセットを受け入れるときに、パリティビットを考慮する必要があります。 3つのキーはそれぞれ、実際には56ビットの長さで、追加の8ビットがパリティに使用されます。
The reader should note that the minimum key size for all of the above cipher algorithms is 40 bits, and that the authors strongly advise that implementations do NOT use key sizes smaller than 40 bits.
読者は、上記のすべての暗号アルゴリズムの最小キーサイズは40ビットであり、実装者は実装で40ビット未満のキーサイズを使用しないことを強くお勧めします。
Weak key checks SHOULD be performed. If such a key is found, the key SHOULD be rejected and a new SA requested. Some cipher algorithms have weak keys or keys that MUST not be used due to their weak nature.
弱い鍵のチェックを実行する必要があります。そのような鍵が見つかった場合、その鍵は拒否されるべきであり、新しいSAが要求されます。一部の暗号化アルゴリズムには、弱い鍵、またはその性質が弱いために使用してはならない鍵があります。
New weak keys might be discovered, so this document does not in any way contain all possible weak keys for these ciphers. Please check with other sources of cryptography such as [MOV] and [Schneier] for further weak keys.
新しい脆弱な鍵が見つかる可能性があるため、このドキュメントには、これらの暗号で考えられるすべての脆弱な鍵は含まれていません。さらに弱い鍵については、[MOV]や[Schneier]などの他の暗号化ソースで確認してください。
CAST-128:
CAST-128：
No known weak keys.
既知の弱いキーはありません。
RC5:
RC5：
No known weak keys when used with 16 rounds.
16ラウンドで使用する場合、既知の弱いキーはありません。
IDEA:
考え：
IDEA has been found to have weak keys. Please check with [MOV] and [Schneier] for more information.
IDEAのキーは弱いことが判明しています。詳細については、[MOV]と[Schneier]で確認してください。
Blowfish:
ふぐ：
Weak keys for Blowfish have been discovered. Weak keys are keys that produce the identical entries in a given S-box. Unfortunately, there is no way to test for weak keys before the S- box values are generated. However, the chances of randomly generating such a key are small.
Blowfishの弱いキーが発見されました。ウィークキーは、特定のSボックスに同じエントリを生成するキーです。残念ながら、S-box値が生成される前に弱いキーをテストする方法はありません。ただし、そのようなキーをランダムに生成する可能性はわずかです。
3DES:
3DES：
DES has 64 known weak keys, including so-called semi-weak keys and possibly-weak keys [Schneier95, pp 280-282]. The likelihood of picking one at random is negligible.
DESには64個の既知の弱い鍵があり、いわゆる半弱い鍵と、場合によっては弱い鍵があります[Schneier95、pp 280-282]。ランダムに選択する可能性はごくわずかです。
For DES-EDE3, there is no known need to reject weak or complementation keys. Any weakness is obviated by the use of multiple keys.
DES-EDE3の場合、脆弱なキーまたは補完キーを拒否する必要は知られていない。複数のキーを使用することで、弱点を取り除くことができます。
However, if the first two or last two independent 64-bit keys are equal (k1 == k2 or k2 == k3), then the 3DES operation is simply the same as DES. Implementers MUST reject keys that exhibit this property.
ただし、最初の2つまたは最後の2つの独立した64ビットキーが等しい場合（k1 == k2またはk2 == k3）、3DES操作はDESと同じです。実装者は、このプロパティを示すキーを拒否する必要があります。
All of the algorithms described in this document use a block size of eight octets (64 bits).
このドキュメントで説明するすべてのアルゴリズムは、8オクテット（64ビット）のブロックサイズを使用します。
Padding is used to align the payload type and pad length octets as specified in [Kent98]. Padding must be sufficient to align the data to be encrypted to an eight octet (64 bit) boundary.
[Kent98]で指定されているように、ペイロードタイプとパッド長オクテットを揃えるためにパディングが使用されます。パディングは、暗号化されるデータを8オクテット（64ビット）境界に揃えるのに十分でなければなりません。
This variable determines how many times a block is encrypted. While this variable MAY be negotiated, a default value MUST always exist when it is not negotiated.
この変数は、ブロックが暗号化される回数を決定します。この変数は交渉されるかもしれませんが、交渉されないときは常にデフォルト値が存在しなければなりません。
+====================+============+======================+
| Algorithm | Negotiable | Default Rounds |
+====================+============+======================+
| CAST-128 | No | key<=80 bits, 12 |
| | | key>80 bits, 16 |
+--------------------+------------+----------------------+
| RC5 | No | 16 |
+--------------------+------------+----------------------+
| IDEA | No | 8 |
+--------------------+------------+----------------------+
| Blowfish | No | 16 |
+--------------------+------------+----------------------+
| 3DES | No | 48 (16x3) |
+--------------------+------------+----------------------+
CAST-128:
CAST-128：
The CAST design procedure was originally developed by Carlisle Adams and Stafford Tavares at Queen's University, Kingston, Ontario, Canada. Subsequent enhancements have been made over the years by Carlisle Adams and Michael Wiener of Entrust Technologies. CAST-128 is the result of applying the CAST Design Procedure as outlined in [Adams97].
CAST設計手順は、カナダのオンタリオ州キングストンにあるクイーンズ大学のカーライルアダムスとスタッフォードタバレスによって最初に開発されました。 Entrust TechnologiesのCarlisle AdamsとMichael Wienerによって、その後の拡張が長年にわたって行われてきました。 CAST-128は、[Adams97]で概説されているCAST設計手順を適用した結果です。
RC5:
RC5：
The RC5 encryption algorithm was developed by Ron Rivest for RSA Data Security Inc. in order to address the need for a high- performance software and hardware ciphering alternative to DES. It is patented (pat.no. 5,724,428). A description of RC5 may be found in [MOV] and [Schneier].
RC5暗号化アルゴリズムは、DESに代わる高性能ソフトウェアおよびハードウェア暗号化の必要性に対処するために、RSA Data Security Inc.のRon Rivestによって開発されました。特許を取得しています（特許番号5,724,428）。 RC5の説明は[MOV]と[Schneier]にあります。
IDEA:
考え：
Xuejia Lai and James Massey developed the IDEA (International Data Encryption Algorithm) algorithm. The algorithm is described in detail in [Lai], [Schneier] and [MOV].
Xuejia LaiとJames MasseyがIDEA（International Data Encryption Algorithm）アルゴリズムを開発しました。アルゴリズムについては、[Lai]、[Schneier]、[MOV]で詳しく説明しています。
The IDEA algorithm is patented in Europe and in the United States with patent application pending in Japan. Licenses are required for commercial uses of IDEA.
IDEAアルゴリズムはヨーロッパとアメリカで特許を取得しており、日本では特許申請中です。 IDEAの商用利用にはライセンスが必要です。
For patent and licensing information, contact:
特許およびライセンス情報については、以下にお問い合わせください。
Ascom Systec AG, Dept. CMVV
Gewerbepark, CH-5506
Magenwil, Switzerland
Phone: +41 64 56 59 83
Fax: +41 64 56 59 90
idea@ascom.ch
http://www.ascom.ch/Web/systec/policy/normal/exhibit1.html
Blowfish:
ふぐ：
Bruce Schneier of Counterpane Systems developed the Blowfish block cipher algorithm. The algorithm is described in detail in [Schneier93], [Schneier95] and [Schneier].
Counterpane SystemsのBruce SchneierがBlowfishブロック暗号アルゴリズムを開発しました。アルゴリズムについては、[Schneier93]、[Schneier95]、[Schneier]で詳しく説明しています。
3DES:
3DES：
This DES variant, colloquially known as "Triple DES" or as DES-EDE3, processes each block three times, each time with a different key. This technique of using more than one DES operation was proposed in [Tuchman79].
このDESバリアントは、通称「トリプルDES」またはDES-EDE3として知られており、各ブロックを3回処理し、毎回異なるキーを使用します。複数のDES操作を使用するこの手法は、[Tuchman79]で提案されました。
P1 P2 Pi
| | |
IV->->(X) +>->->->(X) +>->->->(X)
v ^ v ^ v
+-----+ ^ +-----+ ^ +-----+
k1->| E | ^ k1->| E | ^ k1->| E |
+-----+ ^ +-----+ ^ +-----+
| ^ | ^ |
v ^ v ^ v
+-----+ ^ +-----+ ^ +-----+
k2->| D | ^ k2->| D | ^ k2->| D |
+-----+ ^ +-----+ ^ +-----+
| ^ | ^ |
v ^ v ^ v
+-----+ ^ +-----+ ^ +-----+
k3->| E | ^ k3->| E | ^ k3->| E |
+-----+ ^ +-----+ ^ +-----+
| ^ | ^ |
+>->->+ +>->->+ +>->->
| | |
C1 C2 Ci
The DES-EDE3-CBC algorithm is a simple variant of the DES-CBC algorithm [FIPS-46]. The "outer" chaining technique is used.
DES-EDE3-CBCアルゴリズムは、DES-CBCアルゴリズム[FIPS-46]の単純な変形です。 「外部」連鎖技法が使用されます。
In DES-EDE3-CBC, an Initialization Vector (IV) is XOR'd with the first 64-bit (8 byte) plaintext block (P1). The keyed DES function is iterated three times, an encryption (Ek1) followed by a decryption (Dk2) followed by an encryption (Ek3), and generates the ciphertext (C1) for the block. Each iteration uses an independent key: k1, k2 and k3.
DES-EDE3-CBCでは、初期化ベクトル（IV）が最初の64ビット（8バイト）平文ブロック（P1）とXORされます。キー付きDES関数は、暗号化（Ek1）に続いて復号化（Dk2）に続いて暗号化（Ek3）が3回繰り返され、ブロックの暗号文（C1）が生成されます。各反復では、独立したキーk1、k2、k3を使用します。
For successive blocks, the previous ciphertext block is XOR'd with the current plaintext (Pi). The keyed DES-EDE3 encryption function generates the ciphertext (Ci) for that block.
連続するブロックの場合、前の暗号文ブロックは現在の平文（Pi）とXORされます。キー付きDES-EDE3暗号化機能は、そのブロックの暗号文（Ci）を生成します。
To decrypt, the order of the functions is reversed: decrypt with k3, encrypt with k2, decrypt with k1, and XOR the previous ciphertext block.
復号化するには、関数の順序を逆にします。k3で復号化し、k2で暗号化し、k1で復号化し、前の暗号文ブロックをXORします。
Note that when all three keys (k1, k2 and k3) are the same, DES-EDE3-CBC is equivalent to DES-CBC. This property allows the DES-EDE3 hardware implementations to operate in DES mode without modification.
3つのキー（k1、k2、k3）がすべて同じ場合、DES-EDE3-CBCはDES-CBCと同等であることに注意してください。このプロパティにより、DES-EDE3ハードウェア実装は変更せずにDESモードで動作できます。
For more explanation and implementation information for Triple DES, see [Schneier95].
Triple DESの詳細と実装情報については、[Schneier95]を参照してください。
For a comparison table of the estimated speed of any of these and other cipher algorithms, please see [Schneier97] or for an up-to-date performance comparison, please see [Bosseleaers].
これらおよびその他の暗号アルゴリズムの推定速度の比較表については、[Schneier97]を参照してください。または、最新のパフォーマンス比較については、[Bosseleaers]を参照してください。
The ESP payload is made up of the IV followed by raw cipher-text. Thus the payload field, as defined in [Kent98], is broken down according to the following diagram:
ESPペイロードはIVで構成され、その後に生の暗号文が続きます。したがって、[Kent98]で定義されているペイロードフィールドは、次の図に従って分解されます。
+---------------+---------------+---------------+---------------+
| |
+ Initialization Vector (8 octets) +
| |
+---------------+---------------+---------------+---------------+
| |
~ Encrypted Payload (variable length) ~
| |
+---------------------------------------------------------------+
1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
The IV field MUST be same size as the block size of the cipher algorithm being used. The IV MUST be chosen at random. Common practice is to use random data for the first IV and the last block of encrypted data from an encryption process as the IV for the next encryption process.
IVフィールドは、使用されている暗号アルゴリズムのブロックサイズと同じサイズでなければなりません。 IVはランダムに選択する必要があります。一般的な方法は、次の暗号化プロセスのIVとして、暗号化プロセスからの暗号化データの最初のIVと最後のブロックにランダムデータを使用することです。
Including the IV in each datagram ensures that decryption of each received datagram can be performed, even when some datagrams are dropped, or datagrams are re-ordered in transit.
各データグラムにIVを含めることで、一部のデータグラムがドロップされたり、転送中にデータグラムが並べ替えられたりした場合でも、受信した各データグラムの復号化を確実に実行できます。
To avoid ECB encryption of very similar plaintext blocks in different packets, implementations MUST NOT use a counter or other low-Hamming distance source for IVs.
異なるパケットの非常に類似した平文ブロックのECB暗号化を回避するために、実装はIVにカウンターまたは他の低ハミング距離ソースを使用してはなりません。
Currently, there are no known issues regarding interactions between these algorithms and other aspects of ESP, such as use of certain authentication schemes.
現在、これらのアルゴリズムと特定の認証スキームの使用など、ESPの他の側面との間の相互作用に関する既知の問題はありません。
The minimum number of bits sent from the key exchange protocol to this ESP algorithm must be greater or equal to the key size.
鍵交換プロトコルからこのESPアルゴリズムに送信される最小ビット数は、鍵サイズ以上でなければなりません。
The cipher's encryption and decryption key is taken from the first <x> bits of the keying material, where <x> represents the required key size.
暗号の暗号化および復号化キーは、キー情報の最初の<x>ビットから取得されます。<x>は必要なキーサイズを表します。
Implementations are encouraged to use the largest key sizes they can when taking into account performance considerations for their particular hardware and software configuration. Note that encryption necessarily impacts both sides of a secure channel, so such consideration must take into account not only the client side, but the server as well.
特定のハードウェアおよびソフトウェア構成のパフォーマンスに関する考慮事項を考慮に入れる場合、実装では、最大のキーサイズを使用することをお勧めします。暗号化は必ずセキュアチャネルの両側に影響を与えるため、このような考慮事項ではクライアント側だけでなくサーバーも考慮する必要があります。
For information on the case for using random values please see [Bell97].
ランダム値を使用する場合の詳細については、[Bell97]を参照してください。
For further security considerations, the reader is encouraged to read the documents that describe the actual cipher algorithms.
セキュリティに関するさらなる考慮事項については、実際の暗号化アルゴリズムを説明するドキュメントを読むことをお勧めします。
[Adams97] Adams, C, "The CAST-128 Encryption Algorithm", RFC2144, 1997.
[Adams97] Adams、C、「The CAST-128 Encryption Algorithm」、RFC2144、1997。
[Atkinson98]Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[Atkinson98]ケント、S。、およびR.アトキンソン、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[Baldwin96] Baldwin, R. and R. Rivest, "The RC5, RC5-CBC, RC5-CBC-Pad, and RC5-CTS Algorithms", RFC 2040, October 1996.
[Baldwin96] Baldwin、R。およびR. Rivest、「RC5、RC5-CBC、RC5-CBC-Pad、およびRC5-CTSアルゴリズム」、RFC 2040、1996年10月。
[Bell97] S. Bellovin, "Probable Plaintext Cryptanalysis of the IP Security Protocols", Proceedings of the Symposium on Network and Distributed System Security, San Diego, CA, pp. 155-160, February 1997 (also http://www.research.att.com/~smb/probtxt.{ps, pdf}).
[Bell97] S. Bellovin、「IPセキュリティプロトコルの平文暗号解読」、ネットワークおよび分散システムセキュリティに関するシンポジウムの議事録、サンディエゴ、カリフォルニア州、pp。155-160、1997年2月（http：// www。 research.att.com/~smb/probtxt.{ps、pdf}）。
[Bosselaers]A. Bosselaers, "Performance of Pentium implementations",
http://www.esat.kuleuven.ac.be/~bosselae/
[Bradner97] Bradner, S., "Key words for use in RFCs to indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[Bradner97] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、1997年3月。
[Crypto93] J. Daemen, R. Govaerts, J. Vandewalle, "Weak Keys for IDEA", Advances in Cryptology, CRYPTO 93 Proceedings, Springer-Verlag, pp. 224-230.
[Crypto93] J. Daemen、R。Govaerts、J。Vandewalle、「IDEAの弱い鍵」、暗号学の進歩、CRYPTO 93 Proceedings、Springer-Verlag、pp。224-230。
[FIPS-46] US National Bureau of Standards, "Data Encryption Standard", Federal Information Processing Standard (FIPS) Publication 46, January 1977.
[FIPS-46]米国国家標準局、「データ暗号化標準」、連邦情報処理標準（FIPS）出版物46、1977年1月。
[Kent98] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[Kent98] Kent、S。およびR. Atkinson、「IP Encapsulating Security Payload（ESP）」、RFC 2406、1998年11月。
[Lai] X. Lai, "On the Design and Security of Block Ciphers", ETH Series in Information Processing, v. 1, Konstanz: Hartung-Gorre Verlag, 1992.
[ライ] X.ライ、「ブロック暗号の設計とセキュリティについて」、情報処理のETHシリーズ、v。1、コンスタンツ：Hartung-Gorre Verlag、1992年。
[Madson98] Madson, C. and N. Dorswamy, "The ESP DES-CBC Cipher Algorithm With Explicit IV", RFC 2405, November 1998.
[Madson98] Madson、C。およびN. Dorswamy、「明示的なIVを使用したESP DES-CBC暗号アルゴリズム」、RFC 2405、1998年11月。
[MOV] A. Menezes, P. Van Oorschot, S. Vanstone, "Handbook of Applied Cryptography", CRC Press, 1997. ISBN 0-8493- 8523-7
[MOV] A. Menezes、P。Van Oorschot、S。Vanstone、「Handbook of Applied Cryptography」、CRC Press、1997。ISBN0-8493-8523-7
[Schneier] B. Schneier, "Applied Cryptography Second Edition", John Wiley & Sons, New York, NY, 1995. ISBN 0-471-12845-7
[Schneier] B. Schneier、「Applied Cryptography Second Edition」、John Wiley＆Sons、ニューヨーク、ニューヨーク、1995。ISBN0-471-12845-7
[Schneier93]B. Schneier, "Description of a New Variable-Length Key, 64-Bit Block Cipher", from "Fast Software Encryption, Cambridge Security Workshop Proceedings", Springer-Verlag, 1994, pp. 191-204. http://www.counterpane.com/bfsverlag.html
[Schneier93] B。 Schneier、「新しい可変長キーの説明、64ビットブロック暗号」、「Fast Software Encryption、Cambridge Security Workshop Proceedings」、Springer-Verlag、1994、pp。191-204。 http://www.counterpane.com/bfsverlag.html
[Schneier95]B. Schneier, "The Blowfish Encryption Algorithm - One
Year Later", Dr. Dobb's Journal, September 1995,
http://www.counterpane.com/bfdobsoyl.html
[Schneier97]B. Scheier, "Speed Comparisons of Block Ciphers on a Pentium." February 1997, http://www.counterpane.com/speed.html
[Schneier97] B。 Scheier、「ペンティアム上のブロック暗号の速度比較。」 1997年2月、http：//www.counterpane.com/speed.html
[Thayer97] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.
[Thayer97] Thayer、R.、Doraswamy、N。およびR. Glenn、「IP Security Document Roadmap」、RFC 2411、1998年11月。
[Tuchman79] Tuchman, W, "Hellman Presents No Shortcut Solutions to DES", IEEE Spectrum, v. 16 n. 7, July 1979, pp. 40-41.
[Tuchman79] Tuchman、W、 "Hellman Presents No Shortcut Solutions to DES"、IEEE Spectrum、v。16 n。 1979年7月7日、40-41ページ。
This document is a merger of most of the ESP cipher algorithm documents. This merger was done to facilitate greater understanding of the commonality of all of the ESP algorithms and to further the development of these algorithm within ESP.
このドキュメントは、ESP暗号アルゴリズムドキュメントのほとんどを統合したものです。この合併は、すべてのESPアルゴリズムの共通性の理解を促進し、ESP内でのこれらのアルゴリズムの開発を促進するために行われました。
The content of this document is based on suggestions originally from Stephen Kent and subsequent discussions from the IPSec mailing list as well as other IPSec documents.
このドキュメントの内容は、元々はStephen Kentからの提案と、それに続くIPSecメーリングリストおよびその他のIPSecドキュメントからの議論に基づいています。
Special thanks to Carlisle Adams and Paul Van Oorschot both of Entrust Technologies who provided input and review of CAST.
CASTの入力とレビューを提供してくれたEntrust TechnologiesのCarlisle AdamsとPaul Van Oorschotに特に感謝します。
Thanks to all of the editors of the previous ESP 3DES documents; W. Simpson, N. Doraswamy, P. Metzger, and P. Karn.
以前のESP 3DESドキュメントのすべての編集者に感謝します。 W.シンプソン、N。ドラスワミー、P。メッツガー、P。カーン。
Thanks to Brett Howard from TimeStep for his original work of ESP-RC5.
ESP-RC5のオリジナル作品を作成してくれたTimeStepのBrett Howardに感謝します。
Thanks to Markku-Juhani Saarinen, Helger Lipmaa and Bart Preneel for their input on IDEA and other ciphers.
IDEAやその他の暗号に関する情報を提供してくれたMarkku-Juhani Saarinen、Helger Lipmaa、Bart Preneelに感謝します。
Roy Pereira TimeStep Corporation
Roy Pereira TimeStep Corporation
Phone: +1 (613) 599-3610 x 4808
EMail: rpereira@timestep.com
Rob Adams Cisco Systems Inc.
Rob Adams Cisco Systems Inc.
Phone: +1 (408) 457-5397
EMail: adams@cisco.com
Contributors:
貢献者：
Robert W. Baldwin RSA Data Security, Inc.
Robert W. Baldwin RSA Data Security、Inc.
Phone: +1 (415) 595-8782
EMail: baldwin@rsa.com or baldwin@lcs.mit.edu
Greg Carter Entrust Technologies
グレッグ・カーター・エントラスト・テクノロジーズ
Phone: +1 (613) 763-1358
EMail: carterg@entrust.com
Rodney Thayer Sable Technology Corporation
Rodney Thayer Sable Technology Corporation
Phone: +1 (617) 332-7292 EMail: rodney@sabletech.com The IPSec working group can be contacted via the IPSec working group's mailing list (ipsec@tis.com) or through its chairs:
電話：+1（617）332-7292メール：rodney@sabletech.com IPSecワーキンググループには、IPSecワーキンググループのメーリングリスト（ipsec@tis.com）またはその議長を通じて連絡できます。
Robert Moskowitz International Computer Security Association
Robert Moskowitz International Computer Security Association
EMail: rgm@icsa.net
Theodore Y. Ts'o Massachusetts Institute of Technology
セオドアY. Ts'oマサチューセッツ工科大学
EMail: tytso@MIT.EDU
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができますただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。