RFC1851 日本語訳

Network Working Group                                            P. Karn
Request for Comments: 1851                                      Qualcomm
Category: Experimental                                        P. Metzger
                                                                Piermont
                                                              W. Simpson
                                                              Daydreamer
                                                          September 1995

Karnがコメントのために要求するワーキンググループP.をネットワークでつないでください: 1851年のクアルコムカテゴリ: 実験的なP.のメッツガーピアモントW.シンプソン空想家1995年9月

                      The ESP Triple DES Transform

超能力の三重のDESは変形します。

Status of this Memo

このMemoの状態

   This document defines an Experimental Protocol for the Internet
   community.  This does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

このドキュメントはインターネットコミュニティのためにExperimentalプロトコルを定義します。 これはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。

Abstract

要約

   This document describes the Triple DES-CBC security transform for the
   IP Encapsulating Security Payload (ESP).

このドキュメントはセキュリティがIP Encapsulating Security有効搭載量(超能力)のために変えるTriple DES-CBCについて説明します。

Table of Contents

目次

     1.     Introduction ..........................................    2
        1.1       Keys ............................................    2
        1.2       Initialization Vector ...........................    2
        1.3       Data Size .......................................    3
        1.4       Performance .....................................    3

1. 序論… 2 1.1個のキー… 2 1.2初期設定ベクトル… 2 1.3 データサイズ… 3 1.4パフォーマンス… 3

     2.     Payload Format ........................................    4

2. 有効搭載量形式… 4

     3.     Algorithm .............................................    6
        3.1       Encryption ......................................    6
        3.2       Decryption ......................................    7

3. アルゴリズム… 6 3.1暗号化… 6 3.2復号化… 7

     SECURITY CONSIDERATIONS ......................................    7
     ACKNOWLEDGEMENTS .............................................    8
     REFERENCES ...................................................    9
     AUTHOR'S ADDRESS .............................................   11

セキュリティ問題… 7つの承認… 8つの参照箇所… 9作者のアドレス… 11

Karn, et al                   Experimental                      [Page 1]

RFC 1851                        ESP 3DES                  September 1995

Karn、他Experimental[1ページ]RFC1851の超能力3DES1995年9月

1.  Introduction

1. 序論

   The Encapsulating Security Payload (ESP) [RFC-1827] provides
   confidentiality for IP datagrams by encrypting the payload data to be
   protected.  This specification describes the ESP use of a variant of
   of the Cipher Block Chaining (CBC) mode of the US Data Encryption
   Standard (DES) algorithm [FIPS-46, FIPS-46-1, FIPS-74, FIPS-81].
   This variant, known as Triple DES (3DES), processes each block of the
   plaintext three times, each time with a different key [Tuchman79].

Encapsulating Security有効搭載量(超能力)[RFC-1827]は、ペイロードデータを暗号化するのによるIPデータグラムが保護されるために秘密性を提供します。 この仕様は米国データ暗号化規格(DES)アルゴリズム[FIPS-46、FIPS-46-1、FIPS-74、FIPS-81]のCipher Block Chaining(CBC)モードについて異形の超能力使用について説明します。 Triple DES(3DES)として知られているこの異形は3回(異なったキー[Tuchman79]がある各回)平文の各ブロックを処理します。

   This document assumes that the reader is familiar with the related
   document "Security Architecture for the Internet Protocol" [RFC-
   1825], which defines the overall security plan for IP, and provides
   important background for this specification.

このドキュメントは、読者がIPのために総合的な警備計画を定義する「インターネットプロトコルのためのセキュリティー体系」[RFC1825]という関連するドキュメントに詳しいと仮定して、この仕様に重要なバックグラウンドを前提とします。

1.1.  Keys

1.1. キー

   The secret 3DES key shared between the communicating parties is
   effectively 168-bits long.  This key consists of three independent
   56-bit quantities used by the DES algorithm.  Each of the three 56-
   bit subkeys is stored as a 64-bit (eight octet) quantity, with the
   least significant bit of each octet used as a parity bit.

長い間、事実上、交信パーティーの間で共有された秘密の3DESキーは168ビットです。 このキーはDESアルゴリズムで使用される3つの独立している56ビットの量から成ります。 それぞれの3個の56の噛み付いているサブキーが64ビット(8八重奏)の量として保存されます、それぞれの八重奏の最下位ビットがパリティビットとして使用されている状態で。

1.2.  Initialization Vector

1.2. 初期設定ベクトル

   This mode of 3DES requires an Initialization Vector (IV) that is
   eight octets in length.

3DESのこのモードは長さにおいて8つの八重奏である初期設定Vector(IV)を必要とします。

   Each datagram contains its own IV.  Including the IV in each datagram
   ensures that decryption of each received datagram can be performed,
   even when other datagrams are dropped, or datagrams are re-ordered in
   transit.

各データグラムはそれ自身のIVを含んでいます。 各データグラムにIVを含んでいるのは、それぞれの容認されたデータグラムの復号化を実行できるのを確実にします、他のデータグラムを下げるか、またはトランジットでデータグラムを再注文さえするとき。

   The method for selection of IV values is implementation dependent.

IV値の品揃えのためのメソッドは実装に依存しています。

   Notes:
      A common acceptable technique is simply a counter, beginning with
      a randomly chosen value.  While this provides an easy method for
      preventing repetition, and is sufficiently robust for practical
      use, cryptanalysis may use the rare serendipitous occurrence when
      a corresponding bit position in the first DES block increments in
      exactly the same fashion.

注意: 手当たりしだいに選ばれた値で始まって、一般的な許容できるテクニックは単にカウンタです。 まさに同じファッションによる最初のDESブロック増分における対応するビット位置であるときに、これが反復を防ぐのに簡易法を提供して、実用に、十分強健である間、暗号文解読術はまれな堀り出し上手の発生を使用するかもしれません。

Karn, et al                   Experimental                      [Page 2]

RFC 1851                        ESP 3DES                  September 1995

Karn、他Experimental[2ページ]RFC1851の超能力3DES1995年9月

      Other implementations exhibit unpredictability, usually through a
      pseudo-random number generator.  Care should be taken that the
      periodicity of the number generator is long enough to prevent
      repetition during the lifetime of the session key.

他の実装は通常疑似乱数生成器を通して予測不可能性を示します。 注意するべきです。数のジェネレータの周期性はセッションキーの生涯反復を防ぐことができるくらい長いです。

1.3.  Data Size

1.3. データサイズ

   The 3DES algorithm operates on blocks of eight octets.  This often
   requires padding after the end of the unencrypted payload data.

3DESアルゴリズムは8つの八重奏のブロックを作動させます。 これは、しばしば非暗号化されたペイロードデータの終わり以降そっと歩くのを必要とします。

   Both input and output result in the same number of octets, which
   facilitates in-place encryption and decryption.

両方が同じ数の八重奏における結果を入出力します。(八重奏は適所で暗号化と復号化を容易にします)。

   On receipt, if the length of the data to be decrypted is not an
   integral multiple of eight octets, then an error is indicated, as
   described in [RFC-1825].

領収書の上では、誤りは解読されるデータの長さが8つの八重奏の不可欠の倍数でないなら示されます、[RFC-1825]で説明されるように。

1.4.  Performance

1.4. パフォーマンス

   Three DES-CBC implementations may be pipelined in series to provide
   parallel computation.  At the time of writing, at least one hardware
   implementation can encrypt or decrypt at about 1 Gbps [Schneier94, p.
   231].

3つのDES-CBC実装が、並列計算を提供するために連続的にpipelinedされるかもしれません。 これを書いている時点で、少なくとも1つのハードウェア実装が、Gbpsを暗号化するか、または1時頃に解読することができます。[Schneier94、p。 231].

Karn, et al                   Experimental                      [Page 3]

RFC 1851                        ESP 3DES                  September 1995

Karn、他Experimental[3ページ]RFC1851の超能力3DES1995年9月

2.  Payload Format

2. 有効搭載量形式

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Security Parameters Index (SPI)                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                   Initialization Vector (IV)                  ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                          Payload Data                         ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             ... Padding           |  Pad Length   | Payload Type  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | セキュリティパラメタインデックス(SPI)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ 初期設定ベクトル(IV)~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ 有効搭載量データ~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 詰め物| パッドの長さ| 有効搭載量タイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Security Parameters Index (SPI)

セキュリティパラメタインデックス(SPI)

      A 32-bit value identifying the Security Parameters for this
      datagram.  The value MUST NOT be zero.

このデータグラムのためにSecurity Parametersを特定する32ビットの値。 値はゼロであるはずがありません。

   Initialization Vector (IV)

初期設定ベクトル(IV)

      The size of this field is variable, although it is constant for
      all 3DES datagrams of the same SPI and IP Destination.  Octets are
      sent in network order (most significant octet first) [RFC-1700].

この分野のサイズは可変です、同じSPIとIP Destinationのすべての3DESデータグラムに、それは一定ですが。 ネットワークオーダーで八重奏を送る、(最も重要な八重奏、1番目) [RFC-1700。]

      The size MUST be a multiple of 32-bits.  Sizes of 32 and 64 bits
      are required to be supported.  The use of other sizes is beyond
      the scope of this specification.  The size is expected to be
      indicated by the key management mechanism.

サイズは32ビットの倍数であるに違いありません。 32と64ビットのサイズが、サポートされるのに必要です。 他のサイズの使用はこの仕様の範囲を超えています。 かぎ管理メカニズムによってサイズが示されると予想されます。

      When the size is 32-bits, a 64-bit IV is formed from the 32-bit
      value followed by (concatenated with) the bit-wise complement of
      the 32-bit value.  This field size is most common, as it aligns
      the Payload Data for both 32-bit and 64-bit processing.

サイズが32ビットであるときに、64ビットのIVが続かれる32ビットの値から形成される、(連結される、)、32ビットの価値のビット的な補数。 ともに32ビットの、そして、64ビットの処理のために有効搭載量Dataを並べるとき、この分野サイズは最も一般的です。

      All conformant implementations MUST also correctly process a 64-
      bit field size.  This provides strict compatibility with existing
      hardware implementations.

また、すべてのconformant実装が正しく64の噛み付いている分野サイズを処理しなければなりません。 これは既存のハードウェア実装を厳しい互換性に提供します。

         It is the intent that the value not repeat during the lifetime
         of the encryption session key.  Even when a full 64-bit IV is
         used, the session key SHOULD be changed at least as frequently
         as 2**32 datagrams.

それは値が暗号化セッションキーの生涯繰り返さない意図です。 完全な64ビットでさえあるときに、IVは使用されています、セッションの主要なSHOULD。2**32データグラムと少なくとも同じくらい頻繁に変えます。

Karn, et al                   Experimental                      [Page 4]

RFC 1851                        ESP 3DES                  September 1995

Karn、他Experimental[4ページ]RFC1851の超能力3DES1995年9月

   Payload Data

有効搭載量データ

      The size of this field is variable.

この分野のサイズは可変です。

      Prior to encryption and after decryption, this field begins with
      the IP Protocol/Payload header specified in the Payload Type
      field.  Note that in the case of IP-in-IP encapsulation (Payload
      Type 4), this will be another IP header.

暗号化の前と復号化の後に、IPプロトコル/有効搭載量ヘッダーが有効搭載量Type分野で指定されている状態で、この分野は始まります。 IPにおけるIPカプセル化(有効搭載量Type4)の場合では、これが別のIPヘッダーになることに注意してください。

   Padding

詰め物

      The size of this field is variable.

この分野のサイズは可変です。

      Prior to encryption, it is filled with unspecified implementation
      dependent (preferably random) values, to align the Pad Length and
      Payload Type fields at an eight octet boundary.

暗号化の前に、それは、8八重奏境界でPad Lengthと有効搭載量Type分野を並べるために不特定の実装に依存する(望ましくは無作為の)値で満たされます。

      After decryption, it MUST be ignored.

復号化の後に、それを無視しなければなりません。

   Pad Length

パッドの長さ

      This field indicates the size of the Padding field.  It does not
      include the Pad Length and Payload Type fields.  The value
      typically ranges from 0 to 7, but may be up to 255 to permit
      hiding of the actual data length.

この分野はPadding分野のサイズを示します。 それはPad Lengthと有効搭載量Type分野を含んでいません。 値は、通常に0〜7まで及びますが、最大実際のデータの長さの許可証隠れることへの255であるかもしれません。

      This field is opaque.  That is, the value is set prior to
      encryption, and is examined only after decryption.

この分野は不透明です。 すなわち、値は、暗号化の前に設定されて、復号化の後にだけ調べられます。

   Payload Type

有効搭載量タイプ

      This field indicates the contents of the Payload Data field, using
      the IP Protocol/Payload value.  Up-to-date values of the IP
      Protocol/Payload are specified in the most recent "Assigned
      Numbers" [RFC-1700].

IPプロトコル/有効搭載量値を使用して、この分野は有効搭載量Data分野のコンテンツを示します。 最新の「規定番号」[RFC-1700]でIPプロトコル/有効搭載量の最新の値は指定されます。

      This field is opaque.  That is, the value is set prior to
      encryption, and is examined only after decryption.

この分野は不透明です。 すなわち、値は、暗号化の前に設定されて、復号化の後にだけ調べられます。

         For example, when encrypting an entire IP datagram (Tunnel-
         Mode), this field will contain the value 4, which indicates
         IP-in-IP encapsulation.

全体のIPデータグラム(トンネルモード)を暗号化するとき、例えば、この分野は値4を含むでしょう。(それは、IPにおけるIPカプセル化を示します)。

Karn, et al                   Experimental                      [Page 5]

RFC 1851                        ESP 3DES                  September 1995

Karn、他Experimental[5ページ]RFC1851の超能力3DES1995年9月

3.  Algorithm

3. アルゴリズム

   The 3DES algorithm is a simple variant on the DES-CBC algorithm.  The
   DES function is replaced by three rounds of that function, an
   encryption followed by a decryption followed by an encryption, each
   with independant keys, k1, k2 and k3.

3DESアルゴリズムはDES-CBCアルゴリズムの簡単な異形です。 DES機能をその機能の3ラウンドに取り替えます、と暗号化は暗号化があとに続いた復号化で続きました、それぞれ「不-扶養家族」キー、k1、k2、およびk3で。

   Note that when all three keys (k1, k2 and k3) are the same, 3DES is
   equivalent to DES-CBC.  This property allows the 3DES hardware
   implementations to operate in DES mode without modification.

すべての3個のキー(k1、k2、およびk3)が同じであるときに、3DESがDES-CBCに同等であることに注意してください。 この特性で、3DESハードウェア実装は変更なしでDESモードで作動します。

   For more explanation and implementation information for Triple DES,
   see [Schneier94].

Triple DESのための、より多くの説明と実装情報に関しては、[Schneier94]を見てください。

3.1.  Encryption

3.1. 暗号化

   Append zero or more octets of (preferably random) padding to the
   plaintext, to make its modulo 8 length equal to 6.  For example, if
   the plaintext length is 41, 5 octets of padding are added.

(望ましくは無作為)の詰め物のゼロか、より多くの八重奏を平文に追加して、8長さの同輩に法を6まで作ってください。 例えば、平文の長さが41、5であるなら、詰め物の八重奏は加えられます。

   Append a Pad Length octet containing the number of padding octets
   just added.

ただ加えられた詰め物八重奏の数を含むPad Length八重奏を追加してください。

   Append a Payload Type octet containing the IP Protocol/Payload value
   which identifies the protocol header that begins the payload.

ペイロードを始めるプロトコルヘッダーを特定するIPプロトコル/有効搭載量値を含む有効搭載量Type八重奏を追加してください。

   Provide an Initialization Vector (IV) of the size indicated by the
   SPI.

SPIによって示されたサイズの初期設定Vector(IV)を提供してください。

   Encrypt the payload with Triple DES (EDE mode), producing a
   ciphertext of the same length.

同じ長さの暗号文を生産して、Triple DES(EDEモード)があるペイロードを暗号化してください。

   Octets are mapped to DES blocks in network order (most significant
   octet first) [RFC-1700].  Octet 0 (modulo 8) of the payload
   corresponds to bits 1-8 of the 64-bit DES input block, while octet 7
   (modulo 8) corresponds to bits 57-64 of the DES input block.

八重奏がネットワークオーダーにおけるDESブロックに写像される、(最も重要な八重奏、1番目) [RFC-1700。] ペイロードの八重奏0(法8)は64ビットのDES入力ブロックのビット1-8に対応しています、八重奏7(法8)はDES入力ブロックのビット57-64に対応していますが。

   Construct an appropriate IP datagram for the target Destination, with
   the indicated SPI, IV, and payload.

目標Destinationのために示されたSPI、IV、およびペイロードで適切なIPデータグラムを組み立ててください。

   The Total/Payload Length in the encapsulating IP Header reflects the
   length of the encrypted data, plus the SPI, IV, padding, Pad Length,
   and Payload Type octets.

要約IP HeaderにおけるTotal/有効搭載量Lengthは暗号化されたデータ、SPI、IV、詰め物、Pad Length、および有効搭載量Type八重奏の長さを反映します。

Karn, et al                   Experimental                      [Page 6]

RFC 1851                        ESP 3DES                  September 1995

Karn、他Experimental[6ページ]RFC1851の超能力3DES1995年9月

3.2.  Decryption

3.2. 復号化

   First, the SPI field is removed and examined.  This is used as an
   index into the local Security Parameter table to find the negotiated
   parameters and decryption key.

まず最初に、SPI野原は、取り除かれて、調べられます。 これは、交渉されたパラメタと復号化が主要であることがわかるのにインデックスとして地方のSecurity Parameterテーブルに使用されます。

   The negotiated form of the IV determines the size of the IV field.
   These octets are removed, and an appropriate 64-bit IV value is
   constructed.

IVの交渉されたフォームはIV分野のサイズを決定します。 これらの八重奏を取り除きます、そして、適切な64ビットのIV値を構成します。

   The encrypted part of the payload is decrypted using Triple DES (DED
   mode).

ペイロードの暗号化された一部分が、Triple DES(DEDモード)を使用することで解読されます。

   The Payload Type is removed and examined.  If it is unrecognized, the
   payload is discarded with an appropriate ICMP message.

有効搭載量Typeは取り外されて、調べられます。 それが認識されていないなら、ペイロードは適切なICMPメッセージで捨てられます。

   The Pad Length is removed and examined.  The specified number of pad
   octets are removed from the end of the decrypted payload, and the IP
   Total/Payload Length is adjusted accordingly.

Pad Lengthは取り外されて、調べられます。 解読されたペイロードの端からパッド八重奏の指定された数を取り除きます、そして、それに従って、IP Total/有効搭載量Lengthを調整します。

   The IP Header(s) and the remaining portion of the decrypted payload
   are passed to the protocol receive routine specified by the Payload
   Type field.

Header(s)と解読されたペイロードの残存部分が渡されるIPは有効搭載量Type分野によって指定されたルーチンをプロトコルに受け取ります。

Security Considerations

セキュリティ問題

   Users need to understand that the quality of the security provided by
   this specification depends completely on the strength of the Triple
   DES algorithm, the correctness of that algorithm's implementation,
   the security of the key management mechanism and its implementation,
   the strength of the key [CN94], and upon the correctness of the
   implementations in all of the participating nodes.

ユーザは、この仕様で提供されたセキュリティの品質を完全Triple DESアルゴリズムの強さとそのアルゴリズムの実装の正当性とかぎ管理メカニズムのセキュリティと実装、キーの強さ[CN94]の上と、そして、参加ノードのすべての実装の正当性に依存するのを理解する必要があります。

   Among other considerations, applications may wish to take care not to
   select weak keys for any of the three DES rounds, although the odds
   of picking one at random are low [Schneier94, p. 233].

他の問題の中では、アプリケーションは3DESラウンドのいずれのためにも弱いキーを選択しないように注意したがっているかもしれません、無作為に1つを選ぶ可能性が低いのですが[Schneier94、p。 233].

   It was originally thought that DES might be a group, but it has been
   demonstrated that it is not [CW92].  Since DES is not a group,
   composition of multiple rounds of DES is not equivalent to simply
   using DES with a different key.

元々、DESがグループであるかもしれないと思われましたが、それが[CW92]でないことが示されました。 DESがグループでないので、DESの複数のラウンドの構成は単に異なったキーがあるDESを使用するのに同等ではありません。

   Triple DES with independent keys is not, as naively might be
   expected, as difficult to break by brute force as a cryptosystem with
   three times the keylength.  A space/time tradeoff has been shown
   which can brute-force break triple block encryptions in the time

独立しているキーがある三重のDESは暴力で壊すのが純真に予想されるかもしれないようにkeylengthの3倍がある暗号系ほど難しくはありません。 見返りがブルートフォースがどれを壊すことができるかが示されたスペース/時代に、時間、ブロック暗号化を3倍にしてください。

Karn, et al                   Experimental                      [Page 7]

RFC 1851                        ESP 3DES                  September 1995

Karn、他Experimental[7ページ]RFC1851の超能力3DES1995年9月

   naively expected for double encryption [MH81].

二重暗号化[MH81]のために純真に予想されています。

   However, 2DES can be broken with a meet-in-the-middle attack, without
   significantly more complexity than breaking DES requires [ibid], so
   3DES with independant keys is actually needed to provide this level
   of security.  An attack on 3DES using two independent keys that is
   somewhat (sixteen times) faster than any known for independent keys
   has been shown [OW91].

しかしながら、中央で会っている攻撃で2DESを壊すことができます、実際に「不-扶養家族」キーがある3DESがこのレベルのセキュリティを提供するのが必要であることでDESが必要とする壊す[ibid]よりかなり多くの複雑さなしで。 [OW91]は3DES使用twoから独立しているキーに対する独立しているキーで何より(16回)速くいくらか知られている攻撃に示されました。

   The cut and paste attack described by [Bell95] exploits the nature of
   all Cipher Block Chaining algorithms.  When a block is damaged in
   transmission, on decryption both it and the following block will be
   garbled by the decryption process, but all subsequent blocks will be
   decrypted correctly.  If an attacker has legitimate access to the
   same key, this feature can be used to insert or replay previously
   encrypted data of other users of the same engine, revealing the
   plaintext.  The usual (ICMP, TCP, UDP) transport checksum can detect
   this attack, but on its own is not considered cryptographically
   strong.  In this situation, user or connection oriented integrity
   checking is needed [RFC-1826].

[Bell95]によって説明されたカットアンドペースト攻撃はすべてのCipher Block Chainingアルゴリズムの本質を利用します。ブロックがトランスミッションで破損するとき、復号化では、それと以下のブロックの両方が復号化プロセスによって誤り伝えられるでしょうが、すべてのその後のブロックが正しく解読されるでしょう。 攻撃者が同じキーに正統のアクセスを持っているなら、同じエンジンの他のユーザの以前に暗号化されたデータを挿入するか、または再演するのにこの特徴を使用できます、平文を明らかにして。 普通(ICMP、TCP、UDP)の輸送チェックサムは、この攻撃を検出できますが、それ自身のところで強いと暗号で考えられません。 この状況、ユーザまたは接続では、指向の保全の照合が必要です[RFC-1826]。

   Although it is widely believed that 3DES is substantially stronger
   than DES, as it is less amenable to brute force attack, it should be
   noted that real cryptanalysis of 3DES might not use brute force
   methods at all.  Instead, it might be performed using variants on
   differential [BS93] or linear [Matsui94] cryptanalysis.  It should
   also be noted that no encryption algorithm is permanently safe from
   brute force attack, because of the increasing speed of modern
   computers.

それがブルートフォースアタックにより従順でなくて、3DESがDESより実質的に強いと広く信じられていますが、3DESの本当の暗号文解読術が全く力任せのメソッドを使用しないかもしれないことに注意されるべきです。 代わりに、それは、特異[BS93]か直線的な[Matsui94]暗号文解読術で異形を使用することで実行されるかもしれません。 また、どんな暗号化アルゴリズムも永久にブルートフォースアタックから安全でないことに注意されるべきです、現代のコンピュータの増加する速度のために。

   As with all cryptosystems, those responsible for applications with
   substantial risk when security is breeched should pay close attention
   to developments in cryptography, and especially cryptanalysis, and
   switch to other transforms should 3DES prove weak.

暗号系、セキュリティがbreechedされるときのかなりのリスクがあるアプリケーションに責任があるものが暗号、および特に暗号文解読術で開発への周到な注意を支払うはずであり、3DESが、弱いと判明するなら他へのスイッチが変えるすべてのように。

Acknowledgements

承認

   Some of the text of this specification was derived from work by
   Randall Atkinson for the SIP, SIPP, and IPv6 Working Groups.

この仕様のテキストのいくつかから、ランドル・アトキンソンはSIP、SIPP、およびIPv6 Working Groupsのために仕事に由来されていました。

   Comments should be submitted to the ipsec@ans.net mailing list.

ipsec@ans.net メーリングリストにコメントを提出するべきです。

Karn, et al                   Experimental                      [Page 8]

RFC 1851                        ESP 3DES                  September 1995

Karn、他Experimental[8ページ]RFC1851の超能力3DES1995年9月

References

参照

   [Bell95] Bellovin, S., "An Issue With DES-CBC When Used Without
            Strong Integrity", Proceedings of the 32nd IETF, Danvers,
            MA, April 1995.

[Bell95]Bellovin、S.、「強い保全なしで使用されるとDES-CBCと共に発行する、」、第32IETF、ダンバース(MA)(1995年4月)の議事

   [BS93]   Biham, E., and Shamir, A., "Differential Cryptanalysis of
            the Data Encryption Standard", Berlin: Springer-Verlag,
            1993.

[BS93]Biham、E.とシャミル、A.、「データ暗号化規格の差分解読法」ベルリン: 追出石-Verlag、1993。

   [CN94]   Carroll, J.M., and Nudiati, S., "On Weak Keys and Weak Data:
            Foiling the Two Nemeses", Cryptologia, Vol. 18 No. 23 pp.
            253-280, July 1994.

キャロル、[CN94]J.M.とNudiati、S.、「弱いキーと弱いデータに関して:、」 「Two Nemesesをくじきます」、Cryptologia、Vol.18No.23ページ 253-280と、1994年7月。

   [CW92]   Campbell, K.W., and Wiener, M.J., "Proof that DES Is Not a
            Group", Advances in Cryptology -- Crypto '92 Proceedings,
            Berlin: Springer-Verlag, 1993, pp 518-526.

[CW92] キャンベル、K.W.、およびWiener、M.J.は「そのDES Is Not a Groupを検査します」、CryptologyのAdvances--暗号92年Proceedings、ベルリン: 追出石-Verlag、1993、pp518-526。

   [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月。

   [FIPS-46-1]
            US National Bureau of Standards, "Data Encryption Standard",
            Federal Information Processing Standard (FIPS) Publication
            46-1, January 1988.

[FIPS-46-1]米国規格基準局、「データ暗号化規格」、連邦情報処理基準(FIPS)公表46-1、1988年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.

[FIPS-74]米国規格基準局、「データ暗号化規格を実装して、使用するためのガイドライン」、連邦情報処理基準(FIPS)公表74(1981年4月)。

   [FIPS-81]
            US National Bureau of Standards, "DES Modes of Operation"
            Federal Information Processing Standard (FIPS) Publication
            81, December 1980.

1980年12月の[FIPS-81]米国規格基準局、「DES運転モード」連邦情報処理基準(FIPS)公表81。

   [Matsui94]
            Matsui, M., "Linear Cryptanalysis method dor DES Cipher,"
            Advances in Cryptology -- Eurocrypt '93 Proceedings, Berlin:
            Springer-Verlag, 1994.

[Matsui94] 松井、M.、「直線的なCryptanalysisメソッドdor DES Cipher」、CryptologyのAdvances--Eurocrypt93年Proceedings、ベルリン: 追出石-Verlag、1994。

   [MH81]   Merle, R.C., and Hellman, M., "On the Security of Multiple
            Encryption", Communications of the ACM, v. 24 n. 7, 1981,
            pp. 465-467.

[MH81] メール、R.C.とヘルマン、「複数の暗号化のセキュリティ」のACM、vのM.Communications。 24 n。 7 1981、ページ 465-467.

Karn, et al                   Experimental                      [Page 9]

RFC 1851                        ESP 3DES                  September 1995

Karn、他Experimental[9ページ]RFC1851の超能力3DES1995年9月

   [OW91]   van Oorschot, P.C., and Weiner, M.J.  "A Known-Plaintext
            Attack on Two-Key Triple Encryption", Advances in Cryptology
            -- Eurocrypt '90 Proceedings, Berlin: Springer-Verlag, 1991,
            pp. 318-325.

[OW91]はM. J. Oorschot、P.C.、およびヴェイネル、「2主要な三重の暗号化に対する知られている平文攻撃」をバンに積みます、CryptologyのAdvances--Eurocrypt90年Proceedings、ベルリン: 追出石-Verlag、1991、ページ 318-325.

   [RFC-1800]
            Postel, J., "Internet Official Protocol Standards", STD 1,
            RFC 1800, USC/Information Sciences Institute, July 1995.

[RFC-1800] ポステル、J.、「インターネット公式プロトコル標準」、STD1、USC/情報科学が1995年7月に設けるRFC1800。

   [RFC-1700]
            Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
            1700, USC/Information Sciences Institute, October 1994.

[RFC-1700] USC/情報科学が1994年10月に設けるレイノルズ、J.、およびJ.ポステル、「規定番号」、STD2、RFC1700。

   [RFC-1825]
            Atkinson, R., "Security Architecture for the Internet
            Protocol", RFC-1825, Naval Research Laboratory, July 1995.

[RFC-1825] アトキンソン、R.、「インターネットプロトコルのためのセキュリティー体系」、RFC-1825、海軍研究試験所、1995年7月。

   [RFC-1826]
            Atkinson, R., "IP Authentication Header", RFC-1826, Naval
            Research Laboratory, July 1995.

[RFC-1826] アトキンソン、R.、「IP認証ヘッダー」、RFC-1826、海軍研究試験所、1995年7月。

   [RFC-1827]
            Atkinson, R., "IP Encapsulating Security Protocol (ESP)",
            RFC-1827, Naval Research Laboratory, July 1995.

[RFC-1827] アトキンソン、R.、「セキュリティがプロトコル(超能力)であるとカプセル化するIP」、RFC-1827、海軍研究試験所、1995年7月。

   [Schneier94]
            Schneier, B., "Applied Cryptography", John Wiley & Sons, New
            York, NY, 1994.  ISBN 0-471-59756-2

[Schneier94]シュナイアー、B.、「適用された暗号」、ジョン・ワイリー、および息子、ニューヨーク(ニューヨーク)1994。 ISBN0-471-59756-2

   [Tuchman79]
            Tuchman, W, "Hellman Presents No Shortcut Solutions to DES",
            IEEE Spectrum, v. 16 n. 7, July 1979, pp. 40-41.

[Tuchman79] タクマン、W、「ヘルマンはデスの近道のソリューションを全く提示しない」IEEE Spectrum、v。 16 n。 7 1979年7月、ページ 40-41.

Karn, et al                   Experimental                     [Page 10]

RFC 1851                        ESP 3DES                  September 1995

Karn、他Experimental[10ページ]RFC1851の超能力3DES1995年9月

Author's Address

作者のアドレス

   Questions about this memo can also be directed to:

また、このメモに関する質問による以下のことよう指示できます。

      Phil Karn
      Qualcomm, Inc.
      6455 Lusk Blvd.
      San Diego, California  92121-2779

フィルKarnクアルコムInc.6455ラスクBlvd. サンディエゴ、カリフォルニア92121-2779

      karn@unix.ka9q.ampr.org

karn@unix.ka9q.ampr.org

      Perry Metzger
      Piermont Information Systems Inc.
      160 Cabrini Blvd., Suite #2
      New York, NY  10033

ニューヨーク、スイート#2ニューヨーク ペリーメッツガーピアモント情報システム株式会社160カブリーニBlvd.、10033

      perry@piermont.com

perry@piermont.com

      William Allen Simpson
      Daydreamer
      Computer Systems Consulting Services
      1384 Fontaine
      Madison Heights, Michigan  48071

ミシガン ウィリアムアレンのシンプソン空想家コンピュータシステムズのコンサルタント業務1384フォンテーヌマディソンの高さ、48071

      Bill.Simpson@um.cc.umich.edu
          bsimpson@MorningStar.com

Bill.Simpson@um.cc.umich.edu bsimpson@MorningStar.com

Karn, et al                   Experimental                     [Page 11]

Karn、他のExperimental[11ページ]