Network Working Group K. Raeburn
Request for Comments: 3962 MIT
Category: Standards Track February 2005
Advanced Encryption Standard (AES) Encryption for Kerberos 5
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 (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
The United States National Institute of Standards and Technology (NIST) has chosen a new Advanced Encryption Standard (AES), which is significantly faster and (it is believed) more secure than the old Data Encryption Standard (DES) algorithm. This document is a specification for the addition of this algorithm to the Kerberos cryptosystem suite.
米国国立標準技術研究所（NIST）は、（それが信じられている）古いデータ暗号化規格（DES）アルゴリズムよりも安全速く大きくされ、新しいAdvanced Encryption Standard（AES）を、選択しています。この文書では、Kerberos暗号スイートにこのアルゴリズムを追加するための仕様です。
This document defines encryption key and checksum types for Kerberos 5 using the AES algorithm recently chosen by NIST. These new types support 128-bit block encryption and key sizes of 128 or 256 bits.
この文書では、最近、NISTによって選ばれたAESアルゴリズムを使用して、Kerberos 5のための暗号鍵とチェックサムタイプを定義します。これらの新しいタイプは、128ビットブロック暗号と128または256ビットのキーサイズをサポートしています。
Using the "simplified profile" of [KCRYPTO], we can define a pair of encryption and checksum schemes. AES is used with ciphertext stealing to avoid message expansion, and SHA-1 [SHA1] is the associated checksum function.
[KCRYPTO]の「単純化されたプロファイル」を使用して、我々は暗号化とチェックサムのスキームのペアを定義することができます。 AESは、メッセージ拡張を避けるために、盗ん暗号文で使用され、SHA1 [SHA1]は関連するチェックサム関数です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [KEYWORDS].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119 [KEYWORDS]で説明されるように解釈されます。
The profile in [KCRYPTO] treats keys and random octet strings as conceptually different. But since the AES key space is dense, we can use any bit string of appropriate length as a key. We use the byte representation for the key described in [AES], where the first bit of the bit string is the high bit of the first byte of the byte string (octet string) representation.
[KCRYPTO]お菓子のキーと概念的に異なるランダムオクテット文字列でのプロファイル。 AES鍵空間が緻密であるため、しかし、我々はキーとして適切な長さの任意のビット列を使用することができます。我々は、ビット列の最初のビットがバイト列（オクテット列）表現の最初のバイトの上位ビットである[AES]に記載のキーのバイト表現を使用します。
Given the above format for keys, we can generate keys from the appropriate amounts of random data (128 or 256 bits) by simply copying the input string.
キーの上記の形式を考えると、我々は、単に、入力文字列をコピーすることによって、ランダムデータ（128または256ビット）の適切な量から鍵を生成することができます。
To generate an encryption key from a pass phrase and salt string, we use the PBKDF2 function from PKCS #5 v2.0 ([PKCS5]), with parameters indicated below, to generate an intermediate key (of the same length as the desired final key), which is then passed into the DK function with the 8-octet ASCII string "kerberos" as is done for des3-cbc-hmac-sha1-kd in [KCRYPTO]. (In [KCRYPTO] terms, the PBKDF2 function produces a "random octet string", hence the application of the random-to-key function even though it's effectively a simple identity operation.) The resulting key is the user's long-term key for use with the encryption algorithm in question.
パスフレーズと塩列から暗号鍵を生成するために、我々は、所望の最終と同じ長さの中間鍵を（生成するために、以下に示すパラメータを使用して、PKCS＃5 V2.0（[PKCS5]）からPBKDF2関数を使用します次いで、[KCRYPTO]でDES3-CBC-HMAC-SHA1-KDのために行われているように8オクテットASCII文字列 "ケルベロス" とDK関数に渡される、）キー。 （[KCRYPTO用語は、PBKDF2機能は、「ランダムオクテット列」、それが効果的に単純な識別オペレーションのにもかかわらず、ランダムにキー機能の、従ってアプリケーションを生成する。）得られたキーをするためのユーザの長期鍵であります問題の暗号化アルゴリズムを使用します。
tkey = random2key(PBKDF2(passphrase, salt, iter_count, keylength)) key = DK(tkey, "kerberos")
処理鍵= random2key（PBKDF2（パスフレーズ、塩、iter_count、KEYLENGTH））キー= DK（処理鍵、 "ケルベロス"）
The pseudorandom function used by PBKDF2 will be a SHA-1 HMAC of the passphrase and salt, as described in Appendix B.1 to PKCS#5.
PKCS＃5の付録B.1に記載したようにPBKDF2で使用される擬似ランダム関数は、パスフレーズと塩のSHA-1 HMACであろう。
The number of iterations is specified by the string-to-key parameters supplied. The parameter string is four octets indicating an unsigned number in big-endian order. This is the number of iterations to be performed. If the value is 00 00 00 00, the number of iterations to be performed is 4,294,967,296 (2**32). (Thus the minimum expressible iteration count is 1.)
反復回数は、与えられた文字列からキーへのパラメータで指定されています。パラメータ文字列はビッグエンディアンの順序で符号なしの数を示す4つのオクテットです。これは、反復回数が実行されます。値が00 00 00 00である場合、実行される反復回数は4,294,967,296（2 ** 32）です。 （したがって最小発現繰り返し回数は1です。）
For environments where slower hardware is the norm, implementations of protocols such as Kerberos may wish to limit the number of iterations to prevent a spoofed response supplied by an attacker from consuming lots of client-side CPU time; if such a limit is implemented, it SHOULD be no less than 50,000. Even for environments with fast hardware, 4 billion iterations is likely to take a fairly long time; much larger bounds might still be enforced, and it might be wise for implementations to permit interruption of this operation by the user if the environment allows for it.
遅いハードウェアが標準である環境では、Kerberosなどのプロトコルの実装では、クライアント側のCPU時間を大量に消費するから、攻撃者によって供給されるスプーフィングされた応答を防止するために、反復の数を制限することを望むかもしれません。このような制限が実装されている場合、それは50,000以上であってはなりません。でも高速なハードウェアと環境のために、40億回の反復は、かなり長い時間がかかりそうです。はるかに大きい境界はまだ施行される可能性がありますし、環境がそれを可能にした場合の実装は、ユーザがこの操作の中断を許可することが賢明かもしれません。
If the string-to-key parameters are not supplied, the value used is 00 00 10 00 (decimal 4,096, indicating 4,096 iterations).
ストリングからキーパラメータが供給されない場合、使用される値は00 00 10 00（4096回の反復を示し、4096を10進数）です。
Note that this is not a requirement, nor even a recommendation, for this value to be used in "optimistic preauthentication" (e.g., attempting timestamp-based preauthentication using the user's long-term key without having first communicated with the KDC) in the absence of additional information, or as a default value for sites to use for their principals' long-term keys in their Kerberos database. It is simply the interpretation of the absence of the string-to-key parameter field when the KDC has had an opportunity to provide it.
この値が存在しない状態で「楽観事前認証」（例えば、最初のKDCと通信したことなく、ユーザの長期キーを使用して、タイムスタンプベースの事前認証を試みる）で使用するために、これは、要件、またしてもお勧めではないことに注意してください追加情報の、またはサイトが自分のKerberosデータベース内のプリンシパルの長期キーに使用するために、デフォルト値として。 KDCはそれを提供する機会があったとき、それは単に文字列からキーへのパラメータフィールドの不在の解釈です。
Sample test vectors are given in Appendix B.
サンプルテストベクトルは、付録Bに記載されています
Cipher block chaining is used to encrypt messages, with the initial vector stored in the cipher state. Unlike previous Kerberos cryptosystems, we use ciphertext stealing to handle the possibly partial final block of the message.
暗号ブロック連鎖は、暗号化状態で格納された初期ベクトルを用いて、メッセージを暗号化するために使用されます。前回のKerberos暗号とは異なり、我々はメッセージの可能性が部分的に最後のブロックを処理するために、暗号文スチールを使用します。
Ciphertext stealing is described on pages 195-196 of [AC], and section 8 of [RC5]; it has the advantage that no message expansion is done during encryption of messages of arbitrary sizes as is typically done in CBC mode with padding. Some errata for [RC5] are listed in Appendix A and are considered part of the ciphertext stealing technique as used here.
暗号文窃盗は、[AC]のページ195-196に記載されており、[RC5]のセクション8れます。それは、通常のパディングとCBCモードで行われているようにメッセージ・拡大が任意のサイズのメッセージの暗号化の際に行われないという利点があります。 [RC5]のためのいくつかの正誤表は、付録Aに記載されていますし、ここで使用されるような技術を盗む暗号文の一部とみなされます。
Ciphertext stealing, as defined in [RC5], assumes that more than one block of plain text is available. If exactly one block is to be encrypted, that block is simply encrypted with AES (also known as ECB mode). Input smaller than one block is padded at the end to one block; the values of the padding bits are unspecified. (Implementations MAY use all-zero padding, but protocols MUST NOT rely on the result being deterministic. Implementations MAY use random padding, but protocols MUST NOT rely on the result not being deterministic. Note that in most cases, the Kerberos encryption profile will add a random confounder independent of this padding.)
暗号文窃盗は、[RC5]で定義されるように、プレーンテキストの複数のブロックが利用可能であることを前提としています。正確に一つのブロックを暗号化する場合、そのブロックは、単に（また、ECBモードとしても知られる）、AESで暗号化されています。一つのブロックよりも小さい入力は、1つのブロックの端部に埋め込まれています。パディングビットの値は不定です。 （実装はすべてゼロパディングを使用することができるが、プロトコルは、結果は決定論的であることに依存してはならない。実装はランダムなパディングを使用することができるが、プロトコルは、結果は確定的でない当てにしてはいけません。ほとんどの場合、Kerberos暗号化プロファイルが追加されることに注意してくださいこのパディングのランダムな交絡因子の独立しました。）
For consistency, ciphertext stealing is always used for the last two blocks of the data to be encrypted, as in [RC5]. If the data length is a multiple of the block size, this is equivalent to plain CBC mode with the last two ciphertext blocks swapped.
一貫性のために、暗号文窃盗は、常に[RC5]のように、暗号化するデータの最後の二つのブロックのために使用されます。データの長さがブロックサイズの倍数である場合、これはスワップ最後の二つの暗号文ブロックと無地CBCモードに相当します。
A test vector is given in Appendix B.
テストベクトルは、付録Bに記載されています
The initial vector carried out from one encryption for use in a subsequent encryption is the next-to-last block of the encryption output; this is the encrypted form of the last plaintext block. When decrypting, the next-to-last block of the supplied ciphertext is carried forward as the next initial vector. If only one ciphertext block is available (decrypting one block, or encrypting one block or less), then that one block is carried out instead.
後続の暗号化に使用するために1つの暗号化から搬出初期ベクトルは、暗号化出力の次に、最後のブロックです。これは、最後の平文ブロックの暗号化された形です。復号化するとき、供給される暗号文の次から最後のブロックは、次の初期ベクトルとして繰り越されます。唯一の暗号文ブロック（1つのブロック復号化、あるいは1つのブロック以下の暗号化）が利用可能である場合、その1つのブロックが代わりに行われます。
This is a summary of the parameters to be used with the simplified algorithm profile described in [KCRYPTO]:
これは、[KCRYPTO]に記載の簡略化アルゴリズムのプロファイルで使用されるパラメータの概要です。
+--------------------------------------------------------------------+
| protocol key format 128- or 256-bit string |
| |
| string-to-key function PBKDF2+DK with variable |
| iteration count (see |
| above) |
| |
| default string-to-key parameters 00 00 10 00 |
| |
| key-generation seed length key size |
| |
| random-to-key function identity function |
| |
| hash function, H SHA-1 |
| |
| HMAC output size, h 12 octets (96 bits) |
| |
| message block size, m 1 octet |
| |
| encryption/decryption functions, AES in CBC-CTS mode |
| E and D (cipher block size 16 |
| octets), with next-to- |
| last block (last block |
| if only one) as CBC-style |
| ivec |
+--------------------------------------------------------------------+
Using this profile with each key size gives us two each of encryption and checksum algorithm definitions.
各キーのサイズで、このプロファイルを使用すると、私たちの2つの暗号化とチェックサムアルゴリズムの定義のそれぞれを提供します。
The following encryption type numbers are assigned:
次の暗号化タイプ番号が割り当てられています。
+--------------------------------------------------------------------+
| encryption types |
+--------------------------------------------------------------------+
| type name etype value key size |
+--------------------------------------------------------------------+
| aes128-cts-hmac-sha1-96 17 128 |
| aes256-cts-hmac-sha1-96 18 256 |
+--------------------------------------------------------------------+
The following checksum type numbers are assigned:
以下のチェックサムタイプ番号が割り当てられています。
+--------------------------------------------------------------------+
| checksum types |
+--------------------------------------------------------------------+
| type name sumtype value length |
+--------------------------------------------------------------------+
| hmac-sha1-96-aes128 15 96 |
| hmac-sha1-96-aes256 16 96 |
+--------------------------------------------------------------------+
These checksum types will be used with the corresponding encryption types defined above.
これらのチェックサムタイプは、上記で定義され、対応する暗号化タイプで使用されます。
This new algorithm has not been around long enough to receive the decades of intense analysis that DES has received. It is possible that some weakness exists that has not been found by the cryptographers analyzing these algorithms before and during the AES selection process.
この新しいアルゴリズムは、十分な長DESを受けた強烈な分析の十年を受け取るために周りされていません。いくつかの弱点はAES選定プロセスの前との間にこれらのアルゴリズムを解析する暗号技術者によって発見されていないことが存在することも可能です。
The use of the HMAC function has drawbacks for certain pass phrase lengths. For example, a pass phrase longer than the hash function block size (64 bytes, for SHA-1) is hashed to a smaller size (20 bytes) before applying the main HMAC algorithm. However, entropy is generally sparse in pass phrases, especially in long ones, so this may not be a problem in the rare cases of users with long pass phrases.
HMAC関数の使用は、特定のパスフレーズの長さに関する欠点を有します。例えば、より長いハッシュ関数のブロックサイズよりもパスフレーズ（64のバイトは、SHA-1）は、主HMACアルゴリズムを適用する前に、小さいサイズ（20バイト）にハッシュされます。しかし、エントロピーは特に長いもので、パスフレーズで、一般的に希薄であるので、これは長いパスフレーズを持つユーザーのまれなケースでは問題にならないかもしれません。
Also, generating a 256-bit key from a pass phrase of any length may be deceptive, as the effective entropy in pass-phrase-derived key cannot be nearly that large given the properties of the string-to-key function described here.
パスフレーズ派生鍵に有効なエントロピーは、ここで説明ストリングからキー機能の性質所与ほぼその大きいことはできないとしても、任意の長さのパスフレーズから256ビットの鍵を生成することは、虚偽であってもよいです。
The iteration count in PBKDF2 appears to be useful primarily as a constant multiplier for the amount of work required for an attacker using brute-force methods. Unfortunately, it also multiplies, by the same amount, the work needed by a legitimate user with a valid password. Thus the work factor imposed on an attacker (who may have many powerful workstations at his disposal) must be balanced against the work factor imposed on the legitimate user (who may have a PDA or cell phone); the available computing power on either side increases as time goes on, as well. A better way to deal with the brute-force attack is through preauthentication mechanisms that provide better protection of the user's long-term key. Use of such mechanisms is out of the scope of this document.
PBKDF2での繰り返し回数は、主にブルートフォースメソッドを使用して、攻撃者に必要な作業量のための定数乗算器として有用であることが表示されます。残念ながら、それはまた、同じ量、有効なパスワードを持つ正当なユーザーが必要とする作業で、乗じます。したがって、（彼の処分で多くの強力なワークステーションを有していてもよい）、攻撃者に課せられた仕事率は、（PDAや携帯電話を持っている場合があります）、正当な利用者に課せられた仕事率に対してバランスをとらなければなりません。時間などのいずれかの側に増加に利用可能なコンピューティングパワーだけでなく、に行きます。ブルートフォース攻撃に対処するための良い方法は、ユーザの長期的なキーのより良い保護を提供する事前認証メカニズムを通じてです。そのようなメカニズムの使用は、この文書の範囲外です。
If a site does wish to use this means of protection against a brute-force attack, the iteration count should be chosen based on the facilities available to both attacker and legitimate user, and the amount of work the attacker should be required to perform to acquire the key or password.
サイトがブルートフォース攻撃に対する保護のこの手段を使用したいならば、反復回数は、攻撃者と正規ユーザの両方に利用できる施設に基づいて選択しなければならない、と仕事の量は、攻撃者が取得するために実行するために必要とされなければなりませんキーまたはパスワード。
As an example:
例として：
The author's tests on a 2GHz Pentium 4 system indicated that in one second, nearly 90,000 iterations could be done, producing a 256-bit key. This was using the SHA-1 assembly implementation from OpenSSL, and a pre-release version of the PBKDF2 code for MIT's Kerberos package, on a single system. No attempt was made to do multiple hashes in parallel, so we assume an attacker doing so can probably do at least 100,000 iterations per second -- rounded up to 2**17, for ease of calculation. For simplicity, we also assume the final AES encryption step costs nothing.
2GHz以上のPentium 4システム上の著者のテストは1秒で、ほぼ90,000回の反復が256ビットの鍵を生成する、行うことができることが示されました。これは、単一のシステム上でのOpenSSLからSHA-1アセンブリの実装、およびMITのKerberosパッケージのPBKDF2コードのプレリリース版を使用していました。試みは、並列に複数のハッシュを行うために行われていないので、我々はそうする攻撃者は、おそらく毎秒少なくとも100,000個の反復を行うことができますと仮定した - 計算を容易にするために、2 ** 17に切り上げました。簡単にするために、我々はまた、最終的なAES暗号化ステップ費の何を負いません。
Paul Leach estimates [LEACH] that a password-cracking dictionary may have on the order of 2**21 entries, with capitalization, punctuation, and other variations contributing perhaps a factor of 2**11, giving a ballpark estimate of 2**32.
パスワードクラッキング辞書2の球場推定値を与え、大文字、句読点、およびおそらくは2 ** 11の因数に寄与する他の変形例で、2つの** 21エントリの順序で有していてもよいことポールリーチ推定[LEACH] ** 32。
Thus, for a known iteration count N and a known salt string, an attacker with some number of computers comparable to the author's would need roughly N*2**15 CPU seconds to convert the entire dictionary plus variations into keys.
このように、知られている反復回数Nと知られている塩文字列のために、著者のに匹敵するコンピュータのいくつかの番号を持つ攻撃者は、キーに全体の辞書プラスの変化を変換するために、およそN * 2 ** 15 CPU秒を必要とします。
An attacker using a dozen such computers for a month would have roughly 2**25 CPU seconds available. So using 2**12 (4,096) iterations would mean an attacker with a dozen such computers dedicated to a brute-force attack against a single key (actually, any password-derived keys sharing the same salt and iteration count) would process all the variations of the dictionary entries in four months and, on average, would likely find the user's password in two months.
月のダース、このようなコンピュータを使用して攻撃者が利用できる約2 ** 25 CPU秒を持っているでしょう。だから、（実際には、同じ塩と繰り返し回数を共有する任意のパスワード由来の鍵）は、すべてのプロセスでしょう単一のキーに対するブルートフォース攻撃に捧げダース、コンピュータで攻撃を意味するであろう2 ** 12（4096）の反復を使用して平均して4ヶ月で辞書エントリのバリエーションとは、おそらく2ヶ月でユーザーのパスワードを見つけるだろう。
Thus, if this form of attack is of concern, users should be required to change their passwords every few months, and an iteration count a few orders of magnitude higher should be chosen. Perhaps several orders of magnitude, as many users will tend to use the shorter and simpler passwords (to the extent they can, given a site's password quality checks) that the attacker would likely try first.
この形式の攻撃が懸念される場合にはこのように、ユーザーは数ヶ月ごとにパスワードの変更を必要としなければならない、と繰り返し、より高い数桁を選択する必要があります数えます。おそらく、数桁、できるだけ多くのユーザーには、攻撃者はおそらく最初に試すだろうと（彼らができる限り、サイトのパスワード品質チェックを与えられたに）短く、単純なパスワードを使用する傾向があります。
Since this estimate is based on currently available CPU power, the iteration counts used for this mode of defense should be increased over time, at perhaps 40%-60% each year or so.
この推定値は、現在利用可能なCPUパワーに基づいているので、守備のこのモードで使用反復回数は、おそらく40％-60％、それぞれ1年かそこらで、経時的に増加する必要があります。
Note that if the attacker has a large amount of storage available, intermediate results could be cached, saving a lot of work for the next attack with the same salt and a greater number of iterations than had been run at the point where the intermediate results were saved. Thus, it would be wise to generate a new random salt string when passwords are changed. The default salt string, derived from the principal name, only protects against the use of one dictionary of keys against multiple users.
攻撃者が使用可能なストレージの大容量を持っている場合、中間結果であった時点で実行されていたよりも、中間結果は同じ塩と次の攻撃や繰り返しのより多くのために多くの作業を保存し、キャッシュすることができることに注意してください保存されました。したがって、パスワードが変更され、新たなランダムなsalt文字列を生成することが賢明だろう。プリンシパル名に由来し、デフォルトの塩文字列は、唯一、複数のユーザに対してキーのいずれかの辞書の使用から保護します。
If the PBKDF2 iteration count can be spoofed by an intruder on the network, and the limit on the accepted iteration count is very high, the intruder may be able to introduce a form of denial of service attack against the client by sending a very high iteration count, causing the client to spend a great deal of CPU time computing an incorrect key.
PBKDF2繰り返し回数は、ネットワーク上の侵入者によって詐称することができ、かつ受け入れられた反復回数の制限が非常に高い場合、侵入者は非常に高い反復を送信することによって、クライアントに対するサービス拒否攻撃の形を導入することができるかもしれませんクライアントが間違ったキーを計算するCPU時間の多くを過ごすために引き起こして、数えます。
An intruder spoofing the KDC reply, providing a low iteration count and reading the client's reply from the network, may be able to reduce the work needed in the brute-force attack outlined above. Thus, implementations may seek to enforce lower bounds on the number of iterations that will be used.
低反復カウントを提供し、ネットワークからクライアントの回答を読んで、KDC応答を偽装侵入者は、上記で概説したブルートフォース攻撃に必要な作業を削減することができます。従って、実装が使用される反復の数に下限を強制しようとすることができます。
Since threat models and typical end-user equipment will vary widely from site to site, allowing site-specific configuration of such bounds is recommended.
脅威モデルとそのような境界の部位特異的な構成を可能にする、サイトからサイトに広く変化するであろう典型的なエンドユーザ機器ので推奨されます。
Any benefit against other attacks specific to the HMAC or SHA-1 algorithms is probably achieved with a fairly small number of iterations.
HMACまたはSHA-1アルゴリズムに固有のその他の攻撃に対する任意の利点は、おそらく反復かなり少数で達成されます。
In the "optimistic preauthentication" case mentioned in section 3, the client may attempt to produce a key without first communicating with the KDC. If the client has no additional information, it can only guess as to the iteration count to be used. Even such heuristics as "iteration count X was used to acquire tickets for the same principal only N hours ago" can be wrong. Given the recommendation above for increasing the iteration counts used over time, it is impossible to recommend any specific default value for this case; allowing site-local configuration is recommended. (If the lower and upper bound checks described above are implemented, the default count for optimistic preauthentication should be between those bounds.)
セクション3で述べた「楽観事前認証」場合には、クライアントは、最初のKDCと通信することなく鍵を生成しようと試みることができます。クライアントは、追加の情報を持っていない場合は、それだけで使用される反復回数にと推測することができます。 「反復回数XだけN時間前同じ主体のチケットを取得するために使用された」などであっても、そのようなヒューリスティックが間違っている可能性があります。時間をかけて使用し、反復回数を増やすための上記勧告を考えると、この場合の任意の特定のデフォルト値をお勧めすることは不可能です。サイトローカルコンフィギュレーションが可能にすることをお勧めします。 （上述の下限と上限チェックが実装されている場合、楽観事前認証のためのデフォルト数は、これらの範囲の間であるべきです。）
Ciphertext stealing mode, as it requires no additional padding in most cases, will reveal the exact length of each message being encrypted rather than merely bounding it to a small range of possible lengths as in CBC mode. Such obfuscation should not be relied upon at higher levels in any case; if the length must be obscured from an outside observer, this should be done by intentionally varying the length of the message to be encrypted.
モードを盗む暗号文は、それはほとんどの場合、追加のパディングを必要としないように、むしろ単にCBCモードと可能な長さの小さい範囲に境界よりも、暗号化された各メッセージの正確な長さを明らかにする。そのような難読化は、いずれの場合に高いレベルで依拠すべきではありません。長さが外部の観察者から隠さなければならない場合、これは意図的に暗号化されるメッセージの長さを変化させることによって行われるべきです。
Kerberos encryption and checksum type values used in section 7 were previously reserved in [KCRYPTO] for the mechanisms defined in this document. The registries have been updated to list this document as the reference.
セクション7で用いたKerberos暗号化とチェックサムタイプ値は、以前にこの文書で定義されたメカニズムのために[KCRYPTO]に確保しました。レジストリは、参考としてこのドキュメントを一覧表示するように更新されました。
Thanks to John Brezak, Gerardo Diaz Cuellar, Ken Hornstein, Paul Leach, Marcus Watts, Larry Zhu, and others for feedback on earlier versions of this document.
ジョンBrezak、ヘラルド・ディアスクエリャル、ケンHornstein、ポールリーチ、マーカス・ワッツ、ラリー朱、およびこのドキュメントの以前のバージョンへのフィードバックのために他の人に感謝します。
A. Errata for
A.エラッタについて
(Copied from the RFC Editor's errata web site on July 8, 2004.)
（7月8日、2004年にRFC編集者の正誤表のWebサイトからコピー）
Reported By: Bob Baldwin; baldwin@plusfive.com Date: Fri, 26 Mar 2004 06:49:02 -0800
報告：ボブ・ボールドウィン。 baldwin@plusfive.com日付：金、2004年3月26日6時49分02秒-0800
In Section 8, Description of RC5-CTS, of the encryption method, it says:
第8章では、RC5 - CTSの説明は、暗号化の方法、それは言います：
1. Exclusive-or Pn-1 with the previous ciphertext
block, Cn-2, to create Xn-1.
It should say:
それは言う必要があります。
1. Exclusive-or Pn-1 with the previous ciphertext
block, Cn-2, to create Xn-1. For short messages where
Cn-2 does not exist, use IV.
Reported By: Bob Baldwin; baldwin@plusfive.com Date: Mon, 22 Mar 2004 20:26:40 -0800
報告：ボブ・ボールドウィン。 baldwin@plusfive.com日：月、2004年3月22日夜08時26分40秒-0800
In Section 8, first paragraph, second sentence says:
第8章、最初の段落では、2番目の文が書かれています：
This mode handles any length of plaintext and produces ciphertext
whose length matches the plaintext length.
In Section 8, first paragraph, second sentence should read:
第8章、最初の段落では、第二の文を読んでください。
This mode handles any length of plaintext longer than one
block and produces ciphertext whose length matches the
plaintext length.
In Section 8, step 6 of the decryption method says:
第8章では、復号化方法のステップ6は述べています：
In Section 8, step 6 of the decryption method should read:
セクション8では、復号方法のステップ6を読んでください。
6. Decrypt En and exclusive-or with Cn-2 to create Pn-1.
For short messages where Cn-2 does not exist, use the IV.
B. Sample Test Vectors
B.サンプルテストベクトル
Sample values for the PBKDF2 HMAC-SHA1 string-to-key function are included below.
PBKDF2 HMAC-SHA1の文字列からキーへの機能のサンプル値は、以下に含まれています。
Iteration count = 1 Pass phrase = "password" Salt = "ATHENA.MIT.EDUraeburn" 128-bit PBKDF2 output: cd ed b5 28 1b b2 f8 01 56 5a 11 22 b2 56 35 15 128-bit AES key: 42 26 3c 6e 89 f4 fc 28 b8 df 68 ee 09 79 9f 15 256-bit PBKDF2 output: cd ed b5 28 1b b2 f8 01 56 5a 11 22 b2 56 35 15 0a d1 f7 a0 4b b9 f3 a3 33 ec c0 e2 e1 f7 08 37 256-bit AES key: fe 69 7b 52 bc 0d 3c e1 44 32 ba 03 6a 92 e6 5b bb 52 28 09 90 a2 fa 27 88 39 98 d7 2a f3 01 61
繰り返し回数= 1つのパスフレーズ= "パスワード" ソルト= "ATHENA.MIT.EDUraeburnが" 128ビットPBKDF2出力：CD用のED B5キー28 1B B2 F8 01 56 5A 11 22 B2 56 35 15 128ビットAES：42 26 3C 6E 89 F4 FC 28 B8 68 EE 09 79 9F 15 256ビットPBKDF2出力DF：CD用のED B5 28 1B B2 F8 01 56 5A 11 22 B2 56 35 15 0A D1 F7 A0 4bはB9の33 EC C0 E2 E1 F7 08 A3 F3キー37、256ビットAES：FE 69 7B 52 BC 0D 3C E1 44 32 BA 03 6A 92 E6 5BのB-B 52 28 09 90 A2 FA 27 88 39 98 D7 2aはF3 01 61
Iteration count = 2 Pass phrase = "password" Salt="ATHENA.MIT.EDUraeburn" 128-bit PBKDF2 output: 01 db ee 7f 4a 9e 24 3e 98 8b 62 c7 3c da 93 5d 128-bit AES key: c6 51 bf 29 e2 30 0a c2 7f a4 69 d6 93 bd da 13 256-bit PBKDF2 output: 01 db ee 7f 4a 9e 24 3e 98 8b 62 c7 3c da 93 5d a0 53 78 b9 32 44 ec 8f 48 a9 9e 61 ad 79 9d 86 256-bit AES key: a2 e1 6d 16 b3 60 69 c1 35 d5 e9 d2 e2 5f 89 61 02 68 56 18 b9 59 14 b4 67 c6 76 22 22 58 24 ff
繰り返し回数= 2パスフレーズ= "パスワード" ソルト= "ATHENA.MIT.EDUraeburn" 128ビットPBKDF2出力：01デシベルEE 7F 4A 9E 24 3E 98 8B 62 C7 3Cダ93 5D 128ビットAESキー：51 BF C6 29 E2 30 0A C2 7F A4 69 D6 93 BD DA 13 256ビットPBKDF2出力：53 78 B9 32 44 EC 8F 48 A9 9E 61広告79 9D A0 01デシベルEE 7F 4A 9E 24 3E 98 8B 62 C7 3C DA 93 5D 86 256ビットのAES鍵：A2 E1 6D 16 B3 60 69 C1 35 D5 E9 D2 E2 5F 89 61 02 68 56 18 B9 59 14 B4 67 C6 76 22 22個の58個の24 FF
Iteration count = 1200 Pass phrase = "password" Salt = "ATHENA.MIT.EDUraeburn" 128-bit PBKDF2 output: 5c 08 eb 61 fd f7 1e 4e 4e c3 cf 6b a1 f5 51 2b 128-bit AES key: 4c 01 cd 46 d6 32 d0 1e 6d be 23 0a 01 ed 64 2a 256-bit PBKDF2 output: 5c 08 eb 61 fd f7 1e 4e 4e c3 cf 6b a1 f5 51 2b a7 e5 2d db c5 e5 14 2f 70 8a 31 e2 e6 2b 1e 13 256-bit AES key: 55 a6 ac 74 0a d1 7b 48 46 94 10 51 e1 e8 b0 a7 54 8d 93 b0 ab 30 a8 bc 3f f1 62 80 38 2b 8c 2a
= 1200パスフレーズ= "パスワード" 反復回数塩= "ATHENA.MIT.EDUraeburn" 128ビットのPBKDF2出力：A1 F5 6bを図5c 08 EB 61 FD F7 1E 4E 4E C3 CF 51 2bの128ビットのAESキー：4C 01 CD図5c 08 EB 61 FD F7 1E 4E 4E C3 A1 F5 6B CF 51 2B A7 E5の2D DB C5 E5 14 2F 70 8A 31 E2 E6 2B 1E：46 D6 32 D0 1eは23 0A 01 ED 64 2Aの256ビットPBKDF2出力である6dは13 256ビットのAES鍵：55 A6 AC 74 0Aさd1 7B 48 46 94 10 51 E1〜E8のB0のA7 54 8D 93 B0 AB 30 A8 BC 3F F1 62 80 38 2B 8C 2A
Iteration count = 5 Pass phrase = "password" Salt=0x1234567878563412 128-bit PBKDF2 output: d1 da a7 86 15 f2 87 e6 a1 c8 b1 20 d7 06 2a 49 128-bit AES key: e9 b2 3d 52 27 37 47 dd 5c 35 cb 55 be 61 9d 8e 256-bit PBKDF2 output: d1 da a7 86 15 f2 87 e6 a1 c8 b1 20 d7 06 2a 49 3f 98 d2 03 e6 be 49 a6 ad f4 fa 57 4b 6e 64 ee 256-bit AES key: 97 a4 e7 86 be 20 d8 1a 38 2d 5e bc 96 d5 90 9c ab cd ad c8 7c a4 8f 57 45 04 15 9f 16 c3 6e 31 (This test is based on values given in [PECMS].)
繰り返し回数= 5つのパスフレーズ= "パスワード" 塩= 0x1234567878563412 128ビットのPBKDF2出力：D1ダA7 86 15 F2 87 E6 A1はC8 b1のキー20 D7 06 2A 49 128ビットのAES：E9 B2 3D 52 27 37 47 DD部5c 35 CB 55である61 9D 8E PBKDF2出力256ビット：20 D7 06 2A 49 3F 98 D2 03 E6 D1ダA7 86 15 F2 87 E6 A1のC8 b1は49 A6広告F4 FA 57 4B 6E 64 EE 256ビットのAES鍵であります：97 A4 E7 86である20 D8 1A 38 2D 5E BC 15 9F 16 C3 6E 31 96 D5 90 9C AB、CD広告C8 7cとのA4サイズ8F 57 45 04（この試験は、[PECMS]で与えられた値に基づいています。）
Iteration count = 1200 Pass phrase = (64 characters) "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" Salt="pass phrase equals block size" 128-bit PBKDF2 output: 13 9c 30 c0 96 6b c3 2b a5 5f db f2 12 53 0a c9 128-bit AES key: 59 d1 bb 78 9a 82 8b 1a a5 4e f9 c2 88 3f 69 ed 256-bit PBKDF2 output: 13 9c 30 c0 96 6b c3 2b a5 5f db f2 12 53 0a c9 c5 ec 59 f1 a4 52 f5 cc 9a d9 40 fe a0 59 8e d1 256-bit AES key: 89 ad ee 36 08 db 8b c7 1f 1b fb fe 45 94 86 b0 56 18 b7 0c ba e2 20 92 53 4e 56 c5 53 ba 4b 34
反復回数= 1200パスフレーズ=（64文字） "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" 塩= 128ビットPBKDF2出力 "パスフレーズがブロックサイズに等しい"：13 9C 30 C0 96 6B C3 2B A5 5F DB F2 12 53 0AのC9 128ビットAESキー：59 D1 BB 78 9A 82 8B 1A A5 4E F9 C2 88 3F 69編256ビットPBKDF2出力：52 F5のCC 9aはD9 40 A4 13 9C 30 C0 96 6B C3 2B A5 5F DB F2 12 53 0A C9、C5 EC 59 F1 89広告EE 36 08デシベル8B C7 1F 1B FB FE 45 94 86 56 18 B0 B7 0CのBAのE2 20 92 53 4E 56 C5 53 BA 4B 34：FEはキー59 8E D1 256ビットAESをA0
Iteration count = 1200 Pass phrase = (65 characters) "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" Salt = "pass phrase exceeds block size" 128-bit PBKDF2 output: 9c ca d6 d4 68 77 0c d5 1b 10 e6 a6 87 21 be 61 128-bit AES key: cb 80 05 dc 5f 90 17 9a 7f 02 10 4c 00 18 75 1d 256-bit PBKDF2 output: 9c ca d6 d4 68 77 0c d5 1b 10 e6 a6 87 21 be 61 1a 8b 4d 28 26 01 db 3b 36 be 92 46 91 5e c8 2a 256-bit AES key: d7 8c 5c 9c b8 72 a8 c9 da d4 69 7f 0b b5 b2 d2 14 96 c8 2b eb 2c ae da 21 12 fc ee a0 57 40 1b
反復回数= 1200パスフレーズ=（65文字） "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" 塩= 128ビットPBKDF2出力 "パスフレーズは、ブロックサイズを超える"：9CカリフォルニアD6のD4 68 77 0C D5 1B 10 E6 A6 87 21 61 128ビットのAES鍵であります：CB 80 05 DC 5F 90 17 9A 7F 02 10 4C 00 18 75 1D 256ビットPBKDF2出力：9CのCA D6のD4 68 77 0C D5 1B 10 E6のA6は87 21 3B 36は、92であることがDB 61 1A 8B 4D 28 26 01でありますキー46 91 5E C8 2aの256ビットAES：57 40 1B A0 D7 8C 5C 9C B8 72 A8 C9 DA D4 69 7F 0B B5 B2 D2 14 96 C8 2BのEB 2cはAEダ21 12 FC EE
Iteration count = 50 Pass phrase = g-clef (0xf09d849e) Salt = "EXAMPLE.COMpianist" 128-bit PBKDF2 output: 6b 9c f2 6d 45 45 5a 43 a5 b8 bb 27 6a 40 3b 39 128-bit AES key: f1 49 c1 f2 e1 54 a7 34 52 d4 3e 7f e6 2a 56 e5 256-bit PBKDF2 output: 6b 9c f2 6d 45 45 5a 43 a5 b8 bb 27 6a 40 3b 39 e7 fe 37 a0 c4 1e 02 c2 81 ff 30 69 e1 e9 4f 52 256-bit AES key: 4b 6d 98 39 f8 44 06 df 1f 09 cc 16 6d b4 b8 3c 57 18 48 b7 84 a3 d6 bd c3 46 58 9a 3e 39 3f 9e
反復回数= 50のパスフレーズ= G-音部記号（0xf09d849e）塩= "EXAMPLE.COMpianist" 128ビットPBKDF2出力：27 6A 40 3B 39 128ビットのAES鍵BB 6B 9C F2 6D 45 45 5A 43 A5 B8：F1 49 C1 F2 E1 54 A7 34 52 D4 3E 7F E6 2A 56 E5 256ビットPBKDF2出力：6B 9C F2 6D 45 45 5A 43 A5 B8 BB 27 6aを40 3B 39 E7 FE 37 A0 C4 1E 02 C2 81 FF 30 69 E1〜E9 4F 52 256ビットのAES鍵：1F 09 CC 16 6DのB4〜B8 3C 57 18 48 B7 84 A3 D6のBDのC3 DF 4B部6d 98 39 F8 44 06 46 58 9A 3E 39 3F 9E
Some test vectors for CBC with ciphertext stealing, using an initial vector of all-zero.
すべてゼロの初期ベクトルを用いて暗号文窃盗とCBCのためにいくつかのテストベクトル、。
AES 128-bit key: 0000: 63 68 69 63 6b 65 6e 20 74 65 72 69 79 61 6b 69
AC 128ビット岸壁：0000：オメガ68オメガshtya IIIbを65 20 65 72 61 shtya shtya IIIb族shtyaをshtchます
IV: 0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Input: 0000: 49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65 0010: 20 Output: 0000: c6 35 35 68 f2 bf 8c b4 d8 a5 80 36 2d a7 ff 7f 0010: 97 Next IV: 0000: c6 35 35 68 f2 bf 8c b4 d8 a5 80 36 2d a7 ff 7f
IV：0000：00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00入力20出力：0000：C6 35 35 0000 68 65 0010 49 20 77 6F 75 6C 64 20 6C 69 6B 65 20 74 0010 7F FF A7 68 F2 BF 8C B4 D8 A5 80 36 2D：97次のページIV：0000：80 36 2D A7 FF 7F A5 35 35 68 C6 F2 BF 8cとB4とのD8
IV: 0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Input: 0000: 49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65 0010: 20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 Output: 0000: fc 00 78 3e 0e fd b2 c1 d4 45 d4 c8 ef f7 ed 22 0010: 97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 Next IV: 0000: fc 00 78 3e 0e fd b2 c1 d4 45 d4 c8 ef f7 ed 22
IV：0000：00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00入力：0000：49 20 77 6F 75 6C 64 20 6C 69 6B 65 20 74 68 65 0010 20 47 65 6E 65 72 61 6C 0000：出力20 47 61 75 27 73 20 97 68 72 68 D6 ECのCC C0 C0と7B 25 E2 5EのCF E5次にIV：0000：FC 00 78 3E 0E FD B2とC1はD4 45 D4 C8 EF F7は0010 22編FCを00 78 3E 0E FD B2 C1 D4 45 D4 C8 EF F7 ED 22
IV: 0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Input: 0000: 49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65 0010: 20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43 Output: 0000: 39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8 0010: 97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84 Next IV: 0000: 39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8
IV：0000：00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00入力：0000：49 20 77 6F 75 6C 64 20 6C 69 6B 65 20 74 68 65 0010 20 47 65 6E 65 72 61 6C 39 31 25 23 A7 86 62 D5ことが7FのCB、CC 98 EB 0010 F5のA8：97 68 72 68 D6 ECのCC C0 C0と7B 25 E2 5EのCF E5 84次にIV：0000 0000：出力20 47 61 75 27 73 20 43 ：39 31 25 23 A7 86 62は7FのCB、CC 98 EB F5 A8ことD5
IV: 0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Input: 0000: 49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65 0010: 20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43 0020: 68 69 63 6b 65 6e 2c 20 70 6c 65 61 73 65 2c Output: 0000: 97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84 0010: b3 ff fd 94 0c 16 a1 8c 1b 55 49 d2 f8 38 02 9e 0020: 39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 Next IV: 0000: b3 ff fd 94 0c 16 a1 8c 1b 55 49 d2 f8 38 02 9e
IV：0000：00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00入力：0000：49 20 77 6F 75 6C 64 20 6C 69 6B 65 20 74 68 65 0010 20 47 65 6E 65 72 61 6C 73 20 43 0020 20 47 61 75 27 68 69 63 6B 65 6E 2C 20 70 6C 65 61 73 65 2cの出力：0000：97 68 72 68 D6 ECのCC C0 C0と7B 25 E2 5EのCF E5 84 0010：B3 FF FD 94 0C 16 A1 8C 1B 55 49 38 02 9E 0020 D2のF8：0000：39 31 25 23 A7 86 62 D5は7FのCB、CC 98 EB F5次にIVことB3 FF FD 94 0C 16 A1 8C 1B 55 49 D2のF8 38 02 9E
IV: 0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Input: 0000: 49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65 0010: 20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43 0020: 68 69 63 6b 65 6e 2c 20 70 6c 65 61 73 65 2c 20 Output: 0000: 97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84 0010: 9d ad 8b bb 96 c4 cd c0 3b c1 03 e1 a1 94 bb d8 0020: 39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8 Next IV: 0000: 9d ad 8b bb 96 c4 cd c0 3b c1 03 e1 a1 94 bb d8
IV：0000：00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00入力：0000：49 20 77 6F 75 6C 64 20 6C 69 6B 65 20 74 68 65 0010 20 47 65 6E 65 72 61 6C 73 20 43 0020 20 47 61 75 27 68 69 63 6B 65 6E 2C 20 70 6C 65 61 73 65 2C 20出力：0000：97 68 72 68 D6 ECのCC C0 C0と7B 25 E2 5EのCF E5 84 0010：9（d）広告図8b BB 96 C4 CD C0 3bとC1を03 E1 A1 94のBB D8 0020：0000：C4 96 BB CD C0 3bとC1を03 E1 A1 8B 9D広告39 31 25 23 A7 86 62 D5 7F CB、CC 98のEB F5 A8次にIVこと94 BBのD8
IV: 0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Input: 0000: 49 20 77 6f 75 6c 64 20 6c 69 6b 65 20 74 68 65 0010: 20 47 65 6e 65 72 61 6c 20 47 61 75 27 73 20 43 0020: 68 69 63 6b 65 6e 2c 20 70 6c 65 61 73 65 2c 20 0030: 61 6e 64 20 77 6f 6e 74 6f 6e 20 73 6f 75 70 2e Output: 0000: 97 68 72 68 d6 ec cc c0 c0 7b 25 e2 5e cf e5 84 0010: 39 31 25 23 a7 86 62 d5 be 7f cb cc 98 eb f5 a8 0020: 48 07 ef e8 36 ee 89 a5 26 73 0d bc 2f 7b c8 40 0030: 9d ad 8b bb 96 c4 cd c0 3b c1 03 e1 a1 94 bb d8 Next IV: 0000: 48 07 ef e8 36 ee 89 a5 26 73 0d bc 2f 7b c8 40
IV：0000：00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00入力：0000：49 20 77 6F 75 6C 64 20 6C 69 6B 65 20 74 68 65 0010 20 47 65 6E 65 72 61 6C 73 20 43 0020 20 47 61 75 27 68 69 63 6B 65 6E 2C 20 70 6C 65 61 73 65 2C 20 0030：61 6E 64 20 77 6F 6E 74 6F 6E 20 73 6F 75 70 2E出力：0000：97 68 48 07のEF E8 36 EE 89 A5 26 73 0DのBC 2F 7bとのC8 40：39 31 25 23 A7 86 62 7FのCB、CC 98のEBのF5 A8 0020であるD5：ECのCC C0 C0と7B 25 E2 5E CF E5 84 0010 72 68 D6 0030：0000：48 07 EFのE8 36 EE 89 A5 26 73 0D BC 2F 7bはC8 40 96 C4 CD C0 3B C1 03 E1 A1 94 BB D8次にIV BB 8B 9D広告
Normative References
引用規格
[AC] Schneier, B., "Applied Cryptography", second edition, John Wiley and Sons, New York, 1996.
[AC]シュナイアー、B.、 "Applied Cryptography"、第2版、John Wiley and Sons、ニューヨーク、1996年。
[AES] National Institute of Standards and Technology, U.S. Department of Commerce, "Advanced Encryption Standard", Federal Information Processing Standards Publication 197, Washington, DC, November 2001.
[AES]アメリカ国立標準技術研究所、米国商務省が、「高度暗号化規格」、連邦情報処理規格出版197、ワシントンD.C.、2001年11月。
[KCRYPTO] Raeburn, K., "Encryption and Checksum Specifications for Kerberos 5", RFC 3961, February 2005.
[KCRYPTO]レイバーン、K.、 "暗号化とケルベロス5チェックサムの仕様"、RFC 3961、2005年2月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[PKCS5] Kaliski, B., "PKCS #5: Password-Based Cryptography Specification Version 2.0", RFC 2898, September 2000.
[PKCS5] Kaliski、B.、 "PKCS＃5：パスワードベースの暗号化仕様バージョン2.0"、RFC 2898、2000年9月。
[RC5] Baldwin, R. and R. Rivest, "The RC5, RC5-CBC, RC5-CBC-Pad, and RC5-CTS Algorithms", RFC 2040, October 1996.
[RC5]ボールドウィン、R.及びR.リベスト、 "RC5、RC5-CBC、RC5-CBC-パッド、およびRC5-CTSアルゴリズム"、RFC 2040、1996年10月。
[SHA1] National Institute of Standards and Technology, U.S. Department of Commerce, "Secure Hash Standard", Federal Information Processing Standards Publication 180-1, Washington, DC, April 1995.
[SHA1]アメリカ国立標準技術研究所、商業の米国部門は、連邦情報処理規格180-1出版、ワシントンD.C.、1995年4月「ハッシュ標準セキュア」。
Informative References
参考文献
[LEACH] Leach, P., email to IETF Kerberos working group mailing list, 5 May 2003, ftp://ftp.ietf.org/ietf-mail-archive/krb-wg/2003-05.mail.
[LEACH]リーチ、P.、IETFケルベロスワーキンググループメーリングリスト、2003年5月5日に電子メール、ftp://ftp.ietf.org/ietf-mail-archive/krb-wg/2003-05.mail。
[PECMS] Gutmann, P., "Password-based Encryption for CMS", RFC 3211, December 2001.
[PECMS] Gutmann氏、P.、 "CMSのパスワードベースの暗号化"、RFC 3211、2001年12月。
Author's Address
著者のアドレス
Kenneth Raeburn Massachusetts Institute of Technology 77 Massachusetts Avenue Cambridge, MA 02139
テクノロジーのケネス・レイバーンマサチューセッツ工科大学77マサチューセッツアベニューケンブリッジ、MA 02139
EMail: raeburn@mit.edu
メールアドレス：raeburn@mit.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 IETF文書の権利に関するIETFの手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。