RFC3211 日本語訳
3211 Password-based Encryption for CMS. P. Gutmann. December 2001. (Format: TXT=30527 bytes) (Obsoleted by RFC3369, RFC3370) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group P. Gutmann Request for Comments: 3211 University of Auckland Category: Standards Track December 2001
コメントを求めるワーキンググループP.ガットマン要求をネットワークでつないでください: 3211年のオークランド大学カテゴリ: 標準化過程2001年12月
Password-based Encryption for CMS
cmのためのパスワードベースの暗号化
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 (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
Abstract
要約
This document provides a method of encrypting data using user- supplied passwords and, by extension, any form of variable-length keying material which is not necessarily an algorithm-specific fixed-format key. The Cryptographic Message Syntax data format does not currently contain any provisions for password-based data encryption.
このドキュメントは必ずアルゴリズム特有の固定フォーマットキーであるというわけではないユーザの与えられたパスワードを使用することでデータをコード化する方法と拡大によるどんな形式の可変長の合わせることの材料も供給します。 Cryptographic Message Syntaxデータの形式は現在、パスワードベースのデータ暗号化のためのどんな条項も含みません。
1. Introduction
1. 序論
This document describes a password-based content encryption mechanism for CMS. This is implemented as a new RecipientInfo type and is an extension to the RecipientInfo types currently defined in RFC 2630.
このドキュメントはCMSのためにパスワードベースの満足している暗号化メカニズムについて説明します。これは、新しいRecipientInfoタイプとして実行されて、現在RFC2630で定義されているRecipientInfoタイプへの拡大です。
The format of the messages are described in ASN.1 [ASN1].
メッセージの形式はASN.1[ASN1]で説明されます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
キーワード“MUST"、「必須NOT」が「必要です」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119で説明されるように本書では解釈されることであるべきです。
Gutmann Standards Track [Page 1] RFC 3211 Password-based Encryption for CMS December 2001
ガットマンStandardsはcm2001年12月にRFC3211のパスワードベースの暗号化を追跡します[1ページ]。
1.1 Password-based Content Encryption
1.1 パスワードベースの満足している暗号化
CMS currently defined three recipient information types for public- key key wrapping (KeyTransRecipientInfo), conventional key wrapping (KEKRecipientInfo), and key agreement (KeyAgreeRecipientInfo). The recipient information described here adds a fourth type, PasswordRecipientInfo, which provides for password-based key wrapping.
CMSは現在、公共の主要な主要なラッピング(KeyTransRecipientInfo)、従来の主要なラッピング(KEKRecipientInfo)、および主要な協定(KeyAgreeRecipientInfo)のための3つの受取人情報タイプを定義しました。 ここで説明された受取人情報は4番目のタイプ、PasswordRecipientInfoを加えます。(PasswordRecipientInfoはパスワードベースの主要なラッピングに備えます)。
1.2 RecipientInfo Types
1.2 RecipientInfoはタイプします。
The new recipient information type is an extension to the RecipientInfo type defined in section 6.2 of CMS, extending the types to:
新しい受取人情報タイプはCMSのセクション6.2で定義されたRecipientInfoタイプへの拡大です、以下のことのためにタイプを広げていて
RecipientInfo ::= CHOICE {
ktri KeyTransRecipientInfo,
kari [1] KeyAgreeRecipientInfo,
kekri [2] KEKRecipientInfo,
pwri [3] PasswordRecipientinfo -- New RecipientInfo type
}
RecipientInfo:、:= 選択ktri KeyTransRecipientInfo(kari[1]KeyAgreeRecipientInfo)は[2]KEKRecipientInfo、pwri[3]PasswordRecipientinfoをkekriします--新しいRecipientInfoはタイプします。
Although the recipient information generation process is described in terms of a password-based operation (since this will be its most common use), the transformation employed is a general-purpose key derivation one which allows any type of keying material to be converted into a key specific to a particular content-encryption algorithm. Since the most common use for password-based encryption is to encrypt files which are stored locally (rather than being transmitted across a network), the term "recipient" is somewhat misleading, but is used here because the other key transport mechanisms have always been described in similar terms.
受取人情報発生経過はパスワードベースの操作で説明されますが(これが最も一般的な使い方になるので)、使われた変化はどんなタイプについても材料を合わせるのが特定の満足している暗号化アルゴリズムに特定のキーに変換されるのを許容する汎用の主要な派生1です。 パスワードベースの暗号化の最も一般の使用が局所的(ネットワークの向こう側に伝えられるよりむしろ)に格納されるファイルをコード化することであるときに、「受取人」という用語は、いくらか紛らわしいのですが、他の主要な移送機構が同類項でいつも説明されるので、ここで使用されます。
1.2.1 PasswordRecipientInfo Type
1.2.1 PasswordRecipientInfoはタイプします。
Recipient information using a user-supplied password or previously agreed-upon key is represented in the type PasswordRecipientInfo. Each instance of PasswordRecipientInfo will transfer the content- encryption key (CEK) to one or more recipients who have the previously agreed-upon password or key-encryption key (KEK).
ユーザによって与えられたパスワードか以前に同意しているキーを使用する受取人情報がタイプPasswordRecipientInfoで表されます。 PasswordRecipientInfoの各例は内容の暗号化の以前に同意しているパスワードか主要な暗号化を持っている1人以上の受取人にとって、主要な(CEK)キー(KEK)を移すでしょう。
PasswordRecipientInfo ::= SEQUENCE {
version CMSVersion, -- Always set to 0
keyDerivationAlgorithm
[0] KeyDerivationAlgorithmIdentifier OPTIONAL,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey }
PasswordRecipientInfo:、:= 系列バージョンCMSVersion--いつも0keyDerivationAlgorithm[0]KeyDerivationAlgorithmIdentifier OPTIONAL、keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier、encryptedKey EncryptedKeyにセットしてください。
Gutmann Standards Track [Page 2] RFC 3211 Password-based Encryption for CMS December 2001
ガットマンStandardsはcm2001年12月にRFC3211のパスワードベースの暗号化を追跡します[2ページ]。
The fields of type PasswordRecipientInfo have the following meanings:
タイプPasswordRecipientInfoの分野には、以下の意味があります:
version is the syntax version number. It MUST be 0. Details of
the CMSVersion type are discussed in CMS [RFC2630], section
10.2.5.
バージョンは構文バージョン番号です。 それは0であるに違いありません。 CMS[RFC2630]、セクション10.2.5でCMSVersionタイプの細部について議論します。
keyDerivationAlgorithm identifies the key-derivation algorithm,
and any associated parameters, used to derive the KEK from the
user-supplied password. If this field is absent, the KEK is
supplied from an external source, for example a crypto token such
as a smart card.
keyDerivationAlgorithmは主要な誘導アルゴリズム、およびユーザによって与えられたパスワードからKEKを得るのに使用されるどんな関連パラメタも特定します。 この分野が欠けるなら、外部電源(例えば、スマートカードなどの暗号象徴)からKEKを供給します。
keyEncryptionAlgorithm identifies the key-encryption algorithm,
and any associated parameters, used to encrypt the CEK with the
KEK.
keyEncryptionAlgorithmは主要な暗号化アルゴリズム、およびKEKと共にCEKをコード化するのに使用されるどんな関連パラメタも特定します。
encryptedKey is the result of encrypting the content-encryption
key with the KEK.
encryptedKeyはKEKによって主要な満足している暗号化をコード化するという結果です。
1.2.2 Rationale
1.2.2 原理
Password-based key wrapping is a two-stage process, a first stage in which a user-supplied password is converted into a KEK if required, and a second stage in which the KEK is used to encrypt a CEK. These two stages are identified by the two algorithm identifiers. Although the PKCS #5v2 standard [RFC2898] goes one step further to wrap these up into a single algorithm identifier, this design is particular to that standard and may not be applicable for other key wrapping mechanisms. For this reason the two steps are specified separately.
パスワードベースの主要なラッピングは、2ステージの過程と、必要なら、ユーザによって与えられたパスワードがKEKに変換される第一段階と、KEKがCEKをコード化するのに使用される2番目のステージです。 これらの2つのステージが2つのアルゴリズム識別子によって特定されます。 PKCS#5v2規格[RFC2898]は1ステップで包装に加えて行きますが、ただ一つのアルゴリズム識別子へのこれらであり、このデザインはその規格に特定です、そして、他の主要なラッピングメカニズムには適切でないかもしれません。この理由として、2ステップは別々に指定されます。
The current format doesn't provide any means of differentiating between multiple password recipient infos, which would occur for example if two passwords are used to encrypt the same data. Unfortunately there is a lack of existing practice in this area, since typical applications follow the model of encrypting data such as a file with a single password obtained from the user. Without any clear requirements, an appropriate multiple password mechanism would be difficult (perhaps impossible) to define at this time. If sufficient demand emerges then this may be addressed in a future version of this document, for example by adding an optional identification field of an appropriate form.
現在の形式は例えば2つのパスワードが同じデータをコード化するのに使用されるなら現れるだろう複数のパスワード受取人インフォメーションを区別するどんな手段も提供しません。 残念ながら、既存の習慣の不足がこの領域にあります、主用途がユーザからただ一つのパスワードを得ているファイルなどのコード化データのモデルに従うので。 少しも明確な要件がなければ、適切な倍数パスワードメカニズムはこのとき定義するのが難しいでしょう(恐らく不可能な)。 これはこのドキュメントの将来のバージョンに記述されるかもしれません、十分な要求が現れるなら例えば、適切なフォームの任意の識別分野を加えることによって。
2 Supported Algorithms
2 支持されたアルゴリズム
This section lists the algorithms that must be implemented. Additional algorithms that should be implemented are also included.
このセクションは実行しなければならないアルゴリズムを記載します。 また、実行されるべきである追加アルゴリズムは含まれています。
Gutmann Standards Track [Page 3] RFC 3211 Password-based Encryption for CMS December 2001
ガットマンStandardsはcm2001年12月にRFC3211のパスワードベースの暗号化を追跡します[3ページ]。
2.1 Key Derivation Algorithms
2.1 主要な誘導アルゴリズム
These algorithms are used to convert the password into a KEK. The key derivation algorithms are:
これらのアルゴリズムは、パスワードをKEKに変換するのに使用されます。 主要な誘導アルゴリズムは以下の通りです。
KeyDerivationAlgorithmIdentifer ::= AlgorithmIdentifier
KeyDerivationAlgorithmIdentifer:、:= AlgorithmIdentifier
Conforming implementations MUST include PBKDF2 [RFC2898]. Appendix B contains a more precise definition of the allowed algorithm type than is possible using 1988 ASN.1.
実現を従わせると、PBKDF2[RFC2898]は包含しなければなりません。 付録Bは許容アルゴリズムタイプの可能な使用1988ASN.1より正確な定義を含んでいます。
2.2 Key Encryption Algorithms
2.2 主要な暗号化アルゴリズム
These algorithms are used to encrypt the CEK using the derived KEK. The key encryption algorithms are:
これらのアルゴリズムは、派生しているKEKを使用することでCEKをコード化するのに使用されます。 主要な暗号化アルゴリズムは以下の通りです。
KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier
KeyEncryptionAlgorithmIdentifier:、:= AlgorithmIdentifier
The PasswordRecipientInfo key encryption algorithm identifier is:
PasswordRecipientInfoの主要な暗号化アルゴリズム識別子は以下の通りです。
id-alg-PWRI-KEK OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 9 }
イド-alg-PWRI-KEK物の識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3)9をメンバーと同じくらい具体化させます。
The AlgorithmIdentifier parameters field for this algorithm contains the KEK encryption algorithm used with the the key wrap algorithm specified in section 2.3.
このアルゴリズムのためのAlgorithmIdentifierパラメタ分野はセクション2.3で指定される主要な包装アルゴリズムで使用されるKEK暗号化アルゴリズムを含んでいます。
There is no requirement that the CEK algorithm match the KEK encryption algorithm, although care should be taken to ensure that, if different algorithms are used, they offer an equivalent level of security (for example wrapping a Triple-DES key with an RC2/40 key leads to a severe impedance mismatch in encryption strength).
CEKアルゴリズムがKEK暗号化アルゴリズムに合っているという要件が全くありません、異なったアルゴリズムが使用されているなら同等なレベルのセキュリティを提供するのを保証するために注意するべきですが(例えば、RC2/40キーによって主要なTriple-DESを包装するのは暗号化の強さにおける厳しいインピーダンスミスマッチに通じます)。
Conforming implementations MUST implement the id-alg-PWRI-KEK key wrap algorithm. For the KEK encryption algorithms used by id-alg- PWRI-KEK, conforming implementations MUST include Triple-DES in CBC mode and MAY include other algorithms such as AES, CAST-128, RC5, IDEA, Skipjack, Blowfish, and encryption modes as required. Implementations SHOULD NOT include any KSG (keystream generator) ciphers such as RC4 or a block cipher in OFB mode, and SHOULD NOT include a block cipher in ECB mode.
実現を従わせると、イド-alg-PWRI-KEKの主要な包装アルゴリズムは実行されなければなりません。 イド-alg- PWRI-KEKによって使用されたKEK暗号化アルゴリズムのために、実現を従わせると、Triple-DESがCBCモードが包含しなければならなくて、AESや、キャスト-128や、RC5や、IDEAや、Skipjackや、Blowfishや、暗号化モードなどの他のアルゴリズムは必要に応じて包含するかもしれません。 実現SHOULD NOTはOFBモードにRC4かブロック暗号などのどんなKSG(keystreamジェネレータ)暗号も含んでいます、そして、SHOULD NOTはECBモードにブロック暗号を含んでいます。
2.2.1 Rationale
2.2.1 原理
The use of a level of indirection in specifying the KeyEncryptionAlgorithmIdentifier allows alternative wrapping algorithms to be used in the future. If the KEK algorithm were specified directly in this field then any use of an alternative
KeyEncryptionAlgorithmIdentifierを指定することにおける、間接指定のレベルの使用は、代替のラッピングアルゴリズムが将来使用されるのを許容します。 KEKアルゴリズムが直接これで指定されたなら、代替手段のあらゆる使用をさばいてください。
Gutmann Standards Track [Page 4] RFC 3211 Password-based Encryption for CMS December 2001
ガットマンStandardsはcm2001年12月にRFC3211のパスワードベースの暗号化を追跡します[4ページ]。
wrapping algorithm would require a change to the PasswordRecipientInfo structure rather than simply a change to the key encryption algorithm identifier.
ラッピングアルゴリズムはaが単に主要な暗号化アルゴリズム識別子に変化するよりむしろPasswordRecipientInfo構造への変化を必要とするでしょう。
The parameter field for this algorithm identifier could be specified to default to triple-DES, however due to the confusion over NULL vs absent parameters in algorithm identifiers it's left explicit with no default value.
三重のDESをデフォルトとするためにこのアルゴリズム識別子のためのパラメタ分野を指定できて、NULLの上の混乱によって、対アルゴリズム識別子の欠けているパラメタためしかしながら、それはデフォルト値なしで明白なままにされます。
2.3.1 Key Wrap
2.3.1 主要な包装
The key wrap algorithm encrypts a CEK with a KEK in a manner which ensures that every bit of plaintext effects every bit of ciphertext. This makes it equivalent in function to the package transform [PACKAGE] without requiring additional mechanisms or resources such as hash functions or cryptographically strong random numbers. The key wrap algorithm is performed in two phases, a first phase which formats the CEK into a form suitable for encryption by the KEK, and a second phase which wraps the formatted CEK using the KEK.
主要な包装アルゴリズムはKEKと共にちょうどちょうど暗号文の平文効果のものを確実にする方法でCEKをコード化します。 これは、それを追加メカニズムを必要とすることのないパッケージ変換[パッケージ]への機能における同等物にするか、または暗号で機能を論じ尽くすようなリソースを強い乱数にします。 主要な包装アルゴリズムは二相(KEK、およびKEKを使用することでフォーマットされたCEKを包装する2番目のフェーズで暗号化に適したフォームにCEKをフォーマットする第1段階)で実行されます。
Key formatting: Create a formatted CEK block consisting of the following:
主要な形式: 以下から成るフォーマットされたCEKブロックを作成してください:
1. A one-byte count of the number of bytes in the CEK.
1. CEKでのバイト数の1バイトのカウント。
2. A check value containing the bitwise complement of the first
three bytes of the CEK.
2. チェック値の含有、bitwiseする、CEKの最初の3バイトの補数。
3. The CEK.
3. CEK。
4. Enough random padding data to make the CEK data block a
multiple of the KEK block length and at least two KEK cipher
blocks long (the fact that 32 bits of count+check value are
used means that even with a 40-bit CEK, the resulting data size
will always be at least two (64-bit) cipher blocks long). The
padding data does not have to be cryptographically strong,
although unpredictability helps. Note that PKCS #5 padding is
not used, since the length of the data is already known.
4. CEKをデータにすることができるくらいの無作為の詰め物データはブロック長の、そして、少なくとも2つのKEK暗号長さブロックであるKEK(カウント+チェック価値の32ビットがいつも40ビットのCEK、結果として起こるデータサイズがあっても少なくとも2つ(64ビット)の暗号長さブロックになる中古の手段であるという事実)の倍数を妨げます。 詰め物データが暗号でそうである必要はない、強い、予測不可能性は助けますが。 データの長さが既に知られているので、PKCS#5詰め物が使用されていないことに注意してください。
The formatted CEK block then looks as follows:
次に、フォーマットされたCEKブロックは以下の通りに見えます:
CEK byte count || check value || CEK || padding (if required)
CEKバイト・カウント|| 値をチェックしてください。|| CEK|| 詰め物(必要なら)
Key wrapping:
主要なラッピング:
1. Encrypt the padded key using the KEK.
1. KEKを使用して、そっと歩いているキーをコード化してください。
Gutmann Standards Track [Page 5] RFC 3211 Password-based Encryption for CMS December 2001
ガットマンStandardsはcm2001年12月にRFC3211のパスワードベースの暗号化を追跡します[5ページ]。
2. Without resetting the IV (that is, using the last ciphertext
block as the IV), encrypt the encrypted padded key a second
time.
2. IV(すなわち、IVとして最後の暗号文ブロックを使用する)をリセットしないで、もう一度、コード化されたそっと歩いているキーをコード化してください。
The resulting double-encrypted data is the EncryptedKey.
結果として起こる二重にコード化されたデータはEncryptedKeyです。
2.3.2 Key Unwrap
2.3.2 キーは開けられます。
Key unwrapping:
キーの開けること:
1. Using the n-1'th ciphertext block as the IV, decrypt the n'th
ciphertext block.
1. n-1を使用する、'、暗号文が、IVとして妨げて、n'th暗号文ブロックであると第解読する、'
2. Using the decrypted n'th ciphertext block as the IV, decrypt
the 1st ... n-1'th ciphertext blocks. This strips the outer
layer of encryption.
2. IVとして解読されたn'th暗号文ブロックを使用して、最初の…n-1を解読してください、'、暗号文第ブロック、' これは外側の層から暗号化を奪い取ります。
3. Decrypt the inner layer of encryption using the KEK.
3. 内側の層の暗号化使用がKEKであると解読してください。
Key format verification:
主要な形式検証:
1a. If the CEK byte count is less than the minimum allowed key
size (usually 5 bytes for 40-bit keys) or greater than the
wrapped CEK length or not valid for the CEK algorithm (eg not
16 or 24 bytes for triple DES), the KEK was invalid.
1a。 CEKアルゴリズム(三重のDESのための16バイトか24バイトではなく、eg)には、CEKバイト・カウントが最小限が主要なサイズ(40ビットのキーのための通常5バイト)を許容したより少ないか包装されたCEKの長さより大きいか有効でないなら、KEKは無効でした。
1b. If the bitwise complement of the key check value doesn't match
the first three bytes of the key, the KEK was invalid.
1b。 bitwiseする、主要なチェック価値の補数はキーの最初の3バイトに合わないで、KEKは無効でした。
2.3.3 Example
2.3.3 例
Given a content-encryption algorithm of Skipjack and a KEK algorithm of Triple-DES, the wrap steps are as follows:
Skipjackの満足している暗号化アルゴリズムとTriple-DESのKEKアルゴリズムを考えて、包装ステップは以下の通りです:
1. Set the first 4 bytes of the CEK block to the Skipjack key size
(10 bytes) and the bitwise complement of the first three bytes
of the CEK.
1. そして、Skipjackの主要なサイズ(10バイト)にCEKブロックの最初の4バイトを設定してください、bitwiseする、CEKの最初の3バイトの補数。
2. Append the 80-bit (10-byte) Skipjack CEK and pad the total to
16 bytes (two triple-DES blocks) using 2 bytes of random data.
2. 80ビット(10バイト)のトビウオの類CEKを追加してください、そして、2バイトの無作為のデータを使用することで16バイト(2つの三重のDESブロック)に合計を水増ししてください。
2. Using the IV given in the KeyEncryptionAlgorithmIdentifer,
encrypted the padded Skipjack key.
2. KeyEncryptionAlgorithmIdentiferであって、コード化にされるののそっと歩いているSkipjackキーを考えて、IVを使用します。
3. Without resetting the IV, encrypt the encrypted padded key a
second time.
3. IVをリセットしないで、もう一度、コード化されたそっと歩いているキーをコード化してください。
Gutmann Standards Track [Page 6] RFC 3211 Password-based Encryption for CMS December 2001
ガットマンStandardsはcm2001年12月にRFC3211のパスワードベースの暗号化を追跡します[6ページ]。
The unwrap steps are as follows:
開けてください。ステップは以下の通りです:
1. Using the first 8 bytes of the double-encrypted key as the IV,
decrypt the second 8 bytes.
1. IVとして二重にコード化されたキーの最初の8バイトを使用して、2番目の8バイトを解読してください。
2. Without resetting the IV, decrypt the first 8 bytes.
2. IVをリセットしないで、最初の8バイトを解読してください。
3. Decrypt the inner layer of encryption using the the IV given in
the KeyEncryptionAlgorithmIdentifer to recover the padded
Skipjack key.
3. 内側の層の暗号化使用がそっと歩いているSkipjackキーを回収するためにKeyEncryptionAlgorithmIdentiferで与えられたIVであると解読してください。
4. If the length byte isn't equal to the Skipjack key size (80
bits or 10 bytes) or the bitwise complement of the check bytes
doesn't match the first three bytes of the CEK, the KEK was
invalid.
4. または、長さのバイトがSkipjackの主要なサイズ(80ビットか10バイト)と等しくない、bitwiseする、チェックバイトの補数はCEKの最初の3バイトに合わないで、KEKは無効でした。
2.3.4 Rationale for the Double Wrapping
2.3.4 二重ラッピングのための原理
If many CEKs are encrypted in a standard way with the same KEK and the KEK has a 64-bit block size then after about 2^32 encryptions there is a high probability of a collision between different blocks of encrypted CEKs. If an opponent manages to obtain a CEK, they may be able to solve for other CEKs. The double-encryption wrapping process, which makes every bit of ciphertext dependent on every bit of the CEK, eliminates this collision problem (as well as preventing other potential problems such as bit-flipping attacks). Since the IV is applied to the inner layer of encryption, even wrapping the same CEK with the same KEK will result in a completely different wrapped key each time.
多くのCEKsが同じKEKと共に標準の方法でコード化されて、KEKに64ビットのブロック・サイズがあるなら、およそ2つの^32暗号化の後に、異なったブロックのコード化されたCEKsの間の衝突の高い確率があります。 相手が何とかCEKを入手するなら、彼らはもう一方のためにCEKsを解決できるかもしれません。 二重暗号化ラッピングの過程(暗号文のあらゆるビットをCEKのあらゆるビットに依存するようにする)はこの衝突問題(ビットをはじき出す攻撃などの他の潜在的な問題を防ぐことと同様に)を解決します。 IVが内側の層の暗号化に適用されるので、同じKEKと共に同じCEKを包装すると、完全に異なった包装されたキーはその都度、もたらされるでしょう。
An additional feature of the double wrapping is that it doesn't require the use of any extra algorithms such as hash algorithms in addition to the wrapping algorithm itself, allowing it to be implemented in devices which only support one type of encryption algorithm. A typical example of such a device is a crypto token such as a smart card which often only supports a single block cipher and a single public-key algorithm, making it impossible to wrap keys if the use of an additional algorithm were required.
二重ラッピングの付加的な機能はラッピングアルゴリズム自体に加えた細切れ肉料理アルゴリズムなどの余分などんなアルゴリズムの使用も必要としないということです、それがサポート1だけがタイプする暗号化アルゴリズムの装置で実行されるのを許容して。 そのような装置の典型的な例はしばしばただ一つのブロック暗号とただ一つの公開カギアルゴリズムをサポートするだけであるスマートカードなどの暗号象徴です、追加アルゴリズムの使用が必要であったならキーを包装するのを不可能にして。
3. Test Vectors
3. テストベクトル
This section contains two sets of test vectors, a very basic set for DES which can be used to verify correctness and which uses an algorithm which is freely exportable from the US, and a stress-test version which uses very long passphrase and key sizes and a mixture of algorithms which can be used to verify the behaviour in extreme cases.
このセクションは2セットのテストベクトル、正当性について確かめるのに使用できて、自由に米国から輸出向きであるアルゴリズムを使用するDESに、非常に基本的なセット、非常に長いパスフレーズと主要なサイズを使用するストレス試験バージョン、および極端な場合はふるまいについて確かめるのに使用できるアルゴリズムの混合物を含みます。
Gutmann Standards Track [Page 7] RFC 3211 Password-based Encryption for CMS December 2001
ガットマンStandardsはcm2001年12月にRFC3211のパスワードベースの暗号化を追跡します[7ページ]。
The basic test contains two subtests, a known-answer test for the key
derivation stage and a full test of the key wrapping. Both tests use
a DES-CBC key derived from the password "password" with salt { 12 34
56 78 78 56 34 12 } using 5 iterations of PBKDF2. In the known
answer test the IV is set to all zeroes (equivalent to using ECB) and
used to encrypt an all-zero data block.
基本的なテストは2つの部分試験、主要な派生ステージのための知られている答えテスト、および主要なラッピングの完全なテストを含んでいます。 両方のテストは塩12 34 56 78 78 56 34 12によって「パスワード」というパスワードからPBKDF2の5繰り返しを使用することで得られたDES-CBCキーを使用します。 知られている答えテストで、IVはオールゼロデータ・ブロックをコード化するのにおいて(ECBを使用するのに同等)の、そして、中古のすべてのゼロへのセットです。
The following values are obtained for the known-answer test:
知られている答えテストに以下の値を得ます:
PKCS #5v2 values:
PKCS#5v2値:
input 70 61 73 73 77 6f 72 64
passphrase: "password"
input salt: 12 34 56 78 78 56 34 12
iterations: 5
70 61 73 73 77 6f72 64パスフレーズを入力してください: 「パスワード」入力塩: 12 34 56 78 78 56 34 12の繰り返し: 5
output key: D1 DA A7 86 15 F2 87 E6
known answer: 9B BD 78 FC 11 A3 A9 08
キーを出力してください: D1 DA A7 86 15F2 87の6E知られている答え: 9B BD78FC11A3 A9 08
The following values are obtained when wrapping a 64-bit (parity- adjusted) DES-EBC key:
(同等は適応しました)64ビットのDES-EBCキーを包装するとき、以下の値を得ます:
PKCS #5v2 values:
PKCS#5v2値:
input 70 61 73 73 77 6f 72 64
passphrase: "password"
input salt: 12 34 56 78 78 56 34 12
iterations: 5
70 61 73 73 77 6f72 64パスフレーズを入力してください: 「パスワード」入力塩: 12 34 56 78 78 56 34 12の繰り返し: 5
output key: D1 DA A7 86 15 F2 87 E6
キーを出力してください: D1 DA A7 86 15F2 87E6
CEK formatting phase:
CEK形式フェーズ:
length byte: 08
key check: 73 9D 83
CEK: 8C 62 7C 89 73 23 A2 F8
padding: C4 36 F5 41
長さのバイト: 08の主要なチェック: 73 9D83CEK: 8 C62 7C89 73 23A2 F8詰め物: C4 36F5 41
complete 08 73 9D 83 8C 62 7C 89 73 23 A2 F8 C4 36 F5 41
CEK block:
C62 7C89 73 23A2 F8 C4 36F5 41CEKが妨げる08 73 9D83 8を完成してください:
Gutmann Standards Track [Page 8] RFC 3211 Password-based Encryption for CMS December 2001
ガットマンStandardsはcm2001年12月にRFC3211のパスワードベースの暗号化を追跡します[8ページ]。
Key wrap phase (wrap CEK block using DES key):
主要な包装フェーズ(DESキーを使用するCEKが妨げる包装):
IV: EF E5 98 EF 21 B3 3D 6D
IV: EF E5 98EF21B3 3D6D
first encr. 06 A0 43 86 1E 82 88 E4 8B 59 9E B9 76 10 00 D4
pass output:
second encr. B8 1B 25 65 EE 37 3C A6 DE DC A2 6A 17 8B 0C 10
pass output:
最初に、encr。 06 A0 43 86 1 82 88Eの4 8B59 9E EのB9 76 10 00D4は出力を渡します: 2番目のencr。 B8 1B25 65EE37 3C A6DE DC A2 6A17 8B0C10は出力を渡します:
ASN.1 encoded PasswordRecipientInfo:
ASN.1はPasswordRecipientInfoをコード化しました:
0 A3 68: [3] {
2 02 1: INTEGER 0
5 A0 26: [0] {
7 06 9: OBJECT IDENTIFIER id-PBKDF2 (1 2 840 113549 1 5 12)
18 30 13: SEQUENCE {
20 04 8: OCTET STRING
: 12 34 56 78 78 56 34 12
30 02 1: INTEGER 5
: }
: }
34 30 32: SEQUENCE {
36 06 11: OBJECT IDENTIFIER id-alg-PWRI-KEK
: (1 2 840 113549 1 9 16 3 9)
33 30 17: SEQUENCE {
35 06 5: OBJECT IDENTIFIER des-CBC (1 3 14 3 2 7)
42 04 8: OCTET STRING
: EF E5 98 EF 21 B3 3D 6D
: }
: }
68 04 16: OCTET STRING
: B8 1B 25 65 EE 37 3C A6 DE DC A2 6A 17 8B 0C 10
: }
0 A3 68: [3] { 2 02 1: INTEGER 0 5 A0 26: [0] { 7 06 9: OBJECT IDENTIFIER id-PBKDF2 (1 2 840 113549 1 5 12) 18 30 13: SEQUENCE { 20 04 8: OCTET STRING : 12 34 56 78 78 56 34 12 30 02 1: INTEGER 5 : } : } 34 30 32: SEQUENCE { 36 06 11: OBJECT IDENTIFIER id-alg-PWRI-KEK : (1 2 840 113549 1 9 16 3 9) 33 30 17: SEQUENCE { 35 06 5: OBJECT IDENTIFIER des-CBC (1 3 14 3 2 7) 42 04 8: OCTET STRING : EF E5 98 EF 21 B3 3D 6D : } : } 68 04 16: OCTET STRING : B8 1B 25 65 EE 37 3C A6 DE DC A2 6A 17 8B 0C 10 : }
Gutmann Standards Track [Page 9] RFC 3211 Password-based Encryption for CMS December 2001
ガットマンStandardsはcm2001年12月にRFC3211のパスワードベースの暗号化を追跡します[9ページ]。
The following values are obtained when wrapping a 256-bit key (for
example one for AES or Blowfish) using a triple DES-CBC key derived
from the passphrase "All n-entities must communicate with other
n-entities via n-1 entiteeheehees" with salt
{ 12 34 56 78 78 56 34 12 } using 500 iterations of PBKDF2.
塩12 34 56 78 78 56 34 12によって「すべてのn-実体がn-1 entiteeheeheesを通って他のn-実体とコミュニケートしなければならない」パスフレーズからPBKDF2の500繰り返しを使用することで得られた三重のDES-CBCキーを使用することで256ビットのキー(例えば、AESかBlowfishのためのもの)を包装するとき、以下の値を得ます。
PKCS #5v2 values:
PKCS#5v2値:
input 41 6C 6C 20 6E 2D 65 6E 74 69 74 69 65 73 20 6D
passphrase: 75 73 74 20 63 6F 6D 6D 75 6E 69 63 61 74 65 20
77 69 74 68 20 6F 74 68 65 72 20 6E 2d 65 6E 74
69 74 69 65 73 20 76 69 61 20 6E 2D 31 20 65 6E
74 69 74 65 65 68 65 65 68 65 65 73
"All n-entities must communicate with other "
"n-entities via n-1 entiteeheehees"
input
salt: 12 34 56 78 78 56 34 12
iterations: 500
41 6C6C20 6E2D65 6Eの74 69 74 69 65 73 20 6Dパスフレーズを入力してください: 75 73 74 20 63 6F6D 6D75 6E69 63 61 74 65 20 77 69 74 68 20 6F74 68 65 72 20 6E2d65 6E74 69 74 69 65 73 20 76 69 61 20 6E2D31 20 65 6Eの「すべてのn-実体が他で交信しなければならない」74 69 74 65 65 68 65 65 68 65 65 73「n-1 entiteeheeheesを通したn-実体」入力塩: 12 34 56 78 78 56 34 12の繰り返し: 500
output 6A 89 70 BF 68 C9 2C AE A8 4A 8D F2 85 10 85 86
3DES key: 07 12 63 80 CC 47 AB 2D
6A89 70BF68C9 2C AE A8 4A 8D F2 85 10 85 86 3DESキーを出力してください: 07 12 63 80CC47AB2D
CEK formatting phase:
CEK形式フェーズ:
length byte: 20
key check: 73 9C 82
CEK: 8C 63 7D 88 72 23 A2 F9 65 B5 66 EB 01 4B 0F A5
D5 23 00 A3 F7 EA 40 FF FC 57 72 03 C7 1B AF 3B
padding: FA 06 0A 45
長さのバイト: 20の主要なチェック: 73 9 C82CEK: 8 C63 7D88 72 23A2 F9 65B5 66EB01 4B 0F A5 D5 23 00A3 F7 EA40FF FC57 72 03C7 1B AF 3B詰め物: ファ06 0A45
complete 20 73 9C 82 8C 63 7D 88 72 23 A2 F9 65 B5 66 EB
CEK block: 01 4B 0F A5 D5 23 00 A3 F7 EA 40 FF FC 57 72 03
C7 1B AF 3B FA 06 0A 45
9C82 8C63 7D88 72 23A2 F9 65B5 66EB CEKが妨げる20 73を完成してください: 01 4B 0F A5 D5 23 00A3 F7 EA40ff FC57 72 03C7 1B AF 3Bファ06 0A45
Key wrap phase (wrap CEK block using 3DES key):
主要な包装フェーズ(3DESキーを使用するCEKが妨げる包装):
IV: BA F1 CA 79 31 21 3C 4E
IV: Ba4F1カリフォルニア79 31 21 3C E
first encr. F8 3F 9E 16 78 51 41 10 64 27 65 A9 F5 D8 71 CD
pass output: 27 DB AA 41 E7 BD 80 48 A9 08 20 FF 40 82 A2 80
96 9E 65 27 9E 12 6A EB
最初に、encr。 F8 3F9E16 78 51 41 10 64 27 65A9 F5 D8 71CDパス出力: 27 DB AA41 7EのBD80 48A9 08 20ff40 82A2 80 96 9の65 27 9E12Eの6A EB
second encr. C0 3C 51 4A BD B9 E2 C5 AA C0 38 57 2B 5E 24 55
pass output: 38 76 B3 77 AA FB 82 EC A5 A9 D7 3F 8A B1 43 D9
EC 74 E6 CA D7 DB 26 0C
2番目のencr。 C0 3C51 4A BD B9 2EのC5 AA C0 38 57 2B5E24 55は出力を渡します: 38 76B3 77AA FB82EC A5 A9 D7 3F 8A B1 43D9EC74 6EのカリフォルニアD7 DB26 0C
Gutmann Standards Track [Page 10] RFC 3211 Password-based Encryption for CMS December 2001
ガットマンStandardsはcm2001年12月にRFC3211のパスワードベースの暗号化を追跡します[10ページ]。
ASN.1 encoded PasswordRecipientInfo:
ASN.1はPasswordRecipientInfoをコード化しました:
0 A3 96: [3] {
2 02 1: INTEGER 0
5 A0 27: [0] {
7 06 9: OBJECT IDENTIFIER id-PBKDF2 (1 2 840 113549 1 5 12)
18 30 14: SEQUENCE {
20 04 8: OCTET STRING
: 12 34 56 78 78 56 34 12
30 02 2: INTEGER 500
: }
: }
34 30 35: SEQUENCE {
36 06 11: OBJECT IDENTIFIER id-alg-PWRI-KEK
: (1 2 840 113549 1 9 16 3 9)
34 30 20: SEQUENCE {
36 06 8: OBJECT IDENTIFIER des-EDE3-CBC (1 2 840 113549 3 7)
46 04 8: OCTET STRING
: BA F1 CA 79 31 21 3C 4E
: }
: }
71 04 40: OCTET STRING
: C0 3C 51 4A BD B9 E2 C5 AA C0 38 57 2B 5E 24 55
: 38 76 B3 77 AA FB 82 EC A5 A9 D7 3F 8A B1 43 D9
: EC 74 E6 CA D7 DB 26 0C
: }
0 A3 96: [3] { 2 02 1、: 整数0 5A0 27:0、7、06、9、: 物の識別子イド-PBKDF2、(1 2、840、113549、1 5、12)、18 30 14、: 系列、20 04、8、: 八重奏ストリング: 12 34 56 78 78 56 34 12 30 02、2: 整数500:、:、34 30 35; }
4. Security Considerations
4. セキュリティ問題
The security of this recipient information type rests on the security of the underlying mechanisms employed, for which further information can be found in RFC 2630 and PKCS5v2. More importantly, however, when used with a password the security of this information type rests on the entropy of the user-selected password, which is typically quite low. Pass phrases (as opposed to simple passwords) are STRONGLY RECOMMENDED, although it should be recognized that even with pass phrases it will be difficult to use this recipient information type to derive a KEK with sufficient entropy to properly protect a 128-bit (or higher) CEK.
この受取人情報タイプのセキュリティはRFC2630とPKCS5v2でどの詳細を見つけることができるように使われた発症機序のセキュリティにかかっています。 しかしながら、より重要に、いつがパスワードと共にタイプが通常、かなり低いユーザによって選択されたパスワードのエントロピーで休ませるこの情報のセキュリティを使用しましたか? パス句(簡単なパスワードと対照的に)はSTRONGLY RECOMMENDEDです、パス句があっても、適切に128ビットの、そして、(より高い)のCEKを保護できるくらいのエントロピーがあるKEKを引き出すのにこの受取人情報タイプを使用するのが難しいと認められるべきですが。
Gutmann Standards Track [Page 11] RFC 3211 Password-based Encryption for CMS December 2001
ガットマンStandardsはcm2001年12月にRFC3211のパスワードベースの暗号化を追跡します[11ページ]。
5. IANA Considerations
5. IANA問題
The PasswordRecipientInfo key encryption algorithms are identified by object identifiers (OIDs). OIDs were assigned from an arc contributed to the S/MIME Working Group by the RSA Security. Should additional encryption algorithms be introduced, the advocates for such algorithms are expected to assign the necessary OIDs from their own arcs. No action by the IANA is necessary for this document or any anticipated updates.
物の識別子(OIDs)によってPasswordRecipientInfoの主要な暗号化アルゴリズムは特定されます。 OIDsはRSA SecurityによってS/MIME作業部会に寄付されたアークから割り当てられました。 追加暗号化アルゴリズムを導入するなら、それら自身のアークから必要なOIDsを割り当てるとそのようなアルゴリズムのための支持者を予想します。 IANAによるどんな動作もこのドキュメントかどんな予期されたアップデートにも必要ではありません。
Acknowledgments
承認
The author would like to thank Jim Schaad, Phil Griffin, and the members of the S/MIME Working Group for their comments and feedback on this document.
作者はこのドキュメントの彼らのコメントとフィードバックについてジムSchaad、フィル・グリフィンとS/MIME作業部会のメンバーに感謝したがっています。
Author Address
作者アドレス
Peter Gutmann University of Auckland Private Bag 92019 Auckland, New Zealand
ピーター・ガットマン・オークランド大学の個人的なBag92019オークランド(ニュージーランド)
EMail: pgut001@cs.auckland.ac.nz
メール: pgut001@cs.auckland.ac.nz
References
参照
[ASN1] CCITT Recommendation X.208: Specification of Abstract
Syntax Notation One (ASN.1), 1988.
[ASN1]CCITT推薦X.208: 抽象構文記法1(ASN.1)の仕様、1988。
[RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「使用のための要件レベルを示すRFCsのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2630] Housley, R., "Cryptographic Message Syntax", RFC 2630, June
1999.
[RFC2630] Housley、R.、「暗号のメッセージ構文」、RFC2630、1999年6月。
[RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography
Specification, Version 2.0", RFC 2898, September 2000.
[RFC2898]Kaliski、B.、「PKCS#5:」 パスワードベースの暗号仕様、バージョン2インチ、RFC2898、2000年9月。
[PACKAGE] All-or-Nothing Encryption and the Package Transform, R.
Rivest, Proceedings of Fast Software Encryption '97, Haifa,
Israel, January 1997.
[パッケージ]、オール、無、速いソフトウェア暗号化97年、ハイファ(イスラエル)1月1997の暗号化とパッケージ変換、R.Rivest、議事
Gutmann Standards Track [Page 12] RFC 3211 Password-based Encryption for CMS December 2001
ガットマンStandardsはcm2001年12月にRFC3211のパスワードベースの暗号化を追跡します[12ページ]。
Appendix A: ASN.1:1988 Module
付録A: ASN.1: 1988年のモジュール
PasswordRecipientInfo-88
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) pwri(17) }
PasswordRecipientInfo-88iso(1)が(2) 私たちをメンバーと同じくらい具体化させる、(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)モジュール(0)pwri(17)
DEFINITIONS IMPLICIT TAGS ::= BEGIN
定義、内在しているタグ:、:= 始まってください。
IMPORTS
輸入
AlgorithmIdentifier
FROM AuthenticationFramework { joint-iso-itu-t ds(5) module(1)
authenticationFramework(7) 3 }
AuthenticationFrameworkからのAlgorithmIdentifier共同iso-itu t ds(5)モジュール(1)authenticationFramework(7)3
CMSVersion, EncryptedKey
FROM CryptographicMessageSyntax { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) cms(1) };
CMSVersion、EncryptedKey FROM CryptographicMessageSyntax、iso(1)が(2) 私たちをメンバーと同じくらい具体化させる、(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)モジュール(0)cm(1)、。
-- The following PDU is defined in PKCS5 { iso(1) member-body(2)
-- us(840) rsadsi(113549) pkcs(1) pkcs-5(5) modules(16)
-- pkcs5v2-0(1) }, however it can't be imported because because
-- it's specified in 1994/1997 ASN.1. Because of this it's copied
-- here from the source but rephrased as 1988 ASN.1. Further
-- details are given in [RFC 2898].
-- 以下のPDUがPKCS5で定義される、iso(1)メンバーボディー(2)--、私たち、(840)rsadsi(113549) pkcs(1) pkcs-5(5)モジュール(16)--、pkcs5v2-0(1)、しかしながら、それを輸入できない、--それが1994/1997ASN.1で指定した これのために、それは、ここにソースからコピーされますが、1988ASN.1として言い直されます。 さらに、詳細は中[RFC2898]に述べられます。
PBKDF2-params ::= SEQUENCE {
salt OCTET STRING,
iterationCount INTEGER (1..MAX),
keyLength INTEGER (1..MAX) OPTIONAL,
prf AlgorithmIdentifier
DEFAULT { algorithm id-hmacWithSHA1, parameters NULL } }
PBKDF2-params:、:= 系列OCTET STRINGに塩味を付けさせてください、iterationCount INTEGER(1..MAX)、keyLength INTEGER(1..MAX)OPTIONAL、prf AlgorithmIdentifier DEFAULT、アルゴリズムイド-hmacWithSHA1、パラメタNULL
-- The PRF algorithm is also defined in PKCS5 and can neither be -- imported nor expressed in 1988 ASN.1, however it is encoded as -- an AlgorithmIdentifier with the OID:
-- PRFアルゴリズムは、また、PKCS5で定義されて、どちらもあるはずがありません--1988ASN.1で輸入されて、言い表されます、それがどのようにコード化されても--OIDとAlgorithmIdentifier:
id-hmacWithSHA1 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) digestAlgorithm(2) 7 }
イド-hmacWithSHA1物の識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) digestAlgorithm(2)7をメンバーと同じくらい具体化させます。
-- and NULL parameters. Further details are given in [RFC 2898].
-- そして、NULLパラメタ。 [RFC2898]で詳細を与えます。
-- Implementation note: Because of the inability to precisely -- specify the PBKDF2 PDU or its parameters in 1988 ASN.1, it is -- likely that implementors will also encounter alternative -- interpretations of these parameters, usually using an alternate -- OID from the IPsec arc which is generally used for HMAC-SHA1:
-- 実現注意: 無能、それはそうです--正確に、1988ASN.1のPBKDF2 PDUかそのパラメタを指定してください、そして、また、おそらく、その作成者意志は一般に、HMAC-SHA1に使用されるIPsecアークから代替手段--通常、補欠を使用するこれらのパラメタの解釈--OIDに遭遇します:
Gutmann Standards Track [Page 13] RFC 3211 Password-based Encryption for CMS December 2001
ガットマンStandardsはcm2001年12月にRFC3211のパスワードベースの暗号化を追跡します[13ページ]。
--
-- hMAC-SHA1 OBJECT IDENTIFIER ::= { iso(1)
-- identified-organization(3) dod(6) internet(1) security(5)
-- mechanisms(5) 8 1 2 }
--
-- with absent (rather than NULL) parameters.
-- -- hMAC-SHA1物の識別子:、:= iso(1)--特定された組織(3)dod(6)のインターネット(1)セキュリティ(5)--メカニズム(5)8 1 2--、--欠けている(NULLよりむしろ)パラメタで。
-- The PasswordRecipientInfo
-- PasswordRecipientInfo
id-alg-PWRI-KEK OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 9 }
イド-alg-PWRI-KEK物の識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3)9をメンバーと同じくらい具体化させます。
PasswordRecipientInfo ::= SEQUENCE {
version CMSVersion, -- Always set to 0
keyDerivationAlgorithm
[0] KeyDerivationAlgorithmIdentifier OPTIONAL,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey }
PasswordRecipientInfo:、:= 系列バージョンCMSVersion--いつも0keyDerivationAlgorithm[0]KeyDerivationAlgorithmIdentifier OPTIONAL、keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier、encryptedKey EncryptedKeyにセットしてください。
KeyDerivationAlgorithmIdentifier ::= AlgorithmIdentifier
KeyDerivationAlgorithmIdentifier:、:= AlgorithmIdentifier
KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier
KeyEncryptionAlgorithmIdentifier:、:= AlgorithmIdentifier
END -- PasswordRecipientInfo-88 --
終わってください(PasswordRecipientInfo-88)。
Appendix B: ASN.1:1997 Module
付録B: ASN.1: 1997年のモジュール
This appendix contains the same information as Appendix A in a more recent (and precise) ASN.1 notation, however Appendix A takes precedence in case of conflict.
この付録はより多くの最近の、そして、(正確)のASN.1記法でAppendix Aと同じ情報を含んでいて、しかしながら、Appendix Aは闘争の場合に優先します。
PasswordRecipientInfo-97
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) pwri(18) }
PasswordRecipientInfo-97iso(1)が(2) 私たちをメンバーと同じくらい具体化させる、(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)モジュール(0)pwri(18)
DEFINITIONS IMPLICIT TAGS ::= BEGIN
定義、内在しているタグ:、:= 始まってください。
IMPORTS
輸入
id-PBKDF2, PBKDF2-params,
FROM PKCS5 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-5(5) }
PKCS5からのイド-PBKDF2、PBKDF2-paramsiso(1)が(2) 私たちをメンバーと同じくらい具体化させる、(840) rsadsi(113549) pkcs(1) pkcs-5(5)
CMSVersion, EncryptedKey, des-ede3-cbc, CBCParameter
FROM CryptographicMessageSyntax { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) cms(1) };
CMSVersion、EncryptedKey、des-ede3-cbc、CBCParameter FROM CryptographicMessageSyntax、iso(1)が(2) 私たちをメンバーと同じくらい具体化させる、(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)モジュール(0)cm(1)、。
Gutmann Standards Track [Page 14] RFC 3211 Password-based Encryption for CMS December 2001
ガットマンStandardsはcm2001年12月にRFC3211のパスワードベースの暗号化を追跡します[14ページ]。
id-alg-PWRI-KEK OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 9 }
イド-alg-PWRI-KEK物の識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3)9をメンバーと同じくらい具体化させます。
PasswordRecipientInfo ::= SEQUENCE {
version CMSVersion, -- Always set to 0
keyDerivationAlgorithm
[0] KeyDerivationAlgorithmIdentifier OPTIONAL,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey }
PasswordRecipientInfo:、:= 系列バージョンCMSVersion--いつも0keyDerivationAlgorithm[0]KeyDerivationAlgorithmIdentifier OPTIONAL、keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier、encryptedKey EncryptedKeyにセットしてください。
KeyDerivationAlgorithmIdentifier ::=
AlgorithmIdentifier {{ KeyDerivationAlgorithms }}
KeyDerivationAlgorithmIdentifier:、:= AlgorithmIdentifier KeyDerivationAlgorithms
KeyDerivationAlgorithms ALGORITHM ::= {
{ OID id-PBKDF2 PARMS PBKDF2-params },
...
}
KeyDerivationAlgorithmsアルゴリズム:、:= OIDイド-PBKDF2 PARMS PBKDF2-params…
KeyEncryptionAlgorithmIdentifier ::=
AlgorithmIdentifier {{ KeyEncryptionAlgorithms }}
KeyEncryptionAlgorithmIdentifier:、:= AlgorithmIdentifier KeyEncryptionAlgorithms
KeyEncryptionAlgorithms ALGORITHM ::= {
{ OID id-alg-PWRI-KEK PARMS
AlgorithmIdentifier {{ PWRIAlgorithms }} },
...
}
KeyEncryptionAlgorithmsアルゴリズム:、:= OIDイド-alg-PWRI-KEK PARMS AlgorithmIdentifier PWRIAlgorithms …
-- Algorithm identifiers for algorithms used with the -- id-alg-PWRI-KEK key wrap algorithm. Currently only 3DES is a -- MUST, all others are optional
-- アルゴリズムのためのアルゴリズム識別子が使用した、--イド-alg-PWRI-KEKの主要な包装アルゴリズム。 現在の、唯一の3DESはaです--、すべての他のものが任意であるに違いありません。
PWRIAlgorithms ALGORITHM ::= {
{ OID des-ede3-cbc PARMS CBCParameter },
...
}
PWRIAlgorithmsアルゴリズム:、:= OID des-ede3-cbc PARMS CBCParameter…
-- Supporting definitions. We could also pull in the -- AlgorithmIdentifier from an appropriately recent X.500 module (or -- wherever) but it's just as easy (and more convenient for readers) -- to provide a definition here
-- 定義を支持します。 または、また、私たちが到着できた、--、適切に最近のX.500モジュールからのAlgorithmIdentifier、(--、どこ、)、それは、ちょうど簡単、そして、(読者には、より便利)です--定義をここに提供するために
AlgorithmIdentifier { ALGORITHM:IOSet } ::= SEQUENCE {
algorithm ALGORITHM.&id({IOSet}),
parameters ALGORITHM.&Type({IOSet}{@algorithm}) OPTIONAL
}
AlgorithmIdentifier、アルゴリズム: IOSet:、:= 系列パラメタALGORITHMアルゴリズムALGORITHMイド(IOSet)、Type、(IOSet、@algorithm) OPTIONAL
ALGORITHM ::= CLASS {
&id OBJECT IDENTIFIER UNIQUE,
アルゴリズム:、:= クラス、イド物の識別子ユニークです。
Gutmann Standards Track [Page 15] RFC 3211 Password-based Encryption for CMS December 2001
ガットマンStandardsはcm2001年12月にRFC3211のパスワードベースの暗号化を追跡します[15ページ]。
&Type OPTIONAL
}
WITH SYNTAX { OID &id [PARMS &Type] }
任意の状態で、タイプしてください。 構文でOIDとイド[PARMSとタイプ]
END -- PasswordRecipientInfo-97 --
終わってください(PasswordRecipientInfo-97)。
Gutmann Standards Track [Page 16] RFC 3211 Password-based Encryption for CMS December 2001
ガットマンStandardsはcm2001年12月にRFC3211のパスワードベースの暗号化を追跡します[16ページ]。
Full Copyright Statement
完全な著作権宣言文
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機能のための基金は現在、インターネット協会によって提供されます。
Gutmann Standards Track [Page 17]
ガットマン標準化過程[17ページ]
一覧
スポンサーリンク
