[要約] 要約：RFC 2405は、ESP（Encapsulating Security Payload）のDES-CBC暗号アルゴリズムについて説明しており、明示的なIV（Initialization Vector）を使用する方法を提供しています。目的：このRFCの目的は、ESPのセキュリティ機能を向上させるために、DES-CBC暗号アルゴリズムに明示的なIVを導入することです。
Network Working Group C. Madson
Request for Comments: 2405 Cisco Systems, Inc.
Category: Standards Track N. Doraswamy
Bay Networks, Inc.
November 1998
The ESP DES-CBC Cipher Algorithm With Explicit IV
明示的なIVを使用したESP DES-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 the use of the DES Cipher algorithm in Cipher Block Chaining Mode, with an explicit IV, as a confidentiality mechanism within the context of the IPSec Encapsulating Security Payload (ESP).
このドキュメントでは、IPSecカプセル化セキュリティペイロード（ESP）のコンテキスト内の機密性メカニズムとして、明示的なIVを使用した暗号ブロックチェーンモードでのDES暗号アルゴリズムの使用について説明します。
This document describes the use of the DES Cipher algorithm in Cipher Block Chaining Mode as a confidentiality mechanism within the context of the Encapsulating Security Payload.
このドキュメントでは、カプセル化セキュリティペイロードのコンテキスト内の機密性メカニズムとして、暗号ブロックチェーンモードでのDES暗号アルゴリズムの使用について説明します。
DES is a symmetric block cipher algorithm. The algorithm is described in [FIPS-46-2][FIPS-74][FIPS-81]. [Schneier96] provides a general description of Cipher Block Chaining Mode, a mode which is applicable to several encryption algorithms.
DESは対称ブロック暗号アルゴリズムです。アルゴリズムは、[FIPS-46-2] [FIPS-74] [FIPS-81]で説明されています。 [Schneier96]は、いくつかの暗号化アルゴリズムに適用可能なモードであるCipher Block Chaining Modeの一般的な説明を提供します。
As specified in this memo, DES-CBC is not an authentication mechanism. [Although DES-MAC, described in [Schneier96] amongst other places, does provide authentication, DES-MAC is not discussed here.]
このメモで指定されているように、DES-CBCは認証メカニズムではありません。 [DES-MACは[Schneier96]で説明されていますが、認証を提供しますが、DES-MACについてはここでは説明しません。]
For further information on how the various pieces of ESP fit together to provide security services, refer to [ESP] and [road].
ESPのさまざまな部分を組み合わせてセキュリティサービスを提供する方法の詳細については、[ESP]および[road]を参照してください。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC-2119]で説明されているように解釈されます。
DES-CBC is a symmetric secret-key block algorithm. It has a block size of 64 bits.
DES-CBCは、対称秘密鍵ブロックアルゴリズムです。ブロックサイズは64ビットです。
[FIPS-46-2][FIPS-74] and [FIPS-81] describe the DES algorithm, while [Schneier96] provides a good description of CBC mode.
[FIPS-46-2] [FIPS-74]と[FIPS-81]はDESアルゴリズムについて説明しており、[Schneier96]はCBCモードについて適切に説明しています。
Phil Karn has tuned DES-CBC software to achieve 10.45 Mbps with a 90 MHz Pentium, scaling to 15.9 Mbps with a 133 MHz Pentium. Other DES speed estimates may be found in [Schneier96].
Phil Karnは、DES-CBCソフトウェアを調整して、90 MHz Pentiumで10.45 Mbpsを実現し、133 MHz Pentiumで15.9 Mbpsにスケーリングしました。他のDES速度の見積もりは、[Schneier96]にあります。
DES-CBC requires an explicit Initialization Vector (IV) of 8 octets (64 bits). This IV immediately precedes the protected (encrypted) payload. The IV MUST be a random value.
DES-CBCには、8オクテット（64ビット）の明示的な初期化ベクトル（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を含めることで、一部のデータグラムがドロップされたり、転送中にデータグラムが並べ替えられたりした場合でも、受信した各データグラムの復号化を確実に実行できます。
Implementation note:
実装上の注意：
Common practice is to use random data for the first IV and the last 8 octets of encrypted data from an encryption process as the IV for the next encryption process; this logically extends the CBC across the packets. It also has the advantage of limiting the leakage of information from the random number genrator. No matter which mechnism is used, the receiver MUST NOT assume any meaning for this value, other than that it is an IV.
一般的な方法は、次の暗号化プロセスのIVとして、暗号化プロセスからの暗号化データの最初のIVおよび最後の8オクテットにランダムデータを使用することです。これにより、パケット全体でCBCが論理的に拡張されます。また、乱数生成器からの情報の漏洩を制限するという利点もあります。使用するメカニズムに関係なく、レシーバーはこの値がIVであること以外は、この値の意味を想定してはなりません（MUST NOT）。
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にカウンターまたは他の低ハミング距離ソースを使用してはなりません。
The payload field, as defined in [ESP], is broken down according to the following diagram:
[ESP]で定義されているペイロードフィールドは、次の図に従って分解されます。
+---------------+---------------+---------------+---------------+
| |
+ Initialization Vector (IV) +
| |
+---------------+---------------+---------------+---------------+
| |
~ 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 DES-CBC algorithm described in this document MUST use a block size of 8 octets (64 bits).
このドキュメントで説明されているDES-CBCアルゴリズムでは、8オクテット（64ビット）のブロックサイズを使用する必要があります。
When padding is required, it MUST be done according to the conventions specified in [ESP].
パディングが必要な場合は、[ESP]で指定された規則に従ってパディングする必要があります。
DES-CBC is a symmetric secret key algorithm. The key size is 64-bits. [It is commonly known as a 56-bit key as the key has 56 significant bits; the least significant bit in every byte is the parity bit.]
DES-CBCは対称秘密鍵アルゴリズムです。キーのサイズは64ビットです。 [キーには56ビットの有効ビットがあるため、一般に56ビットキーとして知られています。各バイトの最下位ビットはパリティビットです。]
[arch] describes the general mechanism to derive keying material for the ESP transform. The derivation of the key from some amount of keying material does not differ between the manually- and automatically-keyed security associations.
[arch]は、ESP変換のキー情報を導出する一般的なメカニズムを説明しています。ある量のキー生成情報からのキーの派生は、手動でキーを入力したセキュリティアソシエーションと自動でキーを入力したセキュリティアソシエーションの間で違いはありません。
This mechanism MUST derive a 64-bit key value for use by this cipher. The mechanism will derive raw key values, the derivation process itself is not responsible for handling parity or weak key checks.
このメカニズムは、この暗号で使用する64ビットのキー値を導出する必要があります。メカニズムは生のキー値を導出します。派生プロセス自体は、パリティまたは弱いキーチェックの処理に責任がありません。
Weak key checks SHOULD be performed. If such a key is found, the key SHOULD be rejected and a new SA requested.
弱い鍵のチェックを実行する必要があります。そのような鍵が見つかった場合、その鍵は拒否されるべきであり、新しいSAが要求されます。
Implementation note:
実装上の注意：
If an implementation chooses to do weak key checking, it should recognize that the known weak keys [FIPS74] have been adjusted for parity. Otherwise the handling of parity is a local issue.
実装が弱いキーチェックを行うことを選択した場合、既知の弱いキー[FIPS74]がパリティ用に調整されていることを認識する必要があります。それ以外の場合、パリティの処理はローカルの問題です。
A strong pseudo-random function MUST be used to generate the required key. For a discussion on this topic, reference [RFC1750].
必要なキーを生成するには、強力な疑似ランダム関数を使用する必要があります。このトピックに関する議論については、[RFC1750]を参照してください。
DES has 16 known weak keys, including so-called semi-weak keys. The list of weak keys can be found in [FIPS74].
DESには、いわゆる半弱い鍵を含む、16個の既知の弱い鍵があります。弱いキーのリストは[FIPS74]にあります。
[Blaze96] discusses the costs and key recovery time for brute force attacks. It presents various combinations of total cost/time to recover a key/cost per key recovered for 40-bit and 56-bit DES keys, based on late 1995 estimates.
[Blaze96]は、ブルートフォース攻撃のコストとキー復旧時間について説明しています。 1995年後半の見積もりに基づいて、40ビットおよび56ビットのDES鍵で回復された鍵を回復するための総コスト/時間/鍵ごとのコストのさまざまな組み合わせを示しています。
While a brute force search of a 56-bit DES keyspace can be considered infeasable for the so-called casual hacker, who is simply using spare CPU cycles or other low-cost resources, it is within reach of someone willing to spend a bit more money.
56ビットDESキースペースのブルートフォース検索は、単に予備のCPUサイクルや他の低コストのリソースを使用している、いわゆるカジュアルなハッカーにとって実行不可能であると考えることができますが、もう少し費やすことをいとわない誰かの手の届くところにありますお金。
For example, for a cost of $300,000, a 56-bit DES key can be recovered in an average of 19 days using off-the-shelf technology and in only 3 hours using a custom developed chip.
たとえば、30万ドルのコストで、56ビットのDES鍵は、既製のテクノロジーを使用して平均19日、カスタム開発されたチップを使用してわずか3時間で回復できます。
It should be noted that there are other attacks which can recover the key faster, that brute force attacks are considered the "worst case", although the easiest to implement.
キーをより早く回復できる他の攻撃があること、ブルートフォース攻撃は「最悪のケース」と見なされていることに注意してください。
[Wiener94] also discusses a $1M machine which can break a DES key in 3.5 hours (1993 estimates), using a known-plaintext attack. As discussed in the Security Considerations section, a known plaintext attack is reasonably likely.
[Wiener94]は、既知の平文攻撃を使用して、DESキーを3.5時間（1993年の見積もり）で破ることができる100万ドルのマシンについても説明しています。 「セキュリティに関する考慮事項」セクションで説明したように、既知のプレーンテキスト攻撃はかなり可能性が高いです。
It should also be noted that over time, the total and average search costs as well as the average key recovery time will continue to drop.
また、時間の経過とともに、検索コストの合計と平均、およびキーの平均復旧時間は減少し続けることにも注意してください。
While the above does not provide specific recommendations for key lifetime, it does reinforce the point that for a given application the desired key lifetime is dependent upon the perceived threat (an educated guess as to the amount of resources available to the attacker) relative to the worth of the data to be protected.
上記はキーの有効期間に関する特定の推奨事項を提供していませんが、特定のアプリケーションの場合、望ましいキーの有効期間は、知覚された脅威（攻撃者が利用できるリソースの量に関する知識に基づく推測）に依存するという点を強調しています。保護するデータの価値。
While there are no recommendations for volume-based lifetimes made here, it shoud be noted that given sufficient volume there is an increased probabilty that known plaintext can be accumulated.
ここではボリュームベースのライフタイムの推奨事項はありませんが、十分なボリュームがある場合、既知の平文が蓄積される可能性が高くなることに注意してください。
As of this writing, there are no known issues which preclude the use of the DES-CBC algorithm with any specific authentication algorithm.
これを書いている時点では、DES-CBCアルゴリズムと特定の認証アルゴリズムの使用を妨げる既知の問題はありません。
[Much of this section was originally written by William Allen Simpson and Perry Metzger.]
[このセクションの多くは、もともとウィリアムアレンシンプソンとペリーメッツガーによって書かれました。]
Users need to understand that the quality of the security provided by this specification depends completely on the strength of the DES algorithm, the correctness of that algorithm's implementation, the security of the Security Association management mechanism and its implementation, the strength of the key [CN94], and upon the correctness of the implementations in all of the participating nodes.
ユーザーは、この仕様によって提供されるセキュリティの品質が、DESアルゴリズムの強度、そのアルゴリズムの実装の正確さ、セキュリティアソシエーション管理メカニズムとその実装のセキュリティ、キーの強度に完全に依存することを理解する必要があります[CN94 ]、および参加しているすべてのノードでの実装の正確さについて。
[Bell95] and [Bell96] describe a cut and paste splicing attack which applies to all Cipher Block Chaining algorithms. This attack can be addressed with the use of an authentication mechanism.
[Bell95]と[Bell96]は、すべての暗号化ブロックチェーンアルゴリズムに適用されるカットアンドペーストのスプライシング攻撃について説明しています。この攻撃は、認証メカニズムを使用して対処できます。
The use of the cipher mechanism without any corresponding authentication mechanism is strongly discouraged. This cipher can be used in an ESP transform that also includes authentication; it can also be used in an ESP transform that doesn't include authentication provided there is an companion AH header. Refer to [ESP], [AH], [arch], and [road] for more details.
対応する認証メカニズムなしで暗号化メカニズムを使用することは強くお勧めしません。この暗号は、認証も含むESPトランスフォームで使用できます。また、コンパニオンAHヘッダーがある場合は、認証を含まないESPトランスフォームでも使用できます。詳細については、[ESP]、[AH]、[arch]、および[road]を参照してください。
When the default ESP padding is used, the padding bytes have a predictable value. They provide a small measure of tamper detection on their own block and the previous block in CBC mode. This makes it somewhat harder to perform splicing attacks, and avoids a possible covert channel. This small amount of known plaintext does not create any problems for modern ciphers.
デフォルトのESPパディングが使用される場合、パディングバイトには予測可能な値があります。それらは自身のブロックとCBCモードの前のブロックで改ざん検出の小さな測定を提供します。これにより、スプライシング攻撃の実行がやや難しくなり、潜在的な秘密チャネルが回避されます。この少量の既知の平文は、現代の暗号に問題を引き起こしません。
At the time of writing of this document, [BS93] demonstrated a differential cryptanalysis based chosen-plaintext attack requiring 2^47 plaintext-ciphertext pairs, where the size of a pair is the size of a DES block (64 bits). [Matsui94] demonstrated a linear cryptanalysis based known-plaintext attack requiring only 2^43 plaintext-ciphertext pairs. Although these attacks are not considered practical, they must be taken into account.
この文書の執筆時点で、[BS93]は、2 ^ 47の平文と暗号文のペアを必要とする差分暗号解読ベースの選択平文攻撃を実証しました。ペアのサイズはDESブロックのサイズ（64ビット）です。 [Matsui94]は、2 ^ 43の平文と暗号文のペアのみを必要とする線形暗号解析に基づく既知の平文攻撃を示しました。これらの攻撃は実用的とは見なされていませんが、考慮に入れる必要があります。
More disturbingly, [Wiener94] has shown the design of a DES cracking machine costing $1 Million that can crack one key every 3.5 hours. This is an extremely practical attack.
さらに厄介なことに、[Wiener94]は、3.5時間ごとに1つの鍵を解読できる100万ドルのDES解読マシンの設計を示しました。これは非常に実用的な攻撃です。
One or two blocks of known plaintext suffice to recover a DES key. Because IP datagrams typically begin with a block of known and/or guessable header text, frequent key changes will not protect against this attack.
DES鍵を回復するには、既知の平文の1つまたは2つのブロックで十分です。 IPデータグラムは通常、既知または推測可能なヘッダーテキストのブロックで始まるため、頻繁にキーを変更しても、この攻撃を防ぐことはできません。
It is suggested that DES is not a good encryption algorithm for the protection of even moderate value information in the face of such equipment. Triple DES is probably a better choice for such purposes.
DESは、このような機器に直面して中程度の価値の情報を保護するための優れた暗号化アルゴリズムではないことをお勧めします。トリプルDESは、おそらくそのような目的に適しています。
However, despite these potential risks, the level of privacy provided by use of ESP DES-CBC in the Internet environment is far greater than sending the datagram as cleartext.
ただし、これらの潜在的なリスクにもかかわらず、インターネット環境でのESP DES-CBCの使用によって提供されるプライバシーのレベルは、データグラムをクリアテキストとして送信するよりもはるかに優れています。
The case for using random values for IVs has been refined with the following summary provided by Steve Bellovin. Refer to [Bell97] for further information.
IVにランダムな値を使用するケースは、Steve Bellovinによって提供された次の要約で洗練されています。詳細については、[Bell97]を参照してください。
"The problem arises if you use a counter as an IV, or some other source with a low Hamming distance between successive IVs, for encryption in CBC mode. In CBC mode, the "effective plaintext" for an encryption is the XOR of the actual plaintext and the ciphertext of the preceeding block. Normally, that's a random value, which means that the effective plaintext is quite random. That's good, because many blocks of actual plaintext don't change very much from packet to packet, either.
「CBCモードでの暗号化のためにカウンターをIVとして使用する場合、または連続するIV間のハミング距離が短い他のソースを使用する場合に問題が発生します。CBCモードでは、暗号化の「有効な平文」は実際のXORです前のブロックの平文と暗号文。通常、これはランダムな値であり、これは有効な平文が非常にランダムであることを意味します。実際の平文の多くのブロックもパケットごとにあまり変化しないため、これは良いことです。
For the first block of plaintext, though, the IV takes the place of the previous block of ciphertext. If the IV doesn't differ much from the previous IV, and the actual plaintext block doesn't differ much from the previous packet's, then the effective plaintext won't differ much, either. This means that you have pairs of ciphertext blocks combined with plaintext blocks that differ in just a few bit positions. This can be a wedge for assorted cryptanalytic attacks."
ただし、平文の最初のブロックの場合、IVは前の暗号文のブロックの代わりになります。 IVが前のIVとあまり変わらず、実際の平文ブロックも前のパケットとそれほど変わらない場合、有効な平文もあまり変わらないでしょう。これは、ほんの数ビットの位置が異なる平文ブロックと組み合わされた暗号文ブロックのペアがあることを意味します。これは、さまざまな暗号解読攻撃のくさびになる可能性があります。」
The discussion on IVs has been updated to require that an implementation not use a low-Hamming distance source for IVs.
IVに関する説明が更新され、IVに低ハミング距離ソースを使用しない実装が必要になりました。
[Bell95] Bellovin, S., "An Issue With DES-CBC When Used Without Strong Integrity", Presentation at the 32nd Internet Engineering Task Force, Danvers Massachusetts, April 1995.
[Bell95] Bellovin、S.、「強力な整合性なしで使用した場合のDES-CBCの問題」、第32回インターネットエンジニアリングタスクフォース、ダンバーズマサチューセッツ、1995年4月でのプレゼンテーション。
[Bell96] Bellovin, S., "Problem Areas for the IP Security Protocols", Proceedings of the Sixth Usenix Security Symposium, July 1996.
[Bell96] Bellovin、S。、「IPセキュリティプロトコルの問題領域」、第6回Usenixセキュリティシンポジウムの議事録、1996年7月。
[Bell97] Bellovin, S., "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/papers/probtxt.{ps, pdf}).
[Bell97] Bellovin、S.、 "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 / papers / probtxt。{ps、pdf}）。
[BS93] Biham, E., and A. Shamir, "Differential Cryptanalysis of the Data Encryption Standard", Berlin: Springer-Verlag, 1993.
[BS93] Biham、E.、and A. Shamir、 "Differential Cryptanalysis of the Data Encryption Standard"、Berlin：Springer-Verlag、1993。
[Blaze96] Blaze, M., Diffie, W., Rivest, R., Schneier, B., Shimomura, T., Thompson, E., and M. Wiener, "Minimal Key Lengths for Symmetric Ciphers to Provide Adequate Commercial Security", currently available at http://www.bsa.org/policy/encryption/cryptographers.html.
[Blaze96] Blaze、M.、Diffie、W.、Rivest、R.、Schneier、B.、Shimuramura、T.、Thompson、E。、およびM. Wiener、「適切な商用セキュリティを提供する対称暗号の最小キー長"、現在http://www.bsa.org/policy/encryption/cryptographers.htmlで入手できます。
[CN94] Carroll, J.M., and S. Nudiati, "On Weak Keys and Weak Data: Foiling the Two Nemeses", Cryptologia, Vol. 18 No. 23 pp. 253-280, July 1994.
[CN94] Carroll、J.M。、およびS. Nudiati、「弱い鍵と弱いデータ：2つの宿敵のフォイル」、Cryptologia、Vol。 18 No. 23 pp。253-280、1994年7月。
[FIPS-46-2] US National Bureau of Standards, "Data Encryption Standard", Federal Information Processing Standard (FIPS) Publication 46-2, December 1993, http://www.itl.nist.gov/div897/pubs/fip46-2.htm (supercedes FIPS-46-1).
[FIPS-46-2]米国国家標準局、「データ暗号化標準」、連邦情報処理標準（FIPS）出版物46-2、1993年12月、http：//www.itl.nist.gov/div897/pubs/ fip46-2.htm（FIPS-46-1に優先）。
[FIPS-74] US National Bureau of Standards, "Guidelines for Implementing and Using the Data Encryption Standard", Federal Information Processing Standard (FIPS) Publication 74, April 1981, http://www.itl.nist.gov/div897/pubs/fip74.htm.
[FIPS-74]米国国立標準局、「データ暗号化標準の実装および使用に関するガイドライン」、連邦情報処理標準（FIPS）出版物74、1981年4月、http：//www.itl.nist.gov/div897/ pubs / fip74.htm。
[FIPS-81] US National Bureau of Standards, "DES Modes of Operation", Federal Information Processing Standard (FIPS) Publication 81, December 1980, http://www.itl.nist.gov/div897/pubs/fip81.htm.
[FIPS-81]米国国家標準局、「DES操作モード」、連邦情報処理標準（FIPS）発行81、1980年12月、http：//www.itl.nist.gov/div897/pubs/fip81.htm 。
[Matsui94] Matsui, M., "Linear Cryptanalysis method for DES Cipher", Advances in Cryptology -- Eurocrypt '93 Proceedings, Berlin: Springer-Verlag, 1994.
[Matsui94] Matsui、M.、 "LINE Cryptanalysis method for DES Cipher"、Advances in Cryptology-Eurocrypt '93 Proceedings、Berlin：Springer-Verlag、1994。
[RFC-1750] Eastlake, D., Crocker, S., and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[RFC-1750] Eastlake、D.、Crocker、S。、およびJ. Schiller、「Randomness Recommendations for Security」、RFC 1750、1994年12月。
[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月。
[Schneier96] Schneier, B., "Applied Cryptography Second Edition", John Wiley & Sons, New York, NY, 1996. ISBN 0-471- 12845-7.
[Schneier96] Schneier、B。、「Applied Cryptography Second Edition」、John Wiley＆Sons、ニューヨーク、ニューヨーク、1996。ISBN0-471-12845-7。
[Wiener94] Wiener, M.J., "Efficient DES Key Search", School of Computer Science, Carleton University, Ottawa, Canada, TR-244, May 1994. Presented at the Rump Session of Crypto '93. [Reprinted in "Practical Cryptography for Data Internetworks", W.Stallings, editor, IEEE Computer Society Press, pp.31-79 (1996). Currently available at ftp://ripem.msu.edu/pub/crypt/docs/des-key-search.ps.]
[Wiener94] Wiener、M.J。、「Efficient DES Key Search」、コンピュータサイエンススクール、カールトン大学、オタワ、カナダ、TR-244、1994年5月。Crypto'93のランプセッションで発表。 [「データインターネットワークのための実用的な暗号」、W.Stallings、編集者、IEEE Computer Society Press、31-79頁（1996）に転載。現在、ftp：//ripem.msu.edu/pub/crypt/docs/des-key-search.psで入手できます。]
[ESP] Kent, S., and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[ESP] Kent、S。、およびR. Atkinson、「IP Encapsulating Security Payload（ESP）」、RFC 2406、1998年11月。
[AH] Kent, S., and R. Atkinson, "IP Authentication Header (AH)", RFC 2402, November 1998.
[AH]ケント、S。、およびR.アトキンソン、「IP認証ヘッダー（AH）」、RFC 2402、1998年11月。
[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月。
[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月。
Much of the information provided here originated with various ESP-DES documents authored by Perry Metzger and William Allen Simpson, especially the Security Considerations section.
ここで提供される情報の多くは、Perry MetzgerとWilliam Allen Simpsonによって作成されたさまざまなESP-DESドキュメント、特に「セキュリティに関する考慮事項」セクションに基づいています。
This document is also derived in part from previous works by Jim Hughes, those people that worked with Jim on the combined DES-CBC+HMAC-MD5 ESP transforms, the ANX bakeoff participants, and the members of the IPsec working group.
このドキュメントは、ジムヒューズ、ジムと一緒にDES-CBC + HMAC-MD5 ESP変換を組み合わせて作業した人々、ANXベークオフ参加者、およびIPsecワーキンググループのメンバーによる以前の作品からも一部派生しています。
Thanks to Rob Glenn for assisting with the nroff formatting.
nroffのフォーマットを支援してくれたRob Glennに感謝します。
The IPSec working group can be contacted via the IPSec working group's mailing list (ipsec@tis.com) or through its chairs:
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
Cheryl Madson Cisco Systems, Inc.
シェリルマドソンCisco Systems、Inc.
EMail: cmadson@cisco.com
Naganand Doraswamy Bay Networks, Inc.
Naganand Doraswamy Bay Networks、Inc.
EMail: naganand@baynetworks.com
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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。