RFC3217 日本語訳
3217 Triple-DES and RC2 Key Wrapping. R. Housley. December 2001. (Format: TXT=19855 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Housley Request for Comments: 3217 RSA Laboratories Category: Informational December 2001
Housleyがコメントのために要求するワーキンググループR.をネットワークでつないでください: 3217年のRSA研究所カテゴリ: 情報の2001年12月
Triple-DES and RC2 Key Wrapping
三重のDESとRC2の主要なラッピング
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
Abstract
要約
This document specifies the algorithm for wrapping one Triple-DES key with another Triple-DES key and the algorithm for wrapping one RC2 key with another RC2 key. These key wrap algorithms were originally published in section 12.6 of RFC 2630. They are republished since these key wrap algorithms have been found to be useful in contexts beyond those supported by RFC 2630.
このドキュメントは別のTriple-DESキーによって主要な1Triple-DESを包装するためのアルゴリズムと別のRC2キーによって主要な1RC2を包装するためのアルゴリズムを指定します。 これらの主要な包装アルゴリズムは元々、RFC2630のセクション12.6で発行されました。 これらの主要な包装アルゴリズムがRFC2630によって支持されたものを超えた文脈で役に立つのがわかったので、それらは再刊されます。
1 Introduction
1つの序論
Management of symmetric cryptographic keys often leads to situations where one symmetric key is used to encrypt (or wrap) another. Key wrap algorithms are commonly used in two situations. First, key agreement algorithms (such as Diffie-Hellman [DH-X9.42]) generate a pairwise key-encryption key, and a key wrap algorithm is used to encrypt the content-encryption key or a multicast key with the pairwise key-encryption key. Second, a key wrap algorithm is used to encrypt the content-encryption key, multicast key, or session key in a locally generated storage key-encryption key or a key-encryption key that was distributed out-of-band.
左右対称の暗号化キーの経営者側はしばしば1個の対称鍵が別の(または、包装)ものをコード化するのに使用される状況につながります。 主要な包装アルゴリズムは2つの状況で一般的に使用されます。 まず最初に、主要な協定アルゴリズム(ディフィー-ヘルマン[DH-X9.42]などの)は対状主要な暗号化キーを発生させます、そして、主要な包装アルゴリズムは、満足している暗号化キーか対状主要な暗号化キーによって主要なマルチキャストをコード化するのに使用されます。 2番目に、主要な包装アルゴリズムは、局所的に発生した主記憶キイ暗号化キーかバンドの外で分配された主要な暗号化キーで主要な満足している暗号化キー、マルチキャストキー、またはセッションをコード化するのに使用されます。
This document specifies the algorithm for wrapping one Triple-DES key with another Triple-DES key [3DES], and it specifies the algorithm for wrapping one RC2 key with another RC2 key [RC2]. Encryption of a Triple-DES key with another Triple-DES key uses the algorithm specified in section 3. Encryption of a RC2 key with another RC2 key uses the algorithm specified in section 4. Both of these algorithms rely on the key checksum algorithm specified in section 2. Triple- DES and RC2 content-encryption keys are encrypted in Cipher Block Chaining (CBC) mode [MODES].
このドキュメントは別のTriple-DESキー[3DES]によって主要な1Triple-DESを包装するためのアルゴリズムを指定します、そして、それは別のRC2キー[RC2]によって主要な1RC2を包装するためのアルゴリズムを指定します。 別のTriple-DESキーによって主要なTriple-DESの暗号化はセクション3で指定されたアルゴリズムを使用します。 別のRC2キーによって主要なRC2の暗号化はセクション4で指定されたアルゴリズムを使用します。 これらのアルゴリズムの両方がセクション2で指定された主要なチェックサムアルゴリズムを当てにします。 Cipher Block Chaining(CBC)モード[MODES]で三重のDESとRC2満足している暗号化キーはコード化されます。
Housley Informational [Page 1] RFC 3217 Triple-DES and RC2 Key Wrapping December 2001
Housleyの情報[1ページ]のRFC3217の三重のDESとラッピング2001年12月に主要なRC2
In this document, the key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, and MAY are to be interpreted as described by Scott Bradner in [STDWORDS].
本書では、キーワードが解釈しなければならない、[STDWORDS]でスコット・ブラドナーによって説明されるようにNOT、REQUIRED、SHOULD、SHOULD NOT、RECOMMENDED、および5月を解釈することになっていなければなりませんか?
2 Key Checksum
2 主要なチェックサム
The key checksum algorithm is used to provide a key integrity check value. The algorithm is:
主要なチェックサムアルゴリズムは、主要な保全チェック価値を提供するのに使用されます。 アルゴリズムは以下の通りです。
1. Compute a 20 octet SHA-1 [SHA1] message digest on the key that is
to be wrapped.
2. Use the most significant (first) eight octets of the message
digest value as the checksum value.
1. キーの上の包装されることになっている20八重奏SHA-1[SHA1]メッセージダイジェストを計算してください。 2. チェックサム値としてメッセージダイジェスト価値の最も重要な(最初に)8つの八重奏を使用してください。
3 Triple-DES Key Wrapping and Unwrapping
3 三重のDESの主要なラッピングと開けること
This section specifies the algorithms for wrapping and unwrapping one Triple-DES key with another Triple-DES key [3DES].
このセクションは別のTriple-DESキー[3DES]によって主要な1Triple-DESを包装して、開けるためのアルゴリズムを指定します。
The same key wrap algorithm is used for both Two-key Triple-DES and Three-key Triple-DES keys. When a Two-key Triple-DES key is to be wrapped, a third DES key with the same value as the first DES key is created. Thus, all wrapped Triple-DES keys include three DES keys. However, a Two-key Triple-DES key MUST NOT be used to wrap a Three- key Triple-DES key that is comprised of three unique DES keys.
同じ主要な包装アルゴリズムはTwo主要なTriple-DESとThree主要なTriple-DESキーの両方に使用されます。 Two主要なTriple-DESキーが包装されることになっているとき、最初のDESキーと同じ値のために主要な第3のDESは作成されます。 このようにしてすべて包装されたTriple-DESキーは3個のDESキーを含んでいます。 しかしながら、3個のユニークなDESキーから成るThreeの主要なTriple-DESキーを包装するのにTwo主要なTriple-DESキーを使用してはいけません。
3.1 Triple-DES Key Wrap
3.1 三重のDESの主要な包装
The Triple-DES key wrap algorithm encrypts a Triple-DES key with a Triple-DES key-encryption key. The Triple-DES key wrap algorithm is:
Triple-DESの主要な包装アルゴリズムはTriple-DES主要な暗号化キーによって主要なTriple-DESをコード化します。 Triple-DESの主要な包装アルゴリズムは以下の通りです。
1. Set odd parity for each of the DES key octets comprising the
Three-Key Triple-DES key that is to be wrapped, call the result
CEK.
2. Compute an 8 octet key checksum value on CEK as described above in
Section 2, call the result ICV.
3. Let CEKICV = CEK || ICV.
4. Generate 8 octets at random, call the result IV.
5. Encrypt CEKICV in CBC mode using the key-encryption key. Use the
random value generated in the previous step as the initialization
vector (IV). Call the ciphertext TEMP1.
6. Let TEMP2 = IV || TEMP1.
7. Reverse the order of the octets in TEMP2. That is, the most
significant (first) octet is swapped with the least significant
(last) octet, and so on. Call the result TEMP3.
8. Encrypt TEMP3 in CBC mode using the key-encryption key. Use an
initialization vector (IV) of 0x4adda22c79e82105. The ciphertext
is 40 octets long.
1. 包装されることになっているThree主要なTriple-DESキーを包括するそれぞれのDESの主要な八重奏に奇数パリティを設定してください、そして、CEKに結果に電話をしてください。 2. セクション2で上で説明されるようにCEKで8の八重奏の主要なチェックサム価値を計算してください、そして、ICVに結果に電話をしてください。 3. CEKICVにCEKと等しくしいさせてください。|| ICV。 4. 8つの八重奏を無作為に発生させてください、そして、結果IVに電話をしてください。 5. 主要な暗号化キーを使用して、CBCモードでCEKICVをコード化してください。 初期化ベクトル(IV)として前のステップで発生する無作為の値を使用してください。 TEMP1に暗号文に電話をしてください。 6. TEMP2にIVと等しくしいさせてください。|| TEMP1。 7. TEMP2での八重奏の注文を逆にしてください。 すなわち、最も重要な(最初に)八重奏は最も重要でない(最後)八重奏などで交換されます。 TEMP3に結果に電話をしてください。 8. 主要な暗号化キーを使用して、CBCモードでTEMP3をコード化してください。 0x4adda22c79e82105の初期化ベクトル(IV)を使用してください。 長い間、暗号文は40の八重奏です。
Housley Informational [Page 2] RFC 3217 Triple-DES and RC2 Key Wrapping December 2001
Housleyの情報[2ページ]のRFC3217の三重のDESとラッピング2001年12月に主要なRC2
Note: When the same Three-Key Triple-DES key is wrapped in different key-encryption keys, a fresh initialization vector (IV) must be generated for each invocation of the key wrap algorithm.
以下に注意してください。 同じThree主要なTriple-DESキーが異なった主要な暗号化キーで包装されるとき、新鮮な初期化ベクトル(IV)は主要な包装アルゴリズムの各実施のために発生しなければなりません。
3.2 Triple-DES Key Unwrap
3.2 三重のDESキーは開けられます。
The Triple-DES key unwrap algorithm decrypts a Triple-DES key using a Triple-DES key-encryption key. The Triple-DES key unwrap algorithm is:
Triple-DESキーはアルゴリズムを開けます。Triple-DES主要な暗号化キーを使用することでTriple-DESキーを解読します。 Triple-DESキーは開けられます。アルゴリズムは以下の通りです。
1. If the wrapped key is not 40 octets, then error.
2. Decrypt the wrapped key in CBC mode using the key-encryption key.
Use an initialization vector (IV) of 0x4adda22c79e82105. Call the
output TEMP3.
3. Reverse the order of the octets in TEMP3. That is, the most
significant (first) octet is swapped with the least significant
(last) octet, and so on. Call the result TEMP2.
4. Decompose TEMP2 into IV and TEMP1. IV is the most significant
(first) 8 octets, and TEMP1 is the least significant (last) 32
octets.
5. Decrypt TEMP1 in CBC mode using the key-encryption key. Use the
IV value from the previous step as the initialization vector.
Call the ciphertext CEKICV.
6. Decompose CEKICV into CEK and ICV. CEK is the most significant
(first) 24 octets, and ICV is the least significant (last) 8
octets.
7. Compute an 8 octet key checksum value on CEK as described above in
Section 2. If the computed key checksum value does not match the
decrypted key checksum value, ICV, then error.
8. Check for odd parity each of the DES key octets comprising CEK.
If parity is incorrect, then error.
9. Use CEK as a Triple-DES key.
1. 包装されたキーが40の八重奏でないなら、そして、誤りです。 2. 主要な暗号化キーを使用して、CBCモードで包装されたキーを解読してください。 0x4adda22c79e82105の初期化ベクトル(IV)を使用してください。 TEMP3に出力に電話をしてください。 3. TEMP3での八重奏の注文を逆にしてください。 すなわち、最も重要な(最初に)八重奏は最も重要でない(最後)八重奏などで交換されます。 TEMP2に結果に電話をしてください。 4. IVとTEMP1にTEMP2を分解してください。 IVは最も重要な(最初に)8つの八重奏です、そして、TEMP1は最も重要でない(最後)32の八重奏です。 5. 主要な暗号化キーを使用して、CBCモードでTEMP1を解読してください。 初期化ベクトルとして前のステップからIV値を使用してください。 CEKICVに暗号文に電話をしてください。 6. CEKとICVにCEKICVを分解してください。 CEKは最も重要な(最初に)24の八重奏です、そして、ICVは最も重要でない(最後)8つの八重奏です。 7. セクション2で上で説明されるようにCEKで8の八重奏の主要なチェックサム価値を計算してください。 計算された主要なチェックサム値が解読された主要なチェックサム値、ICVに合っていないなら、そして、誤りです。 8. 奇数パリティがないかどうかCEKを包括するそれぞれのDESの主要な八重奏をチェックしてください。 同等が不正確であるなら、そして、誤りです。 9. Triple-DESキーとしてCEKを使用してください。
3.3 Triple-DES Key Wrap Algorithm Identifier
3.3 三重のDESの主要な包装アルゴリズム識別子
Some security protocols employ ASN.1 [X.208-88, X.209-88], and these protocols employ algorithm identifiers to name cryptographic algorithms. To support these protocols, the Triple-DES key wrap algorithm has been assigned the following algorithm identifier:
いくつかのセキュリティプロトコルがASN.1[X.208-88、X.209-88]を使います、そして、これらのプロトコルは暗号アルゴリズムを命名するのにアルゴリズム識別子を使います。これらのプロトコルをサポートするために、Triple-DESの主要な包装アルゴリズムに以下のアルゴリズム識別子を割り当ててあります:
id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 6 }
イド-alg-CMS3DESwrap物の識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3)6をメンバーと同じくらい具体化させます。
The AlgorithmIdentifier parameter field MUST be NULL.
AlgorithmIdentifierパラメタ分野はNULLであるに違いありません。
Housley Informational [Page 3] RFC 3217 Triple-DES and RC2 Key Wrapping December 2001
Housleyの情報[3ページ]のRFC3217の三重のDESとラッピング2001年12月に主要なRC2
3.4 Triple-DES Key Wrap Example
3.4 三重のDESの主要な包装の例
This section contains a Triple-DES Key Wrap example. Intermediate values corresponding to the named items in section 3.1 are given in hexadecimal.
このセクションはTriple-DES Key Wrapの例を含みます。 16進でセクション3.1で命名された項目に対応する中間的値を与えます。
CEK: 2923 bf85 e06d d6ae 5291 49f1 f1ba e9ea b3a7 da3d 860d 3e98
KEK: 255e 0d1c 07b6 46df b313 4cc8 43ba 8aa7 1f02 5b7c 0838 251f
ICV: 181b 7e96 86e0 4a4e
CEKICV: 2923 bf85 e06d d6ae 5291 49f1 f1ba e9ea b3a7 da3d 860d 3e98
181b 7e96 86e0 4a4e
IV: 5dd4 cbfc 96f5 453b
TEMP1: cfc1 a789 c675 dd2a b49a 3204 ef92 cc03 5c1f 973b 7a79 60f6
a44d cc5f 729d 8449
TEMP2: 5dd4 cbfc 96f5 453b cfc1 a789 c675 dd2a b49a 3204 ef92 cc03
5c1f 973b 7a79 60f6 a44d cc5f 729d 8449
TEMP3: 4984 9d72 5fcc 4da4 f660 797a 3b97 1f5c 03cc 92ef 0432 9ab4
2add 75c6 89a7 c1cf 3b45 f596 fccb d45d
RESULT: 6901 0761 8ef0 92b3 b48c a179 6b23 4ae9 fa33 ebb4 1596 0403
7db5 d6a8 4eb3 aac2 768c 6327 75a4 67d4
CEK: 2923bf85 e06d d6ae 5291 49f1 f1ba e9ea b3a7 da3d 860d 3e98 KEK: 255e 0d1c 07b6 46df b313 4cc8 43ba 8aa7 1f02 5b7c0838 251f ICV: 181b 7e96 86e0 4a4e CEKICV: 2923bf85 e06d d6ae 5291 49f1 f1ba e9ea b3a7da3d 860d 3e98 181b 7e96 86e0 4a4e IV: 5dd4 cbfc 96f5 453b TEMP1: cfc1 a789 c675 dd2a b49a3204ef92 cc03 5c1f 973b 7a79 60f6 a44d cc5f 729d8449TEMP2: 5dd4 cbfc 96f5 453b cfc1 a789 c675 dd2a b49a3204ef92 cc03 5c1f 973b 7a79 60f6 a44d cc5f 729d8449TEMP3: 4984 03ccの9d72 5fcc 4da4 f660 797a 3b97 1f5c92ef0432 9ab4 2add 75c6 89a7 c1cf 3b45 f596 fccb d45d RESULT: 6901 0761 8ef0 92b3 b48c a179 6b23 4ae9 fa33 ebb4 1596 0403 7db5 d6a8 4eb3 aac2 768c 6327 75a4 67d4
4 RC2 Key Wrapping and Unwrapping
4のRC2の主要なラッピングと開けること
This section specifies the algorithms for wrapping and unwrapping one RC2 key with another RC2 key [RC2].
このセクションは別のRC2キー[RC2]によって主要な1RC2を包装して、開けるためのアルゴリズムを指定します。
RC2 supports variable length keys. RC2 128-bit keys MUST be used as key-encryption keys; however, the wrapped RC2 key MAY be of any size.
RC2は可変長キーを支えます。 主要な暗号化キーとしてRC2の128ビットのキーを使用しなければなりません。 しかしながら、包装されたRC2キーはどんなサイズのものであるかもしれません。
4.1 RC2 Key Wrap
4.1 RC2の主要な包装
The RC2 key wrap algorithm encrypts a RC2 key with a RC2 key- encryption key. The RC2 key wrap algorithm is:
RC2の主要な包装アルゴリズムはRC2の主要な暗号化キーによって主要なRC2をコード化します。 RC2の主要な包装アルゴリズムは以下の通りです。
1. Let the RC2 key be called CEK, and let the length of CEK in
octets be called LENGTH. LENGTH is a single octet.
2. Let LCEK = LENGTH || CEK.
3. Let LCEKPAD = LCEK || PAD. If the length of LCEK is a multiple
of 8, the PAD has a length of zero. If the length of LCEK is not
a multiple of 8, then PAD contains the fewest number of random
octets to make the length of LCEKPAD a multiple of 8.
4. Compute an 8 octet key checksum value on LCEKPAD as described
above in Section 2, call the result ICV.
5. Let LCEKPADICV = LCEKPAD || ICV.
6. Generate 8 octets at random, call the result IV.
7. Encrypt LCEKPADICV in CBC mode using the key-encryption key. Use
the random value generated in the previous step as the
initialization vector (IV). Call the ciphertext TEMP1.
1. RC2キーをCEKと呼ばせてください、そして、八重奏における、CEKの長さをLENGTHと呼ばせてください。 LENGTHはただ一つの八重奏です。 2. LCEKに長さと等しくしいさせてください。|| CEK。 3. LCEKPADにLCEKと等しくしいさせてください。|| そっと歩いてください。 LCEKの長さが8の倍数であるなら、PADには、ゼロの長さがあります。 LCEKの長さが8の倍数でないなら、PADはLCEKPADの長さを8の倍数にする最も数数の無作為の八重奏を含んでいます。 4. セクション2で上で説明されるようにLCEKPADで8の八重奏の主要なチェックサム価値を計算してください、そして、ICVに結果に電話をしてください。 5. LCEKPADICVにLCEKPADと等しくしいさせてください。|| ICV。 6. 8つの八重奏を無作為に発生させてください、そして、結果IVに電話をしてください。 7. 主要な暗号化キーを使用して、CBCモードでLCEKPADICVをコード化してください。 初期化ベクトル(IV)として前のステップで発生する無作為の値を使用してください。 TEMP1に暗号文に電話をしてください。
Housley Informational [Page 4] RFC 3217 Triple-DES and RC2 Key Wrapping December 2001
Housleyの情報[4ページ]のRFC3217の三重のDESとラッピング2001年12月に主要なRC2
8. Let TEMP2 = IV || TEMP1.
9. Reverse the order of the octets in TEMP2. That is, the most
significant (first) octet is swapped with the least significant
(last) octet, and so on. Call the result TEMP3.
10. Encrypt TEMP3 in CBC mode using the key-encryption key. Use an
initialization vector (IV) of 0x4adda22c79e82105.
8. TEMP2にIVと等しくしいさせてください。|| TEMP1。 9. TEMP2での八重奏の注文を逆にしてください。 すなわち、最も重要な(最初に)八重奏は最も重要でない(最後)八重奏などで交換されます。 TEMP3に結果に電話をしてください。 10. 主要な暗号化キーを使用して、CBCモードでTEMP3をコード化してください。 0x4adda22c79e82105の初期化ベクトル(IV)を使用してください。
Note: When the same RC2 key is wrapped in different key-encryption keys, a fresh initialization vector (IV) must be generated for each invocation of the key wrap algorithm.
以下に注意してください。 同じRC2キーが異なった主要な暗号化キーで包装されるとき、新鮮な初期化ベクトル(IV)は主要な包装アルゴリズムの各実施のために発生しなければなりません。
4.2 RC2 Key Unwrap
4.2RC2キーは開けられます。
The RC2 key unwrap algorithm decrypts a RC2 key using a RC2 key- encryption key. The RC2 key unwrap algorithm is:
RC2キーは開けられます。アルゴリズムは、RC2がキーであるとRC2の主要な暗号化キーを使用することで解読します。 RC2キーは開けられます。アルゴリズムは以下の通りです。
1. If the wrapped key is not a multiple of 8 octets, then error.
2. Decrypt the wrapped key in CBC mode using the key-encryption key.
Use an initialization vector (IV) of 0x4adda22c79e82105. Call
the output TEMP3.
3. Reverse the order of the octets in TEMP3. That is, the most
significant (first) octet is swapped with the least significant
(last) octet, and so on. Call the result TEMP2.
4. Decompose the TEMP2 into IV and TEMP1. IV is the most
significant (first) 8 octets, and TEMP1 is the remaining octets.
5. Decrypt TEMP1 in CBC mode using the key-encryption key. Use the
IV value from the previous step as the initialization vector.
Call the plaintext LCEKPADICV.
6. Decompose the LCEKPADICV into LCEKPAD, and ICV. ICV is the least
significant (last) octet 8 octets. LCEKPAD is the remaining
octets.
7. Compute an 8 octet key checksum value on LCEKPAD as described
above in Section 2. If the computed key checksum value does not
match the decrypted key checksum value, ICV, then error.
8. Decompose the LCEKPAD into LENGTH, CEK, and PAD. LENGTH is the
most significant (first) octet. CEK is the following LENGTH
octets. PAD is the remaining octets, if any.
9. If the length of PAD is more than 7 octets, then error.
10. Use CEK as an RC2 key.
1. 包装されたキーが8つの八重奏の倍数でないなら、そして、誤りです。 2. 主要な暗号化キーを使用して、CBCモードで包装されたキーを解読してください。 0x4adda22c79e82105の初期化ベクトル(IV)を使用してください。 TEMP3に出力に電話をしてください。 3. TEMP3での八重奏の注文を逆にしてください。 すなわち、最も重要な(最初に)八重奏は最も重要でない(最後)八重奏などで交換されます。 TEMP2に結果に電話をしてください。 4. IVとTEMP1にTEMP2を分解してください。 IVは最も重要な(最初に)8つの八重奏です、そして、TEMP1は残っている八重奏です。 5. 主要な暗号化キーを使用して、CBCモードでTEMP1を解読してください。 初期化ベクトルとして前のステップからIV値を使用してください。 LCEKPADICVに平文に電話をしてください。 6. LCEKPAD、およびICVにLCEKPADICVを分解してください。 ICVは最も重要でない(最後)八重奏8八重奏です。 LCEKPADは残っている八重奏です。 7. セクション2で上で説明されるようにLCEKPADで8の八重奏の主要なチェックサム価値を計算してください。 計算された主要なチェックサム値が解読された主要なチェックサム値、ICVに合っていないなら、そして、誤りです。 8. 長さ、CEK、およびパッドにLCEKPADを分解してください。 LENGTHは最も重要な(最初に)八重奏です。 CEKは以下のLENGTH八重奏です。 PADはもしあれば残っている八重奏です。 9. PADの長さが7つ以上の八重奏であるなら、そして、誤りです。 10. RC2キーとしてCEKを使用してください。
4.3 RC2 Key Wrap Algorithm Identifier
4.3 RC2の主要な包装アルゴリズム識別子
Some security protocols employ ASN.1 [X.208-88, X.209-88], and these protocols employ algorithm identifiers to name cryptographic algorithms. To support these protocols, the RC2 key wrap algorithm has been assigned the following algorithm identifier:
いくつかのセキュリティプロトコルがASN.1[X.208-88、X.209-88]を使います、そして、これらのプロトコルは暗号アルゴリズムを命名するのにアルゴリズム識別子を使います。これらのプロトコルをサポートするために、RC2の主要な包装アルゴリズムに以下のアルゴリズム識別子を割り当ててあります:
Housley Informational [Page 5] RFC 3217 Triple-DES and RC2 Key Wrapping December 2001
Housleyの情報[5ページ]のRFC3217の三重のDESとラッピング2001年12月に主要なRC2
id-alg-CMSRC2wrap OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 7 }
イド-alg-CMSRC2wrap物の識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3)7をメンバーと同じくらい具体化させます。
The AlgorithmIdentifier parameter field MUST be RC2wrapParameter:
AlgorithmIdentifierパラメタ分野はRC2wrapParameterであるに違いありません:
RC2wrapParameter ::= RC2ParameterVersion
RC2wrapParameter:、:= RC2ParameterVersion
RC2ParameterVersion ::= INTEGER
RC2ParameterVersion:、:= 整数
The RC2 effective-key-bits (key size) greater than 32 and less than 256 is encoded in the RC2ParameterVersion. For the effective-key- bits of 40, 64, and 128, the rc2ParameterVersion values are 160, 120, and 58 respectively. These values are not simply the RC2 key length. Note that the value 160 must be encoded as two octets (00 A0), because the one octet (A0) encoding represents a negative number.
32以上の(主要なサイズ)と256RC2有効なキービットはRC2ParameterVersionでコード化されます。 rc2ParameterVersion値は、それぞれ40、64、および128の有効に主要なビット単位で、160と、120と、58です。 これらの値は単にRC2キー長ではありません。 2つの八重奏(00A0)として値160をコード化しなければならないことに注意してください、1つの八重奏(A0)のコード化が負数を表すので。
4.4 RC2 Key Wrap Example
4.4 RC2の主要な包装の例
This section contains a RC2 Key Wrap example. Intermediate values corresponding to the named items in section 4.1 are given in hexadecimal.
このセクションはRC2 Key Wrapの例を含みます。 16進でセクション4.1で命名された項目に対応する中間的値を与えます。
CEK: b70a 25fb c9d8 6a86 050c e0d7 11ea d4d9
KEK: fd04 fd08 0607 07fb 0003 feff fd02 fe05
LENGTH: 10
LCEK: 10b7 0a25 fbc9 d86a 8605 0ce0 d711 ead4 d9
PAD: 4845 cce7 fd12 50
LCEKPAD: 10b7 0a25 fbc9 d86a 8605 0ce0 d711 ead4
d948 45cc e7fd 1250
ICV: 0a6f f19f db40 4988
LCEKPADICV: 10b7 0a25 fbc9 d86a 8605 0ce0 d711 ead4
d948 45cc e7fd 1250 0a6f f19f db40 4988
IV: c7d9 0059 b29e 97f7
TEMP1: a01d a259 3793 1260 e48c 55f5 04ce 70b8
ac8c d79e ffe8 9932 9fa9 8a07 a31f f7a7
TEMP2: c7d9 0059 b29e 97f7 a01d a259 3793 1260
e48c 55f5 04ce 70b8 ac8c d79e ffe8 9932
9fa9 8a07 a31f f7a7
TEMP3: a7f7 1fa3 078a a99f 3299 8eff 9ed7 8cac
b870 ce04 f555 8ce4 6012 9337 59a2 1da0
f797 9eb2 5900 d9c7
RESULT: 70e6 99fb 5701 f783 3330 fb71 e87c 85a4
20bd c99a f05d 22af 5a0e 48d3 5f31 3898
6cba afb4 b28d 4f35
CEK: b70a 25fb c9d8 6a86 050c e0d7 11ea d4d9 KEK: fd04 fd08 0607 07fb0003feff fd02 fe05 LENGTH: 10LCEK: 10b7 0a25 fbc9 d86a8605 0ce0 d711 ead4 d9 PAD: 4845cce7 fd12 50 LCEKPAD: 45ccの10b7 0a25 fbc9 d86a8605 0ce0 d711 ead4 d948e7fd1250ICV: 0a6f f19f db40 4988 LCEKPADICV: 45ccの10b7 0a25 fbc9 d86a8605 0ce0 d711 ead4 d948e7fd1250 0a6f f19f db40 4988IV: c7d9 0059b29e 97f7 TEMP1: a01d a259 3793 1260e48c 55f5 04ce 70b8 ac8c d79e ffe8 9932 9fa9 8a07 a31f f7a7 TEMP2: c7d9 0059b29e 97f7 a01d a259 3793 1260e48c 55f5 04ce 70b8 ac8c d79e ffe8 9932 9fa9 8a07 a31f f7a7 TEMP3: a7f7 1fa3 078a a99f3299 8eff 9ed7 8cac b870 ce04 f555 8ce4 6012 9337 59a2 1da0 f797 9eb2 5900d9c7 RESULT: 70e6 99fb5701f783 3330fb71 e87c 85a4 20bd c99a f05d 22af5a0e 48d3 5f31 3898 6cba afb4 b28d 4f35
Housley Informational [Page 6] RFC 3217 Triple-DES and RC2 Key Wrapping December 2001
Housleyの情報[6ページ]のRFC3217の三重のDESとラッピング2001年12月に主要なRC2
5 References
5つの参照箇所
[3DES] American National Standards Institute. ANSI X9.52-1998,
Triple Data Encryption Algorithm Modes of Operation.
1998.
[3DES]American National Standards Institut。 ANSI X9.52-1998、データ暗号化アルゴリズム運転モードを3倍にしてください。 1998.
[CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630,
June 1999.
[cm] Housley、R.、「暗号のメッセージ構文」、RFC2630、1999年6月。
[DES] American National Standards Institute. ANSI X3.106,
"American National Standard for Information Systems - Data
Link Encryption". 1983.
[DES]American National Standards Institut。 ANSI X3.106、「情報システムのための米国標準規格--データは暗号化をリンクします」。 1983.
[DH-X9.42] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC
2631, June 1999.
[DH-X9.42] レスコラ、E.、「ディフィー-ヘルマンの主要な協定方法」、RFC2631、1999年6月。
[DSS] National Institute of Standards and Technology. FIPS Pub
186: Digital Signature Standard. 19 May 1994.
[DSS]米国商務省標準技術局。 FIPSパブ186: デジタル署名基準。 1994年5月19日。
[MODES] National Institute of Standards and Technology. FIPS Pub
81: DES Modes of Operation. 2 December 1980.
[モード]米国商務省標準技術局。 FIPSパブ81: DES運転モード。 1980年12月2日。
[RANDOM] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994.
[無作為の] イーストレークとD.とクロッカーとS.とJ.シラー、「セキュリティのための偶発性推薦」、RFC1750、1994年12月。
[RC2] Rivest, R., "A Description of the RC2 (r) Encryption
Algorithm", RFC 2268, March 1998.
[RC2] Rivest、R.、「RC2(r)暗号化アルゴリズムの記述」、RFC2268、1998年3月。
[SHA1] National Institute of Standards and Technology. FIPS Pub
180-1: Secure Hash Standard. 17 April 1995.
[SHA1]米国商務省標準技術局。 FIPSパブ180-1: 細切れ肉料理規格を保証してください。 1995年4月17日。
[STDWORDS] Bradner, S., "Key Words for Use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[STDWORDS]ブラドナー、S.、「使用のための要件レベルを示すRFCsのキーワード」、BCP14、RFC2119、1997年3月。
[X.208-88] CCITT. Recommendation X.208: Specification of Abstract
Syntax Notation One (ASN.1). 1988.
[X.208-88]CCITT。 推薦X.208: 抽象構文記法1(ASN.1)の仕様。 1988.
[X.209-88] CCITT. Recommendation X.209: Specification of Basic
Encoding Rules for Abstract Syntax Notation One (ASN.1).
1988.
[X.209-88]CCITT。 推薦X.209: 基本的なコード化の仕様は抽象構文記法1(ASN.1)のために統治されます。 1988.
Housley Informational [Page 7] RFC 3217 Triple-DES and RC2 Key Wrapping December 2001
Housleyの情報[7ページ]のRFC3217の三重のDESとラッピング2001年12月に主要なRC2
6 Security Considerations
6 セキュリティ問題
Implementations must protect the key-encryption key. Compromise of the key-encryption key may result in the disclosure of all keys that have been wrapped with the key-encryption key, which may lead to the disclosure of all traffic protected with those wrapped key.
実現は主要な暗号化キーを保護しなければなりません。 主要な暗号化キーの妥協はそれらが主要な状態で包装されている状態で保護されたすべての交通の公開に通じるかもしれない主要な暗号化キーで包装されたすべてのキーの公開をもたらすかもしれません。
Implementations must randomly generate initialization vectors (IVs) and padding. The generation of quality random numbers is difficult. RFC 1750 [RANDOM] offers important guidance in this area, and Appendix 3 of FIPS Pub 186 [DSS] provides one quality PRNG technique.
実現は初期化ベクトル(IVs)と詰め物を手当たりしだいに発生させなければなりません。 上質の乱数の世代は難しいです。 RFC1750[RANDOM]はこの領域で重要な指導を提供します、そして、FIPS Pub186[DSS]のAppendix3は1つの上質のPRNGのテクニックを提供します。
If the key-encryption key and wrapped key are associated with different symmetric encryption algorithms, the effective security provided to data encrypted with the wrapped key is determined by the weaker of the two algorithms. If, for example, data is encrypted with 168-bit Triple-DES and that Triple-DES key is wrapped with a 40-bit RC2 key, then at most 40 bits of protection is provided. A trivial search to determine the value of the 40-bit RC2 key can recover Triple-DES key, and then the Triple-DES key can be used to decrypt the content. Therefore, implementers must ensure that key- encryption algorithms are as strong or stronger than content- encryption algorithms.
主要な暗号化の主要で包装されたキーが異なった左右対称の暗号化アルゴリズムに関連しているなら、包装されたキーでコード化されたデータに提供された有効なセキュリティは2つのアルゴリズムについて、より弱いことで決定します。例えば、データが168ビットのTriple-DESと共にコード化されて、そのTriple-DESキーが40ビットのRC2キーで包装されるなら、高々保護の40ビットしか提供されません。 内容を解読するのに40ビットのRC2キーの値はTriple-DESキーを回収して、次に、Triple-DESキーを回収できることを決定する些細な検索を使用できます。 したがって、implementersは主要な暗号化アルゴリズムが確実に同じくらい強いか内容暗号化アルゴリズムより強くなるようにしなければなりません。
These key wrap algorithms specified in this document have been reviewed for use with Triple-DES and RC2, and they have not been reviewed for use with other encryption algorithms. Similarly, the key wrap algorithms make use of CBC mode [MODES], and they have not been reviewed for use with other cryptographic modes.
本書では指定されたこれらの主要な包装アルゴリズムはTriple-DESとRC2との使用のために見直されました、そして、使用のために他の暗号化アルゴリズムで見直されていません。同様に、主要な包装アルゴリズムはCBCモード[MODES]を利用します、そして、彼らは使用のために他の暗号のモードで見直されていません。
7 Acknowledgments
7つの承認
This document is the result of contributions from many professionals. I appreciate the hard work of all members of the IETF S/MIME Working Group. I extend a special thanks to Carl Ellison, Peter Gutmann, Bob Jueneman, Don Johnson, Burt Kaliski, John Pawling, and Jim Schaad for their support in defining these algorithms and generating this specification.
このドキュメントは多くの専門家からの貢献の結果です。 私はIETF S/MIME作業部会のすべてのメンバーのきつい仕事に感謝します。 カール・エリソン、ピーター・ガットマン、ボブJueneman、ドン・ジョンソン、バートKaliski、ジョンPawling、およびジムSchaadのおかげで私は彼らのサポートのためにこれらのアルゴリズムを定義して、この仕様を発生させる際に特別番組を広げます。
8 Author Address
8 作者アドレス
Russell Housley RSA Laboratories 918 Spring Knoll Drive Herndon, VA 20170 USA
ラッセルHousley RSA研究所918は小山Driveヴァージニア20170ハーンドン(米国)を跳ばせます。
EMail: rhousley@rsasecurity.com
メール: rhousley@rsasecurity.com
Housley Informational [Page 8] RFC 3217 Triple-DES and RC2 Key Wrapping December 2001
Housleyの情報[8ページ]のRFC3217の三重のDESとラッピング2001年12月に主要なRC2
9 Full Copyright Statement
9 完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Housley Informational [Page 9]
Housley情報です。[9ページ]
一覧
スポンサーリンク
