[要約] RFC 3211は、CMS（Cryptographic Message Syntax）のためのパスワードベースの暗号化に関する規格です。このRFCの目的は、パスワードを使用してCMSメッセージを暗号化するためのセキュアな方法を提供することです。
Network Working Group P. Gutmann
Request for Comments: 3211 University of Auckland
Category: Standards Track December 2001
Password-based Encryption for CMS
CMSのパスワードベースの暗号化
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.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（2001）。無断転載を禁じます。
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.
このドキュメントは、ユーザーがサポートしたパスワードを使用してデータを暗号化する方法を提供し、さらには、必ずしもアルゴリズム固有の固定フォーマットキーではない可変長キーイング材料のあらゆる形式です。暗号化メッセージの構文データ形式には、現在、パスワードベースのデータ暗号化に関する規定は含まれていません。
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タイプとして実装されており、RFC 2630で現在定義されている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.
「必須」、「必須」、「必須」、「必要」、「必要はない」、「推奨」、「5月」、および「オプション」は、RFC 2119で説明されているように解釈されます。
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は現在、Public-Key Key Lapping（KeyTransrecipientInfo）、従来のキーラッピング（KekrecipientInfo）、およびキー契約（keyagreerecipientinfo）の3つの受信者情報タイプを定義しています。ここで説明する受信者情報は、パスワードベースのキーラッピングを提供する4番目のタイプのPasswordRecipientInfoを追加します。
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 ::= CHOICE {
ktri KeyTransRecipientInfo,
kari [1] KeyAgreeRecipientInfo,
kekri [2] KEKRecipientInfo,
pwri [3] PasswordRecipientinfo -- New RecipientInfo type
}
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.
受信者情報生成プロセスは、パスワードベースの操作の観点から説明されていますが（これは最も一般的な使用であるため）、採用されている変換は、あらゆるタイプのキーイング材料を特定のコンテンツ暗号化アルゴリズムに固有のキー。パスワードベースの暗号化の最も一般的な用途は、（ネットワーク全体に送信されるのではなく）ローカルに保存されるファイルを暗号化することであるため、「受信者」という用語はやや誤解を招きますが、他の重要な輸送メカニズムは常にあるために使用されます。同様の用語で説明されています。
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の各インスタンスは、以前に合意したパスワードまたはキー暗号化キー（KEK）を持っている1人または複数の受信者にコンテンツ圧縮キー（CEK）を転送します。
PasswordRecipientInfo ::= SEQUENCE {
version CMSVersion, -- Always set to 0
keyDerivationAlgorithm
[0] KeyDerivationAlgorithmIdentifier OPTIONAL,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey }
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バージョンタイプの詳細は、CMS [RFC2630]、セクション10.2.5で説明されています。
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.
KeyDederivationalGorithmは、ユーザーがサプライされたパスワードから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.
暗号化されたKeyは、KEKを使用してコンテンツ暗号化キーを暗号化した結果です。
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に変換される第1段階であり、CEKを暗号化するためにKEKを使用する2番目の段階です。これらの2つの段階は、2つのアルゴリズム識別子によって識別されます。PKCS＃5V2標準[RFC2898]は、これらを単一のアルゴリズム識別子にまとめるためにさらに一歩進んでいますが、この設計はその標準に特有のものであり、他の主要なラッピングメカニズムには適用できない場合があります。このため、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.
現在の形式では、複数のパスワード受信者INFOを区別する手段は提供されません。これは、たとえば、同じデータを暗号化するために2つのパスワードを使用した場合に発生します。残念ながら、一般的なアプリケーションは、ユーザーから取得した単一のパスワードを含むファイルなどのデータを暗号化するモデルに従っているため、この分野で既存の練習が不足しています。明確な要件がなければ、現時点では適切な複数のパスワードメカニズムを定義することは困難です（おそらく不可能）。十分な需要が発生した場合、これは、適切なフォームのオプションの識別フィールドを追加するなど、このドキュメントの将来のバージョンで対処される場合があります。
2 Supported Algorithms
2サポートされたアルゴリズム
This section lists the algorithms that must be implemented. Additional algorithms that should be implemented are also included.
このセクションには、実装する必要があるアルゴリズムをリストします。実装すべき追加のアルゴリズムも含まれています。
These algorithms are used to convert the password into a KEK. The key derivation algorithms are:
これらのアルゴリズムは、パスワードをKEKに変換するために使用されます。キー派生アルゴリズムは次のとおりです。
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には、1988 ASN.1を使用して可能なよりも許容されるアルゴリズムタイプのより正確な定義が含まれています。
These algorithms are used to encrypt the CEK using the derived KEK. The key encryption algorithms are:
これらのアルゴリズムは、派生したKEKを使用してCEKを暗号化するために使用されます。キー暗号化アルゴリズムは次のとおりです。
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 }
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.
適合実装は、ID-Alg-PWRI-KEKキーラップアルゴリズムを実装する必要があります。id-alg-pwri-kekで使用されるkek暗号化アルゴリズムの場合、適合実装にはCBCモードのトリプルDEを含める必要があり、AES、CAST-128、RC5、アイデア、スキップジャック、ブローフィッシュ、暗号化モードなどの他のアルゴリズムを含めることができます。必須。実装には、RC4やOFBモードのブロック暗号などのKSG（キーストリームジェネレーター）暗号を含めるべきではなく、ECBモードのブロック暗号を含めるべきではありません。
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 wrapping algorithm would require a change to the PasswordRecipientInfo structure rather than simply a change to the key encryption algorithm identifier.
KeyEncryptionAlgorithmidentifierを指定する際の間接レベルの使用により、将来的に代替ラッピングアルゴリズムを使用できるようになります。KEKアルゴリズムがこのフィールドで直接指定された場合、代替ラッピングアルゴリズムを使用すると、キー暗号化アルゴリズム識別子の変更ではなく、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.
このアルゴリズム識別子のパラメーターフィールドは、トリプルDEにデフォルトするように指定できますが、アルゴリズム識別子にnull対存在しないパラメーターが混乱しているため、デフォルト値なしで明示的になります。
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.
キーラップアルゴリズムは、CEKをKEKで暗号化し、すべてのプレーンテキストが暗号文のあらゆるビットに影響を与えることを保証します。これにより、ハッシュ関数や暗号的に強い乱数などの追加のメカニズムやリソースを必要とせずに、パッケージ変換[パッケージ]と同等になります。キーラップアルゴリズムは2つのフェーズで実行されます。これは、CEKをKEKによる暗号化に適したフォームにフォーマットする第1フェーズと、KEKを使用してフォーマットされたCEKをラップする2番目のフェーズです。
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. 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データブロックをKEKブロックの長さの倍数と少なくとも2つの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を使用してパッド入りキーを暗号化します。
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として使用して）、暗号化されたパッド入りキーを2回目に暗号化します。
The resulting double-encrypted data is the EncryptedKey.
結果の二重暗号化データは、暗号化されたキーです。
Key unwrapping:
キーアンラッピング：
1. Using the n-1'th ciphertext block as the IV, decrypt the n'th ciphertext block.
1. n-1'th ciphertextブロックをIVとして使用すると、n'th ciphertextブロックを復号化します。
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 ciphertextブロックを使用すると、1番目の... n-1'th ciphertextブロックを復号化します。これにより、暗号化の外層がストリップされます。
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バイトカウントが最小許容キーサイズ（通常は40ビットキーの場合は5バイト）またはラップされたCEKの長さよりも大きい場合、またはCEKアルゴリズムで有効でない場合（トリプルDEの場合は16または24バイトではありません）、ケックは無効でした。
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。キーチェック値のビットワイズ補数がキーの最初の3バイトと一致しない場合、Kekは無効でした。
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. CEKブロックの最初の4バイトをSkipJackキーサイズ（10バイト）に設定し、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. 2バイトのランダムデータを使用して、80ビット（10バイト）SkipJack CEKを追加し、合計を16バイト（2つのトリプルDESブロック）にパッドします。
2. Using the IV given in the KeyEncryptionAlgorithmIdentifer, encrypted the padded Skipjack key.
2. KeyEncryptionalgorithmidentiferに与えられたIVを使用して、パッド入りのSkipJackキーを暗号化しました。
3. Without resetting the IV, encrypt the encrypted padded key a second time.
3. IVをリセットせずに、暗号化されたパッド付きキーを2回暗号化します。
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. 二重暗号化キーの最初の8バイトをIVとして使用すると、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. KeyEncryptionalgorithmidentiferに与えられたIVを使用して、暗号化の内側層を復号化して、パッド入りのSkipJackキーを回復します。
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バイト）に等しくない場合、またはチェックバイトのビットワイズ補体がCEKの最初の3バイトと一致しない場合、Kekは無効でした。
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.
多くのCEKが同じKekを備えた標準的な方法で暗号化され、Kekが64ビットのブロックサイズを持つ場合、約2^32の暗号化の後、暗号化されたCEKの異なるブロック間の衝突の可能性が高くなります。対戦相手がCEKを手に入れることができれば、他のCEKを解決できる可能性があります。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つのタイプの暗号化アルゴリズムのみをサポートするデバイスに実装できることです。このようなデバイスの典型的な例は、単一のブロック暗号と単一のパブリックキーアルゴリズムのみをサポートするスマートカードなどの暗号トークンです。追加のアルゴリズムの使用が必要な場合はキーを包むことができません。
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の非常に基本的なセットと、米国から自由にエクスポートできるアルゴリズムと、非常に長いパスフレーズとキーサイズとキーサイズを使用するストレステストバージョンを使用します。極端な場合の動作を検証するために使用できるアルゴリズムの混合。
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つのサブテストが含まれています。どちらのテストでも、PBKDF2の5回の反復を使用して、SALT {12 34 56 78 78 56 34 12}を使用したパスワード「パスワード」から派生した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 6F 72 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 15 F2 87 E6既知の回答：9B BD 78 FC 11 A3 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 6F 72 64パスフレーズ： "パスワード"入力塩：12 34 56 78 78 56 34 12反復：5
output key: D1 DA A7 86 15 F2 87 E6
出力キー：D1 DA A7 86 15 F2 87 E6
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 9d 83 CEK：8C 62 7C 89 73 23 A2 F8パディング：C4 36 F5 41
complete 08 73 9D 83 8C 62 7C 89 73 23 A2 F8 C4 36 F5 41 CEK block:
完了08 73 9d 83 8c 62 7c 89 73 23 A2 f8 C4 36 F5 41 CEKブロック：
Key wrap phase (wrap CEK block using DES key):
キーラップフェーズ（DESキーを使用したラップCEKブロック）：
IV: EF E5 98 EF 21 B3 3D 6D
IV：EF E5 98 EF 21 B3 3D 6D
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 1E 82 88 E4 8B 59 9E B9 76 10 00 D4パス出力：2番目のENCR。B8 1B 25 65 EE 37 3C A6 DE DC A2 6A 17 8B 0C 10パス出力：
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
: }
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.
パスフレーズから派生したトリプルDES-CBCキーを使用して、256ビットキー（AESまたはブローフィッシュの場合は1つ）をラッピングするときに、次の値が取得されます。塩{12 34 56 78 78 56 34 12} PBKDF2の500反復を使用。
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 6C 6C 20 6E 2D 65 6E 74 69 74 69 65 73 20 6Dパスフレーズ：75 73 74 20 63 63 6F 6D 6D 75 6E 69 63 61 74 65 2074 69 74 69 65 73 20 76 69 61 20 6E 2D 31 20 65 6E 74 69 74 65 65 68 65 65 65 65 65 65 73塩：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
出力6A 89 70 BF 68 C9 2C AE A8 4A 8D F2 85 10 85 86 3DESキー：07 12 63 80 CC 47 AB 2D
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 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パディング：FA 06 0A 455
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
完了20 73 9C 82 8C 63 7d 88 72 23 A2 F9 65 B5 66 EB CEKブロック：01 4B 0F A5 D5 23 00 A3 F7 EA 40 FF FC 57 72 03 C7 1B AF 3B FA 06 0A 455
Key wrap phase (wrap CEK block using 3DES key):
キーラップフェーズ（3DESキーを使用したラップCEKブロック）：
IV: BA F1 CA 79 31 21 3C 4E
IV：BA F1 CA 79 31 21 3C 4E
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 3F 9E 16 78 51 41 10 64 27 65 A9 F5 D8 71 CDパス出力：27 dB AA 41 E7 BD 80 48 A9 08 20 FF 40 82 A2 80 96 9E 65 27 9E 12 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 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 0CCCCCCCCCC
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
: }
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.
この受信者情報タイプのセキュリティは、採用されている基礎となるメカニズムのセキュリティに基づいており、RFC 2630およびPKCS5v2で詳細情報があります。しかし、さらに重要なことに、パスワードで使用する場合、この情報タイプのセキュリティは、ユーザーが選択したパスワードのエントロピーにかかっています。これは通常非常に低いことです。パスフレーズ（単純なパスワードとは対照的に）を強くお勧めしますが、パスフレーズを使用しても、この受信者情報タイプを使用して、128ビットを適切に保護するのに十分なエントロピーを備えたKEKを導き出すことは困難であることを認識する必要があります。）cek。
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.
PasswordRecipientInfoキー暗号化アルゴリズムは、オブジェクト識別子（OID）によって識別されます。OIDは、RSAセキュリティによってS/MIMEワーキンググループに貢献したARCから割り当てられました。追加の暗号化アルゴリズムが導入された場合、そのようなアルゴリズムの支持者は、独自のアークから必要なOIDを割り当てることが期待されます。このドキュメントまたは予想される更新には、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.
著者は、この文書に関するコメントとフィードバックについて、Jim Schaad、Phil Griffin、およびS/Mimeワーキンググループのメンバーに感謝したいと思います。
Author Address
著者アドレス
Peter Gutmann University of Auckland Private Bag 92019 Auckland, New Zealand
ピーター・ガットマン大学オークランド大学プライベートバッグ92019オークランド、ニュージーランド
EMail: pgut001@cs.auckland.ac.nz
References
参考文献
[ASN1] CCITT Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1), 1988.
[ASN1] CCITT推奨X.208：抽象的構文表記の仕様（ASN.1）、1988。
[RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2630] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999.
[RFC2630] Housley、R。、「暗号化メッセージ構文」、RFC 2630、1999年6月。
[RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography Specification, Version 2.0", RFC 2898, September 2000.
[RFC2898] Kaliski、B。、「PKCS＃5：パスワードベースの暗号化仕様、バージョン2.0」、RFC 2898、2000年9月。
[PACKAGE] All-or-Nothing Encryption and the Package Transform, R. Rivest, Proceedings of Fast Software Encryption '97, Haifa, Israel, January 1997.
[パッケージ] All-noting EncryptionとThe Package Transform、R。Rivest、Fast Software Encryption '97、ハイファ、イスラエル、1997年1月の議事録。
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) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
輸入
AlgorithmIdentifier
FROM AuthenticationFramework { joint-iso-itu-t ds(5) module(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) };
-- 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].
PBKDF2-params ::= SEQUENCE {
salt OCTET STRING,
iterationCount INTEGER (1..MAX),
keyLength INTEGER (1..MAX) OPTIONAL,
prf AlgorithmIdentifier
DEFAULT { algorithm id-hmacWithSHA1, parameters 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:
id-hmacWithSHA1 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) digestAlgorithm(2) 7 }
-- and NULL parameters. Further details are given in [RFC 2898].
- およびnullパラメーター。詳細については、[RFC 2898]に記載されています。
-- 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:
--
-- 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.
-- 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 }
PasswordRecipientInfo ::= SEQUENCE {
version CMSVersion, -- Always set to 0
keyDerivationAlgorithm
[0] KeyDerivationAlgorithmIdentifier OPTIONAL,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey }
KeyDerivationAlgorithmIdentifier ::= 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表記の付録Aと同じ情報が含まれていますが、付録Aは紛争の場合に優先されます。
PasswordRecipientInfo-97
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(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) }
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) };
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 }
PasswordRecipientInfo ::= SEQUENCE {
version CMSVersion, -- Always set to 0
keyDerivationAlgorithm
[0] KeyDerivationAlgorithmIdentifier OPTIONAL,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey }
KeyDerivationAlgorithmIdentifier ::=
AlgorithmIdentifier {{ KeyDerivationAlgorithms }}
KeyDerivationAlgorithms ALGORITHM ::= {
{ OID id-PBKDF2 PARMS PBKDF2-params },
...
}
KeyEncryptionAlgorithmIdentifier ::=
AlgorithmIdentifier {{ KeyEncryptionAlgorithms }}
KeyEncryptionAlgorithms ALGORITHM ::= {
{ OID id-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
PWRIAlgorithms ALGORITHM ::= {
{ 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
AlgorithmIdentifier { ALGORITHM:IOSet } ::= SEQUENCE {
algorithm ALGORITHM.&id({IOSet}),
parameters ALGORITHM.&Type({IOSet}{@algorithm}) OPTIONAL
}
ALGORITHM ::= CLASS {
&id OBJECT IDENTIFIER UNIQUE,
&Type OPTIONAL
}
WITH SYNTAX { OID &id [PARMS &Type] }
END -- PasswordRecipientInfo-97 --Full Copyright Statement
End-PasswordRecipientInfo-97-完全な著作権ステートメント
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（2001）。無断転載を禁じます。
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.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。