RFC2451 日本語訳
2451 The ESP CBC-Mode Cipher Algorithms. R. Pereira, R. Adams. November 1998. (Format: TXT=26400 bytes) (Status: PROPOSED STANDARD)
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.
この文書は、Internet community のための Internet standards track
protocol を明細に記述し、改良のための討議と提案を要求する。このプロト
コルの標準化状態とステータスについては、"Internet Official Protocol
Standards" (STD 1) の最新版を参照してもらいたい。このメモの配布は、無
制限である。
-------------------------------------------------------------------------
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
-------------------------------------------------------------------------
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 (Encapsulating Security Payload: 暗号ペイロード)
Protocol で CBC-mode 暗号アルゴリズムがどのように使用されるかを記述す
る。これは、ある暗号アルゴリズムをどのように使用するかをはっきりと述べ
るだけでなく、すべての CBC-mode 暗号アルゴリズムをどのように使用するか
についても述べる。
-------------------------------------------------------------------------
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
1. 序論...........................................................2
1.1 要求の列挙..................................................2
1.2 知的財産権表示..............................................2
2. 暗号アルゴリズム...............................................2
2.1 モード......................................................3
2.2 鍵サイズ....................................................3
2.3 弱点鍵......................................................4
2.4 ブロックサイズとパディング..................................5
2.5 ラウンド....................................................6
2.6 背景........................................................6
2.7 パフォーマンス..............................................8
3. ESP ペイロード.................................................8
3.1 ESP 環境に関する考察........................................9
3.2 鍵材料......................................................9
4. セキュリティに関する考察.......................................9
5. 参考文献......................................................10
6. 謝辞..........................................................11
7. 編集者のアドレス..............................................12
8. 著作権表示全文................................................14
-------------------------------------------------------------------------
1. Introduction
1. 序論
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.
Encapsulating Security Payload (ESP) [Kent98] は、保護されるためのペイ
ロードデータを暗号化することにより IP データグラムに機密性を提供する。
この仕様書は、CBC-mode 暗号アルゴリズムの 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.
読者は、"Security Architecture for the Internet Protocol"
[Atkinson95], "IP Security Document Roadmap" [Thayer97] と "IP
Encapsulating Security Payload (ESP)" [Kent98] 文書で記述されている用
語と概念に精通していると当然思われる。
Furthermore, this document is a companion to [Kent98] and MUST be
read in its context.
それだけでなく、この文書は [Kent98] に対する片方であり、その背景を理解
しなければならない (MUST)。
1.1 Specification of Requirements
1.1 要求の列挙
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] で記述されたとして解釈されること
ができる。
1.2 Intellectual Property Rights Statement
1.2 知的財産権表示
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.
-------------------------------------------------------------------------
2. Cipher Algorithms
2. 暗号アルゴリズム
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 で使用されるかもしれ
ない。
2.1 Mode
2.1 モード
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.
この文書の範囲内で記述されるか、ほのめかされる対称ブロック暗号アルゴリ
ズムすべては、Cipher Block Chaining (CBC) モードを使用する。このモード
は、ブロックサイズと同じサイズの Initialization Vector (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] で手に入れられることがで
きる。
2.2 Key Size
2.2 鍵サイズ
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 bits の倍数でなければならない (MUST)
ことを定める。
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'.
CAST128 に関し、CAST-128 鍵スケジュールは 128 bits の入力鍵を決め
てかかる。それゆえ、CAST-128 128 bits より小さい鍵は、右端または least
significant の位置に 128 bits 最後まで zeros でパッドされなければなら
ない (MUST)。したがって、もしあなたが 80 bits サイズの鍵 '3B5D831CFE'
を持つなら、128 bits サイズの鍵 '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.
最初の 3DES 鍵は最初の 64 bits から得られ、2 番目は次の 64 bits か
ら、3 番目は最後の 64 bits から得られる。新しい鍵のセットを初めて受け
入れる時、実装はパリティビットを考慮しなければならない (MUST)。3 つの
鍵それぞれは、パリティのために使用される追加の 8 bits を持つ長さからな
る、実際 56 bits の鍵である。
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 bits であることと
実装が 40 bits より小さい鍵サイズを使用しない (NOT) ことを著者が強く忠
告することに、読者は注意すべきである。
2.3 Weak Keys
2.3 弱点鍵
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.
弱点鍵チェックは、おこなわれるべきである (SHOULD)。もしそのような (弱
点) 鍵が見つけられたなら、その鍵は拒否されるべき (SHOULD) であり、新し
い SA が要求されるべきである (SHOULD)。ある一部の暗号アルゴリズムは、
弱点鍵や、弱点の性質のために使用されてはならない (MUST) 鍵を持つ。
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:
No known weak keys.
弱点鍵は知られていない。
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-box で
の同一のエントリを生成する鍵である。不運にも、S- box 値が生成される前
に弱点鍵をテストする方法はない。しかしながら、そのような鍵をランダムに
生成する機会は小さい。
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 は、いわゆる semi-weak keys (半分弱点鍵) と possibly-weak keys (も
しかしたら弱点鍵) を含む、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.
しかしながら、もし依存しない 64-bit 鍵の最初 2 つか最後 2 つが等しい
(k1 == k2 または k2 == k3) なら、その時 3DES 演算は単に DES と等しい。
実装者は、この特性を示す鍵を拒否しなければならない (MUST)。
2.4 Block Size and Padding
2.4 ブロックサイズとパディング
All of the algorithms described in this document use a block size of
eight octets (64 bits).
この文書で記述されるアルゴリズムすべては、8 octets (64 bits) のブロッ
クサイズを使用する。
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] で明細に述べられたとして、octets でペイロードタ
イプとパッド長での境界をあわせるために使用される。パディングは、
8 octet (64 bit) 境界に暗号化されるデータを配置するために十分でなけれ
ばならない。
2.5 Rounds
2.5 ラウンド
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.
この変数は、ブロックがどれだけの回数で暗号化されるかを決める。この変数
は交渉により取り決められるかもしれない (MAY) が、取り決められない時、
デフォルト値はいつも存在しなければならない (MUST)。
+====================+============+======================+
| 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) |
+--------------------+------------+----------------------+
2.6 Backgrounds
2.6 背景
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 設計手順は、Canada の Ontario, Kingston, Queen's University で
Carlisle Adams と Stafford Tavares により、もともと開発された。後の向
上は、Entrust Technologies の Carlisle Adams と Michael Wiener により
何年にも渡って作り直された。CAST-128 は、[Adams97] で概要を述べられた
として CAST Design Procedure を応用した結果である。
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 により開発された。これは特許が取られている (pat.no.
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 アルゴリズムは、Europe と United States で特許が取られ、Japan で
特許出願中である。Licenses は、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:
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].
口語で Triple DES" や DES-EDE3 として知られる、この DES 変形は、(暗号
化する) それぞれのブロックを 3 回、そのそれぞれの回を異なった鍵で処理
する。1 回の 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] の単純な変
形である。"outer" テクニックが使用される。
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 で、Initialization Vector (IV) は、最初の 64-bit (8 byte)
平文ブロック (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] を参照しなさ
い。
2.7 Performance
2.7 パフォーマンス
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] を参照してもらいたい。
-------------------------------------------------------------------------
3. ESP Payload
3. ESP ペイロード
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 と後に続く raw 暗号文により構成される。これにした
がい [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
+---------------+---------------+---------------+---------------+
| |
+ 初期ベクトル (8 octets) +
| |
+---------------+---------------+---------------+---------------+
| |
~ 暗号化されたペイロード (可変長) ~
| |
+---------------------------------------------------------------+
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 フィールドは、使用される暗号アルゴリズムのブロックサイズと同じサイ
ズでなければならない (MUST)。IV は、ランダムに選ばれなければならない
(MUST)。共通の実行は、最初の 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 についてカウンタや他の low-Hamming distance source を
決して使用してはならない (MUST NOT)。
3.1 ESP Environmental Considerations
3.1 ESP 環境に関する考察
Currently, there are no known issues regarding interactions between
these algorithms and other aspects of ESP, such as use of certain
authentication schemes.
確実な認証方法の使用のような、これらの ESP アルゴリズムと ESP の他の側
面の間での相互作用に関する問題点は、現在知られていない。
3.2 Keying Material
3.2 鍵材料
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
bits of the keying material, where represents the required
key size.
暗号アルゴリズムの暗号化と復号鍵は、鍵材料の最初の bits から得られ
る。 は、要求される鍵サイズを表す。
-------------------------------------------------------------------------
4. Security Considerations
4. セキュリティに関する考察
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.
さらに進んだセキュリティに関する考察について、読者は実際の暗号アルゴリ
ズムを記述する文書を読むことが奨励される。
-------------------------------------------------------------------------
5. References
5. 参考文献
[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.
[Baldwin96] Baldwin, R. and R. Rivest, "The RC5, RC5-CBC, RC5-CBC-
Pad, and RC5-CTS Algorithms", RFC 2040, October 1996.
[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}).
[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.
[Crypto93] J. Daemen, R. Govaerts, J. Vandewalle, "Weak Keys for
IDEA", Advances in Cryptology, 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.
[Kent98] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[Lai] X. Lai, "On the Design and Security of Block Ciphers",
ETH Series in Information Processing, v. 1, Konstanz:
Hartung-Gorre Verlag, 1992.
[Madson98] Madson, C. and N. Dorswamy, "The ESP DES-CBC Cipher
Algorithm With Explicit IV", RFC 2405, November 1998.
[MOV] A. Menezes, P. Van Oorschot, S. Vanstone, "Handbook of
Applied Cryptography", CRC Press, 1997. ISBN 0-8493-
8523-7
[Schneier] B. Schneier, "Applied Cryptography Second Edition", John
Wiley & Sons, New York, NY, 1995. ISBN 0-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
[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
[Thayer97] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security
Document Roadmap", RFC 2411, November 1998.
[Tuchman79] Tuchman, W, "Hellman Presents No Shortcut Solutions to
DES", IEEE Spectrum, v. 16 n. 7, July 1979, pp. 40-41.
-------------------------------------------------------------------------
6. Acknowledgments
6. 謝辞
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 mailing list からの次の議論に基づく。
Special thanks to Carlisle Adams and Paul Van Oorschot both of
Entrust Technologies who provided input and review of CAST.
CAST の input と review を提供した 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. Simpson, N. Doraswamy, P. Metzger と P.
Karn の 3 人に感謝する。
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 と他の暗号での input について、Markku-Juhani Saarinen, Helger
Lipmaa と Bart Preneel に感謝する。
-------------------------------------------------------------------------
7. Editors' Addresses
7. 編集者のアドレス
Roy Pereira
TimeStep Corporation
Phone: +1 (613) 599-3610 x 4808
EMail: rpereira@timestep.com
Rob Adams
Cisco Systems Inc.
Phone: +1 (408) 457-5397
EMail: adams@cisco.com
Contributors:
貢献者:
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
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:
IPSec working group は、IPSec working group の mailing list
(ipsec@tis.com) 経由か、その議長を通して連絡されてもよい:
Robert Moskowitz
International Computer Security Association
EMail: rgm@icsa.net
Theodore Y. Ts'o
Massachusetts Institute of Technology
EMail: tytso@MIT.EDU
-------------------------------------------------------------------------
8. Full Copyright Statement
8. 著作権表示全文
Copyright (C) The Internet Society (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.
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.
一覧
スポンサーリンク
