RFC2405 日本語訳

2405 The ESP DES-CBC Cipher Algorithm With Explicit IV. C. Madson, N.Doraswamy. November 1998. (Format: TXT=20208 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                          C. Madson
Request for Comments: 2405                           Cisco Systems, Inc.
Category: Standards Track                                   N. Doraswamy
                                                      Bay Networks, Inc.
                                                           November 1998

コメントを求めるワーキンググループC.マドソン要求をネットワークでつないでください: 2405年のシスコシステムズInc.カテゴリ: 標準化過程N.DoraswamyベイネットワークスInc.1998年11月

                    The ESP DES-CBC Cipher Algorithm
                            With Explicit IV

明白なIVがある超能力DES-CBC暗号アルゴリズム

Status of this Memo

この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.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

Copyright(C)インターネット協会(1998)。 All rights reserved。

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).

このドキュメントはCipher Block Chaining ModeにおけるDES Cipherアルゴリズムの使用について説明します、明白なIVと共に、IPSec Encapsulating Security有効搭載量(超能力)の文脈の中の秘密性メカニズムとして。

1. Introduction

1. 序論

   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.

このドキュメントは、Encapsulating Security有効搭載量の文脈の中でCipher Block Chaining ModeにおけるDES Cipherアルゴリズムの使用を秘密性メカニズムと説明します。

   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は認証機構ではありません。 [他の場所の中の[Schneier96]で説明されたDES-MACは認証を提供しますが、ここでDES-MACについて議論しません。]

   For further information on how the various pieces of ESP fit together
   to provide security services, refer to [ESP] and [road].

超能力の様々な断片がセキュリティー・サービスを提供するためにどう一緒に合うかに関する詳細について、[超能力]と[道路]を参照してください。

Madson & Doraswamy          Standards Track                     [Page 1]

RFC 2405            The ESP DES-CBC Cipher Algorithm       November 1998

マドソンとDoraswamy規格は超能力DES-CBC暗号アルゴリズム1998年11月にRFC2405を追跡します[1ページ]。

   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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC-2119]で説明されるように本書では解釈されることであるべきですか?

2. Algorithm and Mode

2. アルゴリズムとモード

   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モードの良い記述を提供します。

2.1 Performance

2.1 パフォーマンス

   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].

フィルKarnは90MHzのPentiumで10.45Mbpsを達成するためにDES-CBCソフトウェアを調整しました、133MHzのPentiumで15.9Mbpsに比例して。 他のDES速度見積りは[Schneier96]で見つけられるかもしれません。

3. ESP Payload

3. 超能力有効搭載量

   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ビット)の明白な初期設定Vector(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とベスト8八重奏に次の暗号化プロセスのためのIVとして無作為のデータを使用することになっています。 これはパケットの向こう側にCBCを論理的に広げています。 また、それには、乱数genratorからの情報の漏出を制限する利点があります。 どのmechnismが使用されていても、受信機はこの値のために少しの意味も仮定してはいけません、それが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暗号化を避けるために、実装はIVsにカウンタか他の低いハミング距離ソースを使用してはいけません。

   The payload field, as defined in [ESP], is broken down according to
   the following diagram:

以下のダイヤグラムによると、[超能力]で定義されるペイロード分野は砕けています:

Madson & Doraswamy          Standards Track                     [Page 2]

RFC 2405            The ESP DES-CBC Cipher Algorithm       November 1998

マドソンとDoraswamy規格は超能力DES-CBC暗号アルゴリズム1998年11月にRFC2405を追跡します[2ページ]。

      +---------------+---------------+---------------+---------------+
      |                                                               |
      +                   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

+---------------+---------------+---------------+---------------+ | | + 初期設定ベクトル(IV)+| | +---------------+---------------+---------------+---------------+ | | ~ 暗号化された有効搭載量(可変長)~| | +---------------------------------------------------------------+ 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

3.1 Block Size and Padding

3.1 ブロック・サイズと詰め物

   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].

詰め物を必要とするとき、[超能力]で指定されたコンベンションによると、それをしなければなりません。

4. Key Material

4. 主要な材料

   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.

[アーチ]は超能力変換のための材料を合わせる引き出す一般的機構について説明します。 いくらかの量の合わせることの材料からのキーの派生が異ならない、手動、そして、自動的に合わせられたセキュリティ協会。

   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.

弱いキーはSHOULDをチェックします。実行されます。 キーはそのようなものであるなら見つけられて、キーはSHOULDです。拒絶されていて新しい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]のために。

Madson & Doraswamy          Standards Track                     [Page 3]

RFC 2405            The ESP DES-CBC Cipher Algorithm       November 1998

マドソンとDoraswamy規格は超能力DES-CBC暗号アルゴリズム1998年11月にRFC2405を追跡します[3ページ]。

4.1 Weak Keys

4.1 弱いキー

   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]で弱いキーのリストを見つけることができます。

4.2 Key Lifetime

4.2 主要な生涯

   [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]はブルートフォースアタックのためのコストとキーリカバリー時間について議論します。 それは1 40ビットの、そして、56ビットのDESキーのために回収されたキーあたり1つのキー/費用を取り戻す総費用/時間の様々な組み合わせを提示します、遅い1995の見積りに基づいて。

   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.

単に予備CPUサイクルか他の安価のリソースを費やしているいわゆるカジュアルなハッカーのためのinfeasableであると56ビットのDES keyspaceの力任せの検索を考えることができますが、もう少しのお金を使っても構わないと思っているだれかの範囲の中にそれはあります。

   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万ドルの費用で、平均19日間でカスタム開発されたチップを使用することで技術とほんの3時間後にすぐ入手できた状態で使用することで56ビットのDESキーを回収できます。

   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]は3.5時間(1993の見積り)で主要なDESを壊すことができる$の1Mのマシンについて議論します、知られている平文攻撃を使用して。 Security Considerations部で議論するように、知られている平文攻撃は合理的にありそうです。

   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.

推薦が全くここで作られたボリュームベースの生涯ない間、そこに知られている平文をあることができる増強されたprobabiltyが蓄積されるとshoudにその与えられた十分なボリュームに述べられます。

5. Interaction with Authentication Algorithms

5. 認証アルゴリズムとの相互作用

   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アルゴリズムの使用も排除する問題が知られていません。

Madson & Doraswamy          Standards Track                     [Page 4]

RFC 2405            The ESP DES-CBC Cipher Algorithm       November 1998

マドソンとDoraswamy規格は超能力DES-CBC暗号アルゴリズム1998年11月にRFC2405を追跡します[4ページ]。

6. Security Considerations

6. セキュリティ問題

   [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アルゴリズムの強さとそのアルゴリズムの実装の正当性とSecurity Association管理メカニズムのセキュリティと実装、キーの強さ[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]はすべてのCipher Block Chainingアルゴリズムに適用される攻撃を継ぐカットアンドペーストについて説明します。認証機構の使用でこの攻撃は扱うことができます。

   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.

少しも対応する認証機構のない暗号メカニズムの使用は強くお勧めできないです。 また、認証を含んでいる超能力変換にこの暗号を使用できます。 また、仲間AHヘッダーがあれば認証を含んでいない超能力変換にそれを使用できます。 その他の詳細について[超能力]、[AH]、[アーチ]、および[道路]を参照してください。

   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.

デフォルト超能力詰め物が使用されているとき、詰め物バイトには、予測できる値があります。 彼らは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平文暗号文組を必要とする差分解読法に基づいている選ばれた平文攻撃を示しました。そこでは、1組のサイズが1つの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]は、1を割ることができる1ドルのMillionがDES分解マシンの設計に主要な3.5時間毎を費やすのを示しました。 これは非常に実用的な攻撃です。

   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.

知られている平文の1か2ブロックが、DESキーを回収するために十分です。 IPデータグラムが1ブロックの知られているそして/または、推測可能なヘッダーテキストで通常始まるので、頻繁なキーチェンジはこの攻撃から守らないでしょう。

Madson & Doraswamy          Standards Track                     [Page 5]

RFC 2405            The ESP DES-CBC Cipher Algorithm       November 1998

マドソンとDoraswamy規格は超能力DES-CBC暗号アルゴリズム1998年11月にRFC2405を追跡します[5ページ]。

   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の使用で提供されたプライバシーのレベルはcleartextとしてデータグラムを送るよりはるかに大きいです。

   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.

以下の概要がスティーブBellovinによって提供されている状態で、IVsに無作為の値を使用するためのケースは洗練されました。 詳細について[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.

「あなたはIVとしてカウンタを使用するか、または連続したIVsの間には、低いハミング距離がある状態である他のソースを使用するなら、問題が起こります、CBCモードにおける暗号化のために。」 CBCモードで、暗号化のための「有効な平文」は、実際の平文のXORとpreceedingブロックの暗号文です。 通常、それは無作為の値です。(その値は有効な平文がかなり無作為であることを意味します)。 パケットによって実際の平文の多くのブロックがあまり変化しないので、それは良いです。

      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とあまり異なっていなくて、また実際の平文ブロックがパケットの前のものとあまり異なっていないと、有効な平文はあまり異ならないでしょう。 これは、あなたがわずかいくつかのビット位置で異なる平文ブロックに組の暗号文ブロックを結合させることを意味します。 「これはさまざまなcryptanalytic攻撃のためのくさびであるかもしれません。」

   The discussion on IVs has been updated to require that an
   implementation not use a low-Hamming distance source for IVs.

実装がIVsに低いハミング距離ソースを使用しないのが必要であるようにIVsについての議論をアップデートしました。

7. References

7. 参照

   [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.、「」 第32インターネットのプレゼンテーションが特別委員会を設計することでの強い保全ダンバースマサチューセッツ(4月1995)なしで使用されると、DES-CBCと共に発行します。

   [Bell96]     Bellovin, S., "Problem Areas for the IP Security
                Protocols", Proceedings of the Sixth Usenix Security
                Symposium, July 1996.

[Bell96] Bellovin、S.、「IPセキュリティー・プロトコルのための問題領域」、第6Usenixセキュリティシンポジウム、1996年7月の議事。

Madson & Doraswamy          Standards Track                     [Page 6]

RFC 2405            The ESP DES-CBC Cipher Algorithm       November 1998

マドソンとDoraswamy規格は超能力DES-CBC暗号アルゴリズム1998年11月にRFC2405を追跡します[6ページ]。

   [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.、「IPセキュリティー・プロトコルのありえそうな平文暗号文解読術」、Networkの上のSymposiumとDistributed System Security、サンディエゴ(カリフォルニア)のページのProceedings 155-160と、1997( http://www.research.att.com/~smb/papers/probtxt ps、pdfも)年2月。

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

[BS93] Biham、E.、およびA.シャミル、「データ暗号化規格の差分解読法」、ベルリン: 追出石-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]の炎、M.、ディフィー、W.、Rivest、R.、シュナイアー、B.、Shimomura、T.、トンプソン、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]キャロル、J.M.、およびS.Nudiati、「弱いキーと弱いデータに関して:、」 「Two Nemesesをくじきます」、Cryptologia、Vol.18No.23ページ 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 (supercedes 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] 松井、M.、「DES Cipherのための直線的なCryptanalysisメソッド」、CryptologyのAdvances--Eurocrypt93年Proceedings、ベルリン: 追出石-Verlag、1994。

   [RFC-1750]   Eastlake, D., Crocker, S., and J. Schiller, "Randomness
                Recommendations for Security", RFC 1750, December 1994.

1994年12月の[RFC-1750]イーストレークとD.とクロッカー、S.とJ.シラー、「セキュリティのための偶発性推薦」RFC1750。

   [RFC-2119]   Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC-2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

Madson & Doraswamy          Standards Track                     [Page 7]

RFC 2405            The ESP DES-CBC Cipher Algorithm       November 1998

マドソンとDoraswamy規格は超能力DES-CBC暗号アルゴリズム1998年11月にRFC2405を追跡します[7ページ]。

   [Schneier96] Schneier, B., "Applied Cryptography Second Edition",
                John Wiley & Sons, New York, NY, 1996.  ISBN 0-471-
                12845-7.

[Schneier96]シュナイアー、B.、「適用された暗号第2版」、ジョン・ワイリー、および息子、ニューヨーク(ニューヨーク)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]ウインナソーセージ、M.J.、「効率的なDES主要な検索」(コンピュータサイエンスの学校、カールトン大学、オタワ(カナダ)TR-244)は1994がそうするかもしれません。 暗号の臀部セッションのときに、93年を提示しました。 [「データインターネットワークのための実際的な暗号」、W.ストーリングズ、現在 ftp://ripem.msu.edu/pub/crypt/docs/des-key-search.ps で利用可能なエディタ(IEEEコンピュータSociety Press)pp.31-79(1996)では、翻刻します。]

   [ESP]        Kent, S., and R. Atkinson, "IP Encapsulating Security
                Payload (ESP)", RFC 2406, November 1998.

[超能力] ケント、S.、およびR.アトキンソン、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC2406、1998年11月。

   [AH]         Kent, S., and R. Atkinson, "IP Authentication Header
                (AH)", RFC 2402, November 1998.

[ああ] ケント、S.とR.アトキンソン、「IP認証ヘッダー(ああ)」、RFC2402、1998年11月。

   [arch]       Kent, S., and R. Atkinson, "Security Architecture for
                the Internet Protocol", RFC 2401, November 1998.

[アーチ形に曲げます] 1998年11月のケント、S.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」RFC2401。

   [road]       Thayer, R., Doraswamy, N., and R. Glenn, "IP Security
                Document Roadmap", RFC 2411, November 1998.

[道路] セイヤーとR.とDoraswamy、N.とR.グレン、「IPセキュリティドキュメント道路地図」、RFC2411、1998年11月。

8. Acknowledgments

8. 承認

   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.

ここに提供された情報の多くはペリーメッツガーとウィリアム・アレン・シンプソン(特にSecurity Considerations部)によって書かれた様々な超能力-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.

また、ジム・ヒューズ、結合したデスCBC+HMAC-MD5 ESP変換、ANX bakeoff関係者、およびIPsecワーキンググループのメンバーの上のジムと共に働いていたそれらの人々による前の作品からこのドキュメントを一部得ます。

   Thanks to Rob Glenn for assisting with the nroff formatting.

ロブ・グレンにnroff形式を助けてくださってありがとうございます。

Madson & Doraswamy          Standards Track                     [Page 8]

RFC 2405            The ESP DES-CBC Cipher Algorithm       November 1998

マドソンとDoraswamy規格は超能力DES-CBC暗号アルゴリズム1998年11月にRFC2405を追跡します[8ページ]。

   The IPSec working group can be contacted via the IPSec working
   group's mailing list (ipsec@tis.com) or through its chairs:

IPSecワーキンググループのメーリングリスト( ipsec@tis.com )の近く、または、そのいすを通してIPSecワーキンググループに連絡できます:

     Robert Moskowitz
     International Computer Security Association

ロバート・マスコウィッツInternationalのコンピュータセキュリティ協会

     EMail: rgm@icsa.net

メール: rgm@icsa.net

     Theodore Y. Ts'o
     Massachusetts Institute of Technology

セオドアY.t○マサチューセッツ工科大学

     EMail: tytso@MIT.EDU

メール: tytso@MIT.EDU

9. Editors' Addresses

9. エディタのアドレス

   Cheryl Madson
   Cisco Systems, Inc.

シェリルマドソンシスコシステムズInc.

   EMail: cmadson@cisco.com

メール: cmadson@cisco.com

   Naganand Doraswamy
   Bay Networks, Inc.

Naganand DoraswamyベイネットワークスInc.

   EMail: naganand@baynetworks.com

メール: naganand@baynetworks.com

Madson & Doraswamy          Standards Track                     [Page 9]

RFC 2405            The ESP DES-CBC Cipher Algorithm       November 1998

マドソンとDoraswamy規格は超能力DES-CBC暗号アルゴリズム1998年11月にRFC2405を追跡します[9ページ]。

10.  Full Copyright Statement

10. 完全な著作権宣言文

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

Copyright(C)インターネット協会(1998)。 All rights reserved。

   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.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   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.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Madson & Doraswamy          Standards Track                    [Page 10]

マドソンとDoraswamy標準化過程[10ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

DAYOFYEAR関数 通算日を求める

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る