RFC3962 日本語訳
3962 Advanced Encryption Standard (AES) Encryption for Kerberos 5. K.Raeburn. February 2005. (Format: TXT=32844 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group K. Raeburn Request for Comments: 3962 MIT Category: Standards Track February 2005
コメントを求めるワーキンググループK.レイバーンの要求をネットワークでつないでください: 3962年のMITカテゴリ: 標準化過程2005年2月
Advanced Encryption Standard (AES) Encryption for Kerberos 5
ケルベロス5のためのエー・イー・エス(AES)暗号化
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(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)は新しいエー・イー・エス(AES)を選びました、とどちらがかなり速いか、そして、(それは信じられています)以上は古いデータ暗号化規格(DES)アルゴリズムより安全にします。 このドキュメントはケルベロス暗号系スイートへのこのアルゴリズムの添加のための仕様です。
1. Introduction
1. 序論
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.
このドキュメントは、ケルベロス5のために最近NISTによって選ばれたAESアルゴリズムを使用することで暗号化キーとチェックサムタイプを定義します。これらの新しいタイプは128ビットか256ビットの128ビットのブロック暗号化と主要なサイズを支持します。
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]の「簡易型のプロフィール」を使用して、私たちは1組の暗号化とチェックサム計画を定義できます。 AESはメッセージ拡大を避けるのに暗号文窃盗と共に使用されます、そして、SHA-1[SHA1]は関連チェックサム機能です。
2. Conventions used in this Document
2. このDocumentで使用されるコンベンション
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14RFC2119[キーワード]で説明されるように本書では解釈されることであるべきです。
Raeburn Standards Track [Page 1] RFC 3962 AES Encryption for Kerberos 5 February 2005
ケルベロス2005年2月5日のレイバーン標準化過程[1ページ]RFC3962AES暗号化
3. Protocol Key Representation
3. プロトコルキー表現
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]で説明されたキーのバイト表現を使用します。
4. Key Generation from Pass Phrases or Random Data
4. パス句か無作為のデータからのキー生成
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#5v2.0([PKCS5])からPBKDF2機能を使用します、パラメタが以下で示されている状態で中間的キー(必要な最終的なキーと同じ長さの)を発生させるように、DKは[KCRYPTO]でdes3-cbc- hmac-sha1-kdのために行われる8八重奏のASCIIストリング"kerberos"で機能します。(次に、キーは入られます)。 ([KCRYPTO]用語で、PBKDF2機能は「無作為の八重奏ストリング」を生産して、それですが、したがって、事実上、主要な機能への無作為のアプリケーションは簡単な一致演算です。) 結果として起こるキーは暗号化アルゴリズムがはっきりしていない使用のためのユーザの長期のキーです。
tkey = random2key(PBKDF2(passphrase, salt, iter_count, keylength)) key = DK(tkey, "kerberos")
tkeyはrandom2key(PBKDF2(パスフレーズ、塩、iter_カウント、keylength))主要な=DKと等しいです。(tkey、"kerberos")
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.
PBKDF2によって使用された擬似ランダム機能はAppendix B.1でPKCS#5まで説明されるようにパスフレーズと塩の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であるなら、実行されるべき繰り返しの数は42億9496万7296(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.
より遅いハードウェアが標準である環境を、ケルベロスなどのプロトコルの実現は攻撃者によって供給されただまされた応答が多くのクライアントサイドCPU時間を費やすのを防ぐために、繰り返しの数を制限したがっているかもしれません。 限界はそのようなものであるなら実行されて、それはSHOULDです。少なくとも5万になってください。 速いハードウェアがある環境においてさえ、40億繰り返しはかなり長い時かかりそうです。 はるかに大きい領域はまだ励行されているかもしれません、そして、環境がそれを考慮するなら、実現がユーザによるこの操作の中断を可能にするのは、賢明であるかもしれません。
Raeburn Standards Track [Page 2] RFC 3962 AES Encryption for Kerberos 5 February 2005
ケルベロス2005年2月5日のレイバーン標準化過程[2ページ]RFC3962AES暗号化
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(4,096繰り返しを示す10進4,096)です。
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とコミュニケートしていなくて主要な長い期間を使用することでタイムスタンプベースの前認証を試みる)で使用されるためには要件か推薦でさえないことに注意してください。 KDCにそれを提供する機会があったとき、それは単にストリングからキーへのパラメタ分野の欠如の解釈です。
Sample test vectors are given in Appendix B.
Appendix Bで試供品テストベクトルを与えます。
5. Ciphertext Stealing
5. 暗号文窃盗
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.
暗号ブロック連鎖は、初期ベクトルが暗号状態に格納されている状態でメッセージをコード化するのに使用されます。 前のケルベロス暗号系と異なって、私たちは、メッセージのことによると部分的な最終的なブロックを扱うのに暗号文窃盗を使用します。
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.
暗号文窃盗は195-196ページの[西暦]、および[RC5]のセクション8で説明されます。 それには、詰め物でCBCモードで通常して、メッセージ拡大が全く任意のサイズに関するメッセージの暗号化の間にそのままで行われない利点があります。 [RC5]はAppendix 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]で定義される暗号文窃盗は、1ブロック以上のプレーンテキストが利用可能であると仮定します。 ちょうど1ブロックがコード化されていることであるなら、そのブロックはAES(また、ECBモードとして、知られている)と共に単にコード化されます。 1ブロックが1ブロックの端のときに水増しされるより小さい入力。 詰め物ビットの値は不特定です。 (実現はオールゼロ詰め物を使用するかもしれませんが、プロトコルは決定論的な結果を当てにしてはいけません。 実現は無作為の詰め物を使用するかもしれませんが、プロトコルは決定論的でない結果を当てにしてはいけません。 多くの場合、ケルベロス暗号化プロフィールがこの詰め物の如何にかかわらず無作為の交絡因子を加えることに注意してください。)
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.
一貫性において、暗号文窃盗はデータの最後の2ブロックがコード化されるのにいつも使用されます、[RC5]のように。 データの長さがブロック・サイズの倍数であるなら、最後の2つの暗号文ブロックが交換されている状態で、これは明瞭なCBCモードに同等です。
A test vector is given in Appendix B.
Appendix Bでテストベクトルを与えます。
Raeburn Standards Track [Page 3] RFC 3962 AES Encryption for Kerberos 5 February 2005
ケルベロス2005年2月5日のレイバーン標準化過程[3ページ]RFC3962AES暗号化
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ブロック以下をコード化して)、その1ブロックが代わりに行われます。
6. Kerberos Algorithm Profile Parameters
6. ケルベロスアルゴリズムプロフィールパラメタ
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 | +--------------------------------------------------------------------+
+--------------------------------------------------------------------+ | プロトコルキー形式128か256ビット列| | | | 変数があるストリングから主要な機能へのPBKDF2+DK| | 繰り返しカウント(| | 上を見ます)| | | | デフォルトストリングから重要へのパラメタ00 00 10 00| | | | キー生成種子長さのキーサイズ| | | | 主要な機能に無作為のアイデンティティ機能| | | | ハッシュ関数、H SHA-1| | | | HMAC出力サイズ、h12八重奏(96ビット)| | | | メッセージブロック・サイズ、m1八重奏| | | | 暗号化/復号化機能、CBC-CTSモードによるAES| | 次にがあるEとD(暗号ブロック・サイズ16| | 八重奏)、-、-| | 最後のブロック、(最後に、|妨げてください|、1だけ)、CBC-スタイル| | ivec| +--------------------------------------------------------------------+
Using this profile with each key size gives us two each of encryption and checksum algorithm definitions.
それぞれの主要なサイズがあるこのプロフィールを使用すると、私たちそれぞれ2は暗号化とチェックサムアルゴリズム定義について与えられます。
Raeburn Standards Track [Page 4] RFC 3962 AES Encryption for Kerberos 5 February 2005
ケルベロス2005年2月5日のレイバーン標準化過程[4ページ]RFC3962AES暗号化
7. Assigned Numbers
7. 規定番号
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 | +--------------------------------------------------------------------+
+--------------------------------------------------------------------+ | 暗号化タイプ| +--------------------------------------------------------------------+ | 型名etype値のキーサイズ| +--------------------------------------------------------------------+ | 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 | +--------------------------------------------------------------------+
+--------------------------------------------------------------------+ | チェックサムタイプ| +--------------------------------------------------------------------+ | 型名sumtype値の長さ| +--------------------------------------------------------------------+ | 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.
これらのチェックサムタイプは上で定義される対応する暗号化タイプで使用されるでしょう。
8. Security Considerations
8. セキュリティ問題
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が受け取った激しい分析の数10年間に受信されているということではありません。 過程の前と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機能の使用には、あるパス句の長さのための欠点があります。 例えば、主なHMACアルゴリズムを適用する(20バイト)前に、ハッシュ関数ブロック・サイズ(SHA-1のための64バイト)より長いパス句はさらに小さいサイズに論じ尽くされます。 しかしながら、一般に、エントロピーはパス句でまばらです、これがロングパス句があるユーザのまれなケースで問題でないかもしれなくて特に長いもので。
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ビットのキーを発生させるのもあてにならないかもしれません、ここで説明されたストリングから主要な機能の特性を考えて、引き出されたパス句のキーの有効なエントロピーがほとんどそんなに大きいはずがないときに。
Raeburn Standards Track [Page 5] RFC 3962 AES Encryption for Kerberos 5 February 2005
ケルベロス2005年2月5日のレイバーン標準化過程[5ページ]RFC3962AES暗号化
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 Pentium4システムの作者のテストは、1秒で、およそ9万繰り返しができたのを示しました、256ビットのキーを生産して。 これはMITのケルベロスパッケージにOpenSSLからのSHA-1アセンブリ実現、およびPBKDF2コードのプレリリースバージョンを使用していました、ただ一つのシステムの上で。 倍数をするのを試みを全くしませんでした。平行では、私たちが、そうしている攻撃者がたぶん少なくとも10万繰り返しができると思って、2番目--計算の容易さのために17を2**まで四捨五入する単位で論じ尽くします。 また、簡単さのために、私たちは、最終的な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**11の要素を寄付する21のエントリーが2**の注文のときにあるかもしれないと見積もっています[リーチ]、2**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と知られている塩のストリングのために、作者のものへの何らかの数のコンピュータが匹敵している攻撃者は、およそ15CPU秒のN*2**が全体の辞書と変化をキーに変換する必要があるでしょう。
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
1カ月そのような1ダースのコンピュータを使用している攻撃者はおよそ2*を持っているでしょう。有効な*25CPU秒。 それで、2**12(4,096)繰り返しを使用するとそのような1ダースのコンピュータが全数探索法に捧げられている状態で攻撃者が単一のキーに対して意味するだろう、(実際に同じ塩と繰り返しを共有するどんなパスワードで派生しているキー
Raeburn Standards Track [Page 6] RFC 3962 AES Encryption for Kerberos 5 February 2005
ケルベロス2005年2月5日のレイバーン標準化過程[6ページ]RFC3962AES暗号化
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.
カウント) 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%かそうで。
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.
攻撃者に有効な多量の格納があるなら、中間結果がキャッシュされるかもしれないことに注意してください、同じ塩と中間結果が保存されたポイントを走ったより大きい数の繰り返しで次の攻撃のための多くの仕事を救って。 パスワードを変えるとき、したがって、新しい無作為の塩のストリングを発生させるのは賢明でしょう。 主要な名前から得られたデフォルト塩のストリングは複数のユーザに対してキーの1冊の辞書の使用から守るだけです。
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アルゴリズムに対するどんな利益もたぶんかなり少ない数の繰り返しによって達成されます。
Raeburn Standards Track [Page 7] RFC 3962 AES Encryption for Kerberos 5 February 2005
ケルベロス2005年2月5日のレイバーン標準化過程[7ページ]RFC3962AES暗号化
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モード。 どのような場合でも、より高いレベルでそのような困惑を当てにするべきではありません。 傍観者から長さをあいまいにしなければならないなら、故意にコード化されるべきメッセージの長さを変えることによって、これをするべきです。
9. IANA Considerations
9. IANA問題
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で使用されるケルベロス暗号化とチェックサムタイプ値は以前に、本書では定義されたメカニズムのために[KCRYPTO]に控えられました。 このドキュメントについて参照に記載するために登録をアップデートしました。
10. Acknowledgements
10. 承認
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、ヘラルド・ディアーズクエリャル、ケン・ホーンスタイン、ポール・リーチ、Marcusウォッツ、ラリー・朱、および他のものをありがとうございます。
Raeburn Standards Track [Page 8] RFC 3962 AES Encryption for Kerberos 5 February 2005
ケルベロス2005年2月5日のレイバーン標準化過程[8ページ]RFC3962AES暗号化
A. Errata for RFC 2040 Section 8
A。 RFC2040部8のための誤字
(Copied from the RFC Editor's errata web site on July 8, 2004.)
(2004年7月8日のRFC Editorの誤字ウェブサイトから、コピーされます。)
Reported By: Bob Baldwin; baldwin@plusfive.com Date: Fri, 26 Mar 2004 06:49:02 -0800
以下によって報告されました。 ボブ・ボールドウィン。 baldwin@plusfive.com 日付: 金曜日、2004年3月26日06: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.
1. 前の暗号文ブロック、Xn-1を作成するCn-2と排他的論理和Pn-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.
1. 前の暗号文ブロック、Xn-1を作成するCn-2と排他的論理和Pn-1。 Cn-2が存在しない短いメッセージには、IVを使用してください。
Reported By: Bob Baldwin; baldwin@plusfive.com Date: Mon, 22 Mar 2004 20:26:40 -0800
以下によって報告されました。 ボブ・ボールドウィン。 baldwin@plusfive.com 日付: 月曜日、2004年3月22日20: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、第一節で、2番目の文は読むべきです:
This mode handles any length of plaintext longer than one
block and produces ciphertext whose length matches the
plaintext length.
このモードは、1ブロックより長い間どんな長さの平文も扱って、長さが平文の長さに合っている暗号文を生産します。
In Section 8, step 6 of the decryption method says:
セクション8では、復号化方法のステップ6は言います:
6. Decrypt En to create Pn-1.
6. Enを解読して、Pn-1を作成してください。
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.
6. Cn-2と共にEnと排他的論理和を解読して、Pn-1を作成してください。 Cn-2が存在しない短いメッセージには、IVを使用してください。
Raeburn Standards Track [Page 9] RFC 3962 AES Encryption for Kerberos 5 February 2005
ケルベロス2005年2月5日のレイバーン標準化過程[9ページ]RFC3962AES暗号化
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つのPass句=Saltは"ATHENA.MIT.EDUraeburn"128ビットのPBKDF2出力と等しいです: cd教育b5 28 1b b2 f8 01 56 5a11 22b2 56 35 15の128ビットのAESキー: 42 26 3c 6e89f4 fc28b8 df68ee09 79の9fの15の256ビットのPBKDF2出力: cd教育b5 28 1b b2 f8 01 56 5a11 22b2 56 35 15 0a d1 f7 a0 4b b9 f3 a3 33のec c0 e2 e1 f7の08 37の256ビットのAESキー: fe69 7b52bc 0d 3c e1 44 32Ba03 6a92e6 5b bb52 28 09 90a2ファ27 88 39 98d7 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
「パスワード」繰り返しカウント=2Pass句=Saltは"ATHENA.MIT.EDUraeburn"128ビットのPBKDF2出力と等しいです: 01 db ee 7f 4a 9e24 3e98 8b62c7 3c da93の5dの128ビットのAESキー: c6 51bf29e2 30 0a c2 7f a4 69d6 93のbd daの13の256ビットのPBKDF2出力: 01 db ee 7f 4a 9e24 3e98 8b62c7 3c da93 5d a0 53 78b9 32 44ec 8f48a9 9e61広告79の9dの86の256ビットのAESキー: a2 e1 6d16b3 60 69c1 35d5 e9 d2 e2 5f89 61 02 68 56 18b9 59 14b4 67c6 76 22 22 58 24ff
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
「パスワード」1200Passが言葉で表す繰り返しカウント==Saltは"ATHENA.MIT.EDUraeburn"128ビットのPBKDF2出力と等しいです: 5c08eb61fd f7 1e 4e 4e c3Cf6b a1 f5 51の2bの128ビットのAESキー: 4c01cd46d6 32d0 1e 6d、23 0a01教育64の2aの256ビットのPBKDF2出力になってください: 5c08eb61fd f7 1e 4e 4e c3Cf6b a1 f5 51 2b a7 e5 2d db c5 e5 14 2f70 8a31のe2 e6 2b 1eの13の256ビットのAESキー: 55 a6 ac74 0a d1 7b48 46 94 10 51e1 e8 b0 a7 54 8d93b0腹筋30a8 bc 3f f1 62 80 38 2b 8c 2a
Raeburn Standards Track [Page 10] RFC 3962 AES Encryption for Kerberos 5 February 2005
ケルベロス2005年2月5日のレイバーン標準化過程[10ページ]RFC3962AES暗号化
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].)
「パスワード」繰り返しカウント=5Pass句=Saltは0×1234567878563412の128ビットのPBKDF2出力と等しいです: d1 da a7 86 15f2 87e6 a1 c8 b1 20d7 06 2a49の128ビットのAESキー: e9 b2 3d52 27 37 47dd 5c35は61が9d 8eの256ビットのPBKDF2出力であったなら55をcbします: d1 da a7 86 15f2 87e6 a1 c8 b1 20d7 06 2a49 3f98d2 03e6、49a6広告f4ファ57の4b 6eの64のeeの256ビットのAESキーになってください: 97a4 e7 86、20d8 1a38 2d 5e bc96d5 90 9c腹筋cd広告c8 7c a4 8f57 45 04 15 9f16c3 6e31になってください。(このテストは[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
繰り返しカウント=1200Pass句の=(64のキャラクタ)"XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"塩は「パス句の同輩はサイズを妨げること」の128ビットのPBKDF2出力と等しいです: 13 9c30c0 96 6b c3 2b a5 5f db f2 12 53の0a c9の128ビットのAESキー: 59 d1 bb78 9a82 8b 1a a5 4e f9 c2 88 3f69の教育の256ビットのPBKDF2出力: 13 9c30c0 96 6b c3 2b a5 5f db f2 12 53 0a c9 c5 ec59f1 a4 52のfe a0の59の8e d1の256ビットのAES f5cc9a d9 40キー: 89 広告ee36 08db 8b c7 1f 1b fb fe45 94 86b0 56 18b7 0c Ba e2 20 92 53 4e56c5 53Ba4b34
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
繰り返しカウント=1200Pass句の=(65のキャラクタ)"XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"塩は「パス句はブロック・サイズを超えていること」の128ビットのPBKDF2出力と等しいです: 9c ca d6 d4 68 77 0c d5 1b10e6 a6 87 21、61の128ビットのAESキーになってください: cb80 05dc 5f90 17 9a 7f02 10 4c00 18 75の1dの256ビットのPBKDF2出力: 9c ca d6 d4 68 77 0c d5 1b10e6 a6 87 21、92 46 91 5e c8 2aの256ビットのAESが主要であったなら、61 1a 8b 4d28 26 01db 3b36になってください: d7 8c 5c 9c b8 72a8 c9 da d4 69 7f 0b b5 b2 d2 14 96c8 2b eb 2c ae da21 12fc ee a0 57 40 1b
Raeburn Standards Track [Page 11] RFC 3962 AES Encryption for Kerberos 5 February 2005
ケルベロス2005年2月5日のレイバーン標準化過程[11ページ]RFC3962AES暗号化
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
繰り返しカウント=50Pass句=のg-音部記号(0xf09d849e)塩は"EXAMPLE.COMpianist"128ビットのPBKDF2出力と等しいです: 6b 9c f2 6d45 45 5a43a5 b8 bb27 6a40 3b39の128ビットのAESキー: f1 49c1 f2 e1 54a7 34 52d4 3e 7f e6 2a56のe5の256ビットのPBKDF2出力: 6b 9c f2 6d45 45 5a43a5 b8 bb27 6a40 3b39e7 fe37a0 c4 1e02c2 81ff30 69のe1 e9 4fの52の256ビットのAESキー: 09ccの4b 6d98 39f8 44 06df 1f16 6d b4 b8 3c57 18 48b7 84a3 d6 bd c3 46 58 9a 3e39 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
AESの128ビットのキー: 0000: 63 68 69 63 6b65 6e20 74 65 72 69 79 61 6b69
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入力: 0000: 49 20 77 6f75 6c64 20 6c69 6b65 20 74 68 65 0010: 20 出力: 0000: c6 35 35 68f2 bf 8c b4 d8 a5 80 36 2d a7ff7f0010: 97 次IV: 0000: c6 35 35 68f2 bf 8c b4 d8 a5 80 36 2d a7ff7f
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 6f75 6c64 20 6c69 6b65 20 74 68 65 0010: 20 47 65 6e65 72 61 6c20 47 61 75 27 73 20出力: 0000: fc00 78 3e 0e fd b2 c1 d4 45d4 c8 ef f7教育22 0010: 97 68 72 68d6 ec cc c0 c0 7b25e2 5e Cf e5 Next IV: 0000: fc00 78 3e 0e fd b2 c1 d4 45d4 c8 ef f7教育22
Raeburn Standards Track [Page 12] RFC 3962 AES Encryption for Kerberos 5 February 2005
ケルベロス2005年2月5日のレイバーン標準化過程[12ページ]RFC3962AES暗号化
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 6f75 6c64 20 6c69 6b65 20 74 68 65 0010: 20 47 65 6e65 72 61 6c20 47 61 75 27 73 20 43出力: 0000: 39 31 25 23a7 86 62d5、7f cb cc98eb f5 a8 0010になってください: 97 68 72 68d6 ec cc c0 c0 7b25e2 5e Cf e5 84Next IV: 0000: 39 31 25 23a7 86 62d5、7f cb cc98eb f5 a8になってください。
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 6f75 6c64 20 6c69 6b65 20 74 68 65 0010: 20 47 65 6e65 72 61 6c20 47 61 75 27 73 20 43 0020: 68 69 63 6b65 6e 2c20 70 6c65 61 73 65 2c出力: 0000: 97 68 72 68d6 ec cc c0 c0 7b25e2 5e Cf e5 84 0010: b3ff fd94 0c16a1 8c 1b55 49d2 f8 38 02 9e0020: 39 31 25 23a7 86 62d5、7f cb cc98eb f5 Next IVになってください: 0000: b3ff fd94 0c16a1 8c 1b55 49d2 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 6f75 6c64 20 6c69 6b65 20 74 68 65 0010: 20 47 65 6e65 72 61 6c20 47 61 75 27 73 20 43 0020: 68 69 63 6b65 6e 2c20 70 6c65 61 73 65 2c20出力: 0000: 97 68 72 68d6 ec cc c0 c0 7b25e2 5e Cf e5 84 0010: 9d広告8b bb96c4 cd c0 3b c1 03e1 a1 94bb d8 0020: 39 31 25 23a7 86 62d5、7f cb cc98eb f5 a8 Next IVになってください: 0000: 9d広告8b bb96c4 cd c0 3b c1 03e1 a1 94bb d8
Raeburn Standards Track [Page 13] RFC 3962 AES Encryption for Kerberos 5 February 2005
ケルベロス2005年2月5日のレイバーン標準化過程[13ページ]RFC3962AES暗号化
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 6f75 6c64 20 6c69 6b65 20 74 68 65 0010: 20 47 65 6e65 72 61 6c20 47 61 75 27 73 20 43 0020: 68 69 63 6b65 6e 2c20 70 6c65 61 73 65 2c20 0030: 61 6e64 20 77 6f 6e74 6f 6e20 73 6f75 70 2e出力: 0000: 97 68 72 68d6 ec cc c0 c0 7b25e2 5e Cf e5 84 0010: 39 31 25 23a7 86 62d5、7f cb cc98eb f5 a8 0020になってください: 48 07ef e8 36ee89a5 26 73 0d bc 2f 7b c8 40 0030: 9d広告8b bb96c4 cd c0 3b c1 03e1 a1 94bb d8 Next IV: 0000: 48 07ef e8 36ee89a5 26 73 0d bc 2f 7b c8 40
Normative References
引用規格
[AC] Schneier, B., "Applied Cryptography", second edition, John
Wiley and Sons, New York, 1996.
[西暦] シュナイアーとB.と「適用された暗号」と第2版とジョン・ワイリーとソンス、ニューヨーク、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.
ワシントン(DC)2001年11月の[AES]米国商務省標準技術局、米国商務省、「エー・イー・エス」連邦政府の情報処理規格公表197。
[KCRYPTO] Raeburn, K., "Encryption and Checksum Specifications for
Kerberos 5", RFC 3961, February 2005.
[KCRYPTO] レイバーンとK.と「暗号化とケルベロス5インチチェックサム仕様、RFC3961、2005年2月。」
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[KEYWORDS]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[PKCS5] Kaliski, B., "PKCS #5: Password-Based Cryptography
Specification Version 2.0", RFC 2898, September 2000.
[PKCS5]Kaliski、B.、「PKCS#5:」 パスワードベースの暗号仕様バージョン2インチ、RFC2898、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.Rivest、「RC5、RC5-CBC、RC5-CBC-パッド、およびRC5-CTSアルゴリズム」RFC2040、10月1996日
[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、ワシントン(DC)1995年4月。
Raeburn Standards Track [Page 14] RFC 3962 AES Encryption for Kerberos 5 February 2005
ケルベロス2005年2月5日のレイバーン標準化過程[14ページ]RFC3962AES暗号化
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.
[リーチ]リーチ、P.はIETFケルベロスワーキンググループメーリングリスト、2003年5月5日、 ftp://ftp.ietf.org/ietf-mail- アーカイブ/krb-wg/2003-05.mailにメールされます。
[PECMS] Gutmann, P., "Password-based Encryption for CMS", RFC
3211, December 2001.
[PECMS]ガットマン、P.、「cmのためのパスワードベースの暗号化」、RFC3211、2001年12月。
Author's Address
作者のアドレス
Kenneth Raeburn Massachusetts Institute of Technology 77 Massachusetts Avenue Cambridge, MA 02139
マサチューセッツ通りケンブリッジ、ケネスレイバーンマサチューセッツ工科大学77MA 02139
EMail: raeburn@mit.edu
メール: raeburn@mit.edu
Raeburn Standards Track [Page 15] RFC 3962 AES Encryption for Kerberos 5 February 2005
ケルベロス2005年2月5日のレイバーン標準化過程[15ページ]RFC3962AES暗号化
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でIETF Documentsの権利に関するIETFの手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Raeburn Standards Track [Page 16]
レイバーン標準化過程[16ページ]
一覧
スポンサーリンク
