Network Working Group K. Raeburn
Request for Comments: 3961 MIT
Category: Standards Track February 2005
Encryption and Checksum Specifications
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
抽象
This document describes a framework for defining encryption and checksum mechanisms for use with the Kerberos protocol, defining an abstraction layer between the Kerberos protocol and related protocols, and the actual mechanisms themselves. The document also defines several mechanisms. Some are taken from RFC 1510, modified in form to fit this new framework and occasionally modified in content when the old specification was incorrect. New mechanisms are presented here as well. This document does NOT indicate which mechanisms may be considered "required to implement".
この文書は、Kerberosプロトコルと関連するプロトコル、及び実際のメカニズム自体との間の抽象化レイヤを定義する、Kerberosプロトコルで使用するための暗号化とチェックサムメカニズムを定義するためのフレームワークを記述する。文書はまた、いくつかのメカニズムを定義します。いくつかは、RFC 1510から撮影したこの新しいフレームワークに合わせて形に修正し、古い仕様が間違っていたとき、時折内容に変更されています。新しいメカニズムは、ここにも提示されています。この文書は、「実装するために必要」と考えることができるそのメカニズムを示すものではありません。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Encryption Algorithm Profile . . . . . . . . . . . . . . . . 4
4. Checksum Algorithm Profile . . . . . . . . . . . . . . . . . 9
5. Simplified Profile for CBC Ciphers with Key Derivation . . . 10
5.1. A Key Derivation Function . . . . . . . . . . . . . . . 10
5.2. Simplified Profile Parameters . . . . . . . . . . . . . 12
5.3. Cryptosystem Profile Based on Simplified Profile . . . 13
5.4. Checksum Profiles Based on Simplified Profile . . . . . 16
6. Profiles for Kerberos Encryption and Checksum Algorithms . . 16
6.1. Unkeyed Checksums . . . . . . . . . . . . . . . . . . . 17
6.2. DES-based Encryption and Checksum Types . . . . . . . . 18
6.3. Triple-DES Based Encryption and Checksum Types . . . . 28
7. Use of Kerberos Encryption Outside This Specification . . . . 30
8. Assigned Numbers . . . . . . . . . . . . . . . . . . . . . . 31
9. Implementation Notes . . . . . . . . . . . . . . . . . . . . 32
10. Security Considerations . . . . . . . . . . . . . . . . . . . 33
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
12. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 36
A. Test vectors . . . . . . . . . . . . . . . . . . . . . . . . 38
A.1. n-fold . . . . . . . . . . . . . . . . . . . . . . . . 38
A.2. mit_des_string_to_key . . . . . . . . . . . . . . . . . 39
A.3. DES3 DR and DK . . . . . . . . . . . . . . . . . . . . 43
A.4. DES3string_to_key . . . . . . . . . . . . . . . . . . . 44
A.5. Modified CRC-32 . . . . . . . . . . . . . . . . . . . . 44
B. Significant Changes from RFC 1510 . . . . . . . . . . . . . . 45
Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Normative References. . . . . . . . . . . . . . . . . . . . . . . 47
Informative References. . . . . . . . . . . . . . . . . . . . . . 48
Editor's Address. . . . . . . . . . . . . . . . . . . . . . . . . 49
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 50
The Kerberos protocols [Kerb] are designed to encrypt messages of arbitrary sizes, using block encryption ciphers or, less commonly, stream encryption ciphers. Encryption is used to prove the identities of the network entities participating in message exchanges. However, nothing in the Kerberos protocol requires that any specific encryption algorithm be used, as long as the algorithm includes certain operations.
ケルベロスプロトコル[カーブ]は、ブロック暗号化方式や、あまり一般的ではないが、ストリーム暗号化方式を使用して、任意のサイズのメッセージを暗号化するように設計されています。暗号化は、メッセージ交換に参加するネットワークエンティティの身元を証明するために使用されます。しかし、Kerberosプロトコルには何も限りアルゴリズムは、特定の操作を含んでいるとして、任意の特定の暗号化アルゴリズムが使用されている必要がありません。
The following sections specify the encryption and checksum mechanisms currently defined for Kerberos, as well as a framework for defining future mechanisms. The encoding, chaining, padding, and other requirements for each are described. Appendix A gives test vectors for several functions.
以下のセクションでは、現在、Kerberosのために定義された暗号化とチェックサム機構、ならびに将来のメカニズムを定義するためのフレームワークを指定します。それぞれの符号化、連鎖、パディング、及び他の要件が記載されています。付録Aには、いくつかの機能のためのテストベクトルを与えます。
Both encryption and checksum mechanisms are profiled in later sections. Each profile specifies a collection of operations and attributes that must be defined for a mechanism. A Kerberos encryption or checksum mechanism specification is not complete if it does not define all of these operations and attributes.
どちらの暗号化とチェックサムメカニズムは、後のセクションで紹介されています。各プロファイルは、メカニズムのために定義されなければならない操作と属性のコレクションを指定します。それは、これらの操作と属性のすべてを定義していない場合はKerberosの暗号化またはチェックサムメカニズム仕様が完全ではありません。
An encryption mechanism must provide for confidentiality and integrity of the original plaintext. (Incorporating a checksum may permit integrity checking, if the encryption mode does not provide an integrity check itself.) It must also provide non-malleability
暗号化メカニズムは、元の平文の機密性と整合性のために提供しなければなりません。 （暗号化モードは、整合性チェック自体を提供しない場合は、チェックサムを組み込むこと、整合性チェックを可能にすることができる。）また、非展性を提供する必要があります
[Bellare98] [Dolev91]. Use of a random confounder prepended to the plaintext is recommended. It should not be possible to determine if two ciphertexts correspond to the same plaintext without the key.
[Bellare98] [Dolev91]。平文の前に付加ランダム交絡因子の使用が推奨されます。 2つの暗号文は、鍵なしで同一の平文に対応するかどうかを決定することが可能であってはなりません。
A checksum mechanism [1] must provide proof of the integrity of the associated message and must preserve the confidentiality of the message in case it is not sent in the clear. Finding two plaintexts with the same checksum should be infeasible. It is NOT required that an eavesdropper be unable to determine whether two checksums are for the same message, as the messages themselves would presumably be visible to any such eavesdropper.
チェックサム機構[1]に関連するメッセージの完全性の証明を提供する必要があり、それは平文で送信されない場合に、メッセージの機密性を保持しなければなりません。同じチェックサムを持つ2つの平文を見つけることは実行不可能でなければなりません。盗聴者がメッセージ自体は、おそらくそのような盗聴者に見えるであろうように、2つのチェックサムが、同じメッセージのためのものであるかどうかを判断することができないことが要求されません。
Due to advances in cryptography, some cryptographers consider using the same key for multiple purposes unwise. Since keys are used in performing a number of different functions in Kerberos, it is desirable to use different keys for each of these purposes, even though we start with a single long-term or session key.
暗号の進歩に、いくつかの暗号技術者は愚かな複数の目的のために同じキーを使用することを検討してください。キーはケルベロスの異なる多数の機能を実行する際に使用されているので、我々は、単一の長期的又はセッション鍵で開始にもかかわらず、これらの目的のそれぞれに異なる鍵を使用することが望ましいです。
We do this by enumerating the different uses of keys within Kerberos and by making the "usage number" an input to the encryption or checksum mechanisms; such enumeration is outside the scope of this document. Later sections define simplified profile templates for encryption and checksum mechanisms that use a key derivation function applied to a CBC mode (or similar) cipher and a checksum or hash algorithm.
私たちは、Kerberos内のキーの異なる用途を列挙することによって暗号化またはチェックサム・メカニズムへの「使用回数」の入力をすることによってこれを行います。そのような列挙は、このドキュメントの範囲外です。以降のセクションでは、CBCモード（または類似の）暗号チェックサムまたはハッシュアルゴリズムに適用される鍵導出関数を使用して暗号化とチェックサムメカニズムの簡略化されたプロファイルのテンプレートを定義します。
We distinguish the "base key" specified by other documents from the "specific key" for a specific encryption or checksum operation. It is expected but not required that the specific key be one or more separate keys derived from the original protocol key and the key usage number. The specific key should not be explicitly referenced outside of this document. The typical language used in other documents should be something like, "encrypt this octet string using this key and this usage number"; generation of the specific key and cipher state (described in the next section) are implicit. The creation of a new cipher-state object, or the re-use of one from a previous encryption operation, may also be explicit.
私たちは、特定の暗号化やチェックサム演算のための「特定のキー」から他の文書で指定された「ベース・キー」を区別する。これは予想されるが、特定のキーは、元のプロトコルキーとキーの使用回数に由来する1つまたは複数の別個の鍵である必要はありません。特定のキーは、明示的にこのドキュメントの外で参照すべきではありません。他のドキュメントで使用される典型的な言語は何かのように、「このキーとその使用法の番号を使用して、このオクテット文字列を暗号化」する必要があります。 （次のセクションで説明）特定のキーと暗号状態の生成は、暗黙的です。新しい暗号状態オブジェクトの作成、または前の暗号化操作から1の再使用は、また、明示的かもしれません。
New protocols defined in terms of the Kerberos encryption and checksum types should use their own key usage values. Key usages are unsigned 32-bit integers; zero is not permitted.
Kerberosの暗号化とチェックサムの種類の面で定義された新しいプロトコルは、独自のキー使用の値を使用する必要があります。主な用途は、符号なし32ビット整数です。ゼロは許可されていません。
All data is assumed to be in the form of strings of octets or eight-bit bytes. Environments with other byte sizes will have to emulate this behavior in order to get correct results.
すべてのデータは、オクテットまたは8ビット・バイトの文字列の形であると仮定されます。他のバイトサイズの環境では、正しい結果を得るために、この動作をエミュレートする必要があります。
Each algorithm is assigned an encryption type (or "etype") or checksum type number, for algorithm identification within the Kerberos protocol. The full list of current type number assignments is given in section 8.
各アルゴリズムは、Kerberosプロトコル内のアルゴリズムの識別のために、暗号化の種類（または「ETYPE」）又はチェックサム・タイプ番号が割り当てられます。現在のタイプ番号の割り当ての完全なリストは、セクション8に記載されています。
An encryption mechanism profile must define the following attributes and operations. The operations must be defined as functions in the mathematical sense. No additional or implicit inputs (such as Kerberos principal names or message sequence numbers) are permitted.
暗号化メカニズムプロファイルは、以下の属性と操作を定義する必要があります。操作は、数学的な意味での関数として定義する必要があります。 （例えば、Kerberosプリンシパル名またはメッセージシーケンス番号のような）追加の又は暗黙の入力が許可されていません。
protocol key format This describes which octet string values represent valid keys. For encryption mechanisms that don't have perfectly dense key spaces, this will describe the representation used for encoding keys. It need not describe invalid specific values; all key generation routines should avoid such values.
このプロトコルキーの形式は、有効なキーを表すオクテット文字列値を示します。完全に密なキーにスペースを持っていない暗号化メカニズムについては、これは、符号化キーに使用する表現を記述します。これは、無効な特定の値を記述する必要はありません。すべての鍵生成ルーチンは、このような値を避ける必要があります。
specific key structure This is not a protocol format at all, but a description of the keying material derived from the chosen key and used to encrypt or decrypt data or compute or verify a checksum. It may, for example, be a single key, a set of keys, or a combination of the original key with additional data. The authors recommend using one or more keys derived from the original key via one-way key derivation functions.
特定のキー構造これは、すべてのプロトコル形式ではなく、鍵材料の説明は、選択されたキーに由来し、暗号化または復号化データまたはチェックサムを計算または検証するために使用されます。これは、例えば、単一のキー、キーのセット、または追加のデータと、元のキーの組み合わせであってもよいです。著者は、一方向の鍵導出関数を経由して元のキーに由来する1つの以上のキーを使用することをお勧めします。
required checksum mechanism This indicates a checksum mechanism that must be available when this encryption mechanism is used. Since Kerberos has no built in mechanism for negotiating checksum mechanisms, once an encryption mechanism is decided, the corresponding checksum mechanism can be used.
必要なチェックサムメカニズムこれは、この暗号化メカニズムを使用する場合に利用可能でなければならないチェックサムメカニズムを示しています。 Kerberosはないチェックサムメカニズムを交渉するための機構に内蔵されているので、暗号化機構が決定されると、対応するチェックサム機構を使用することができません。
key-generation seed length, K This is the length of the random bitstring needed to generate a key with the encryption scheme's random-to-key function (described below). This must be a fixed value so that various techniques for producing a random bitstring of a given length may be used with key generation functions.
鍵生成のシード長さ、Kは、これは、（後述する）暗号化方式のランダム・ツー・キー機能を持つキーを生成するために必要なランダムビット文字列の長さです。所与の長さのランダムビット列を生成するための様々な技術は、鍵生成関数で使用することができるように、これは固定値でなければなりません。
key generation functions Keys must be generated in a number of cases, from different types of inputs. All function specifications must indicate how to generate keys in the proper wire format and must avoid generating keys that significantly compromise the confidentiality of encrypted data, if the cryptosystem has such. Entropy from each source should be preserved as much as possible. Many of the inputs, although unknown, may be at least partly predictable (e.g., a password string is likely to be entirely in the ASCII subset and of fairly short length in many environments; a semi-random string may include time stamps). The benefit of such predictability to an attacker must be minimized.
鍵生成機能キーは、異なるタイプの入力から、多くの場合に生成されなければなりません。すべての機能仕様は、適切なワイヤ形式で鍵を生成する方法を示さなければならないと暗号がこのようなを持っている場合は大幅に、暗号化されたデータの機密性を損なう鍵の生成を回避しなければなりません。各ソースからのエントロピーはできるだけ保存されなければなりません。入力の多くの未知が、少なくとも部分的に予測可能であってもよい（例えば、パスワード文字列は、ASCIIサブセットであり、多くの環境でかなり短い長さで完全である可能性がある。セミランダム文字列はタイムスタンプを含んでいてもよいです）。攻撃者がこのような予測可能性の利点は最小限に抑えなければなりません。
string-to-key (UTF-8 string, UTF-8 string, opaque)->(protocol-key) This function generates a key from two UTF-8 strings and an opaque octet string. One of the strings is usually the principal's pass phrase, but generally it is merely a secret string. The other string is a "salt" string intended to produce different keys from the same password for different users or realms. Although the strings provided will use UTF-8 encoding, no specific version of Unicode should be assumed; all valid UTF-8 strings should be allowed. Strings provided in other encodings MUST first be converted to UTF-8 before applying this function.
ストリングからキー（UTF-8文字列、UTF-8文字列、不透明） - >（プロトコルキー）この関数は、2つのUTF-8文字列と不透明なオクテット列から鍵を生成します。文字列の一つは、通常、プリンシパルのパスフレーズですが、一般的に、それは単に秘密の文字列です。他の文字列は、異なるユーザまたはレルムのために同じパスワードとは異なる鍵を生成することを目的とし、「塩」の文字列です。提供される文字列がUTF-8エンコーディングを使用するが、ユニコードの特別バージョンが想定されるべきではありません。すべての有効なUTF-8文字列は許されるべきです。他のエンコーディングに設けられた文字列が最初にこの機能を適用する前に、UTF-8に変換しなければなりません。
The third argument, the octet string, may be used to pass mechanism-specific parameters into this function. Since doing so implies knowledge of the specific encryption system, generating non-default parameter values should be an uncommon operation, and normal Kerberos applications should be able to treat this parameter block as an opaque object supplied by the Key Distribution Center or defaulted to some mechanism-specific constant value.
第三の引き数、オクテットストリングが、この機能に機構固有のパラメータを渡すために使用されてもよいです。そうすること、デフォルト以外のパラメータ値は珍しい操作する必要があります生成し、特定の暗号化システムの知識を意味し、不透明なオブジェクトがキー配布センターから供給されるか、いくつかのメカニズムにデフォルト設定として、通常のKerberosアプリケーションでは、このパラメータブロックを処理することができるはずですので、固有の定数値。
The string-to-key function should be a one-way function so that compromising a user's key in one realm does not compromise it in another, even if the same password (but a different salt) is used.
1つの分野でユーザーのキーを損なうことは同じパスワード（しかし異なる塩）が使用されている場合でも、別のそれを損なわないように、文字列からキーへの機能は、一方向関数でなければなりません。
random-to-key (bitstring[K])->(protocol-key) This function generates a key from a random bitstring of a specific size. All the bits of the input string are assumed to be equally random, even though the entropy present in the random source may be limited.
ランダム・ツー・キー（ビット文字列[K]） - >（プロトコルキー）この関数は、特定のサイズのランダムビット列から鍵を生成します。入力文字列のすべてのビットをランダムソースに存在するエントロピーが制限され得るにもかかわらず、等しくランダムであると仮定されます。
key-derivation (protocol-key, integer)->(specific-key) In this function, the integer input is the key usage value, as described above. An attacker is assumed to know the usage values. The specific-key output value was described in section 2.
鍵導出（プロトコルキー、整数） - 上記のように>（特定のキー）この関数では、整数入力は、主要な用法値です。攻撃者は、使用価値を知っていると想定されます。特定キーの出力値は、セクション2で説明しました。
string-to-key parameter format This describes the format of the block of data that can be passed to the string-to-key function above to configure additional parameters for that function. Along with the mechanism of encoding parameter values, bounds on the allowed parameters should also be described to avoid allowing a spoofed KDC to compromise the user's password. If practical it may be desirable to construct the encoding so that values unacceptably weakening the resulting key cannot be encoded.
ストリングからキーパラメータ形式これは、その関数の追加のパラメータを設定するために、上記ストリングからキー機能に渡すことができるデータのブロックのフォーマットを記述する。パラメータ値を符号化するメカニズムとともに、許可パラメータの境界はまた、偽装されたKDCは、ユーザのパスワードを侵害することができ避けるために説明しなければなりません。実用的な場合は、値が許容できないほど得キー符号化することができないを弱めるようにエンコーディングを構築することが望ましい場合があります。
Local security policy might permit tighter bounds to avoid excess resource consumption. If so, the specification should recommended defaults for these bounds. The description should also outline possible weaknesses if bounds checks or other validations are not applied to a parameter string received from the network.
ローカルセキュリティポリシーは、過剰なリソースの消費を避けるために、より厳しい限界を許すかもしれません。その場合、仕様は、これらの境界のデフォルトを推奨すべきです。境界チェックや他の検証をネットワークから受信したパラメータ文字列に適用されていない場合の記述も可能弱点を概説する必要があります。
As mentioned above, this should be considered opaque to most normal applications.
前述したように、これはほとんどの通常のアプリケーションに対して不透明と考えるべきです。
default string-to-key parameters (octet string) This default value for the "params" argument to the string-to-key function should be used when the application protocol (Kerberos or other) does not explicitly set the parameter value. As indicated above, in most cases this parameter block should be treated as an opaque object.
アプリケーションプロトコル（Kerberosまたはその他）は、明示的にパラメータ値を設定していない場合、デフォルトの文字列ツー主要パラメータ（オクテット文字列）文字列からキーへの機能への「のparams」引数のこのデフォルト値を使用する必要があります。上記に示したように、ほとんどの場合、このパラメータブロックは、不透明なオブジェクトとして扱われるべきです。
cipher state This describes any information that can be carried over from one encryption or decryption operation to the next, for use with a given specific key. For example, a block cipher used in CBC mode may put an initial vector of one block in the cipher state. Other encryption modes may track nonces or other data.
暗号状態これは、与えられた特定のキーを使用するため、次の1つの暗号化または復号化操作から引き継ができる任意の情報を説明しています。例えば、CBCモードで使用されるブロック暗号は、暗号状態における一つのブロックの初期ベクトルを置いてもよいです。その他の暗号化モードは、ナンスまたは他のデータを追跡することができます。
This state must be non-empty and must influence encryption so that messages are decrypted in the same order they were a encrypted, if the cipher state is carried over from one encryption to the next. Distinguishing out-of-order or missing messages from corrupted messages is not required. If desired, this can be done at a higher level by including sequence numbers and not "chaining" the cipher state between encryption operations.
この状態は非空でなければならないとのメッセージが暗号状態は次の1つの暗号化から引き継がれている場合、彼らは、暗号化されたのと同じ順序で復号化されるように、暗号化に影響を与える必要があります。アウトオブオーダーまたは欠落メッセージ破損したメッセージから区別することは必要ありません。所望であれば、これはシーケンス番号を含み、暗号化操作の間に暗号化状態を「連鎖」しないことにより、より高いレベルで行うことができます。
The cipher state may not be reused in multiple encryption or decryption operations. These operations all generate a new cipher state that may be used for following operations using the same key and operation.
暗号状態は、複数の暗号化や復号化の操作で再利用することはできません。これらの操作はすべて、同じキー操作を使用して、次の操作に使用することができる新しい暗号状態を生成します。
The contents of the cipher state must be treated as opaque outside of encryption system specifications.
暗号状態の内容は暗号化システム仕様の不透明な外として扱われなければなりません。
initial cipher state (specific-key, direction)->(state) This describes the generation of the initial value for the cipher state if it is not being carried over from a previous encryption or decryption operation.
初期暗号化状態（特定のキー、方向） - >（状態）は、前の暗号化または復号化操作から引き継がれていない場合、これは暗号化状態のための初期値の生成を記載しています。
This describes any initial state setup needed before encrypting arbitrary amounts of data with a given specific key. The specific key and the direction of operations to be performed (encrypt versus decrypt) must be the only input needed for this initialization.
これは、与えられた特定のキーとデータの任意の量を暗号化する前に必要な初期状態の設定を記述します。特定のキーと実行される操作の方向（解読に対する暗号化）この初期化に必要なだけ入力しなければなりません。
This state should be treated as opaque in any uses outside of an encryption algorithm definition.
この状態は、暗号化アルゴリズムの定義の外の用途に不透明なものとして扱われるべきです。
IMPLEMENTATION NOTE: [Kerb1510] was vague on whether and to what degree an application protocol could exercise control over the initial vector used in DES CBC operations. Some existing implementations permit setting the initial vector. This framework does not provide for application control of the cipher state (beyond "initialize" and "carry over from previous encryption"), as the form and content of the initial cipher state can vary between encryption systems and may not always be a single block of random data.
実装上の注意：[Kerb1510]アプリケーションプロトコルはDES CBC操作で使用される初期ベクトルを支配することができるかどうかと、どの程度の漠然としました。いくつかの既存の実装は、初期ベクトルを設定することが可能。初期暗号化状態の形態及び内容は、暗号化システムの間で変化することができ、常に単一のブロックでなくてもよいように、このフレームワークは、暗号化状態のアプリケーション制御（超えて「初期化」および「前暗号化からキャリーオーバー」）を提供しませんランダムデータの。
New Kerberos application protocols should not assume control over the initial vector, or that one even exists. However, a general-purpose implementation may wish to provide the capability, in case applications explicitly setting it are encountered.
新しいKerberosアプリケーションプロトコルは、初期ベクトルの制御を仮定するべきではありません、またはその1にも存在します。しかし、汎用的な実装は、明示的にそれが発生した場合の設定のアプリケーションでは、機能を提供することを望むかもしれません。
encrypt (specific-key, state, octet string)->(state, octet string) This function takes the specific key, cipher state, and a non-empty plaintext string as input and generates ciphertext and a new cipher state as outputs. If the basic encryption algorithm itself does not provide for integrity protection (e.g., DES in CBC mode), then some form of verifiable MAC or checksum must be included. Some random factor such as a confounder should be included so that an observer cannot know if two messages contain the same plaintext, even if the cipher state and specific keys are the same. The exact length of the plaintext need not be encoded, but if it is not and if padding is required, the padding must be added at the end of the string so that the decrypted version may be parsed from the beginning.
暗号化（特定のキー、状態、オクテットストリング） - >（状態、オクテットストリング）この関数は、入力として、特定のキー、暗号化状態、非空の平文の文字列を取得し、暗号文出力として新しい暗号状態を生成します。基本的な暗号化アルゴリズム自体は、完全性保護のために提供していない場合（例えば、CBCモードのDES）は、その後、検証MACまたはチェックサムのいくつかのフォームが含まれている必要があります。 2つのメッセージが同じ平文が含まれている場合、観察者は、暗号状態と特定のキーが同じであっても、知ることができないような交絡因子のようないくつかのランダムな要因が含まれなければなりません。平文の正確な長さは、符号化される必要はないが、それはないとパディングが必要な場合は復号化バージョンが先頭から解析することができるように、パディングは、文字列の最後に追加されなければならない場合。
The specification of the encryption function must indicate not only the precise contents of the output octet string, but also the output cipher state. The application protocol may carry the output cipher state forward from one encryption with a given specific key to another; the effect of this "chaining" must be defined [2].
暗号化機能の仕様は、出力オクテット文字列の正確な内容が、また、出力暗号状態ではないだけを指定する必要があります。アプリケーションプロトコルは、他に指定された特定のキーを持つ1つの暗号化から前方に出力暗号状態を有していてもよいです。この「連鎖」の効果は、定義されなければならない[2]。
Assuming that values for the specific key and cipher state are correctly-produced, no input octet string may result in an error indication.
特定のキーと暗号状態の値が正しく生成されていると仮定すると、何も入力オクテットストリングは、エラー表示を生じないかもしれません。
decrypt (specific-key, state, octet string)->(state, octet string) This function takes the specific key, cipher state, and ciphertext as inputs and verifies the integrity of the supplied ciphertext. If the ciphertext's integrity is intact, this function produces the plaintext and a new cipher state as outputs; otherwise, an error indication must be returned, and the data discarded.
復号化（特定のキー、状態、オクテットストリング） - >（状態、オクテットストリング）この関数は、入力として特定のキー、暗号状態、及び暗号文を受け取り、供給された暗号文の完全性を検証します。暗号文の整合性が損なわれていない場合、この関数は平文と出力として新しい暗号状態を作り出します。それ以外の場合は、エラー表示が返されなければならず、データは破棄します。
The result of the decryption may be longer than the original plaintext, as, for example, when the encryption mode adds padding to reach a multiple of a block size. If this is the case, any extra octets must come after the decoded plaintext. An application protocol that needs to know the exact length of the message must encode a length or recognizable "end of message" marker within the plaintext [3].
復号の結果は、暗号化モードがブロックサイズの倍数に到達するためにパディングを追加すると、例えば、のように、元の平文より長くてもよいです。このような場合は、余分なオクテットは、復号平文の後に来なければなりません。メッセージの正確な長さを知る必要があるアプリケーションプロトコルは、平文内の長さまたはマーカー認識「メッセージの終わりを」コードしなければならない[3]。
As with the encryption function, a correct specification for this function must indicate not only the contents of the output octet string, but also the resulting cipher state.
暗号化機能と同様に、この機能のための正しい仕様は、出力オクテット文字列の内容だけでなく、その結果、暗号状態だけでなく、示さなければなりません。
pseudo-random (protocol-key, octet-string)->(octet-string) This pseudo-random function should generate an octet string of some size that is independent of the octet string input. The PRF output string should be suitable for use in key generation, even if the octet string input is public. It should not reveal the input key, even if the output is made public.
擬似ランダム（プロトコルキー、オクテットストリング） - >（オクテット列）この擬似ランダム関数は、オクテットストリングの入力とは独立しているいくつかのサイズのオクテット列を生成すべきです。 PRF出力文字列はオクテット文字列の入力が公開されている場合でも、鍵の生成に使用するのに適している必要があります。これは、出力が公開されていても、入力キーを明らかにしてはいけません。
These operations and attributes are all that is required to support Kerberos and various proposed preauthentication schemes.
これらの操作と属性は、Kerberosと様々な提案事前認証スキームをサポートするために必要なものすべてです。
For convenience of certain application protocols that may wish to use the encryption profile, we add the constraint that, for any given plaintext input size, a message size must exist between that given size and that size plus 65,535 such that the length of the decrypted version of the ciphertext will never have extra octets at the end.
暗号化プロファイルを使用したい場合があり、特定のアプリケーションプロトコルの便宜のために、我々は、任意の平文入力サイズのため、メッセージサイズが所与のサイズとそのサイズと復号化されたバージョンの65,535ような長さの間に存在する必要があり、制約を追加します暗号文の末尾に余分なオクテットを持つことはありません。
Expressed mathematically, for every message length L1, there exists a message size L2 such that
数学的に表現、すべてのメッセージの長さL1のために、そのL2は、そのようなメッセージのサイズが存在します
L2 >= L1 L2 < L1 + 65,536 for every message M with |M| = L2, decrypt(encrypt(M)) = M
L2> = L1 L2 <L1 +とすべてのメッセージMのための65536 | M | = L2は、復号化（暗号化（M））= M
A document defining a new encryption type should also describe known weaknesses or attacks, so that its security may be fairly assessed, and should include test vectors or other validation procedures for the operations defined. Specific references to information that is readily available elsewhere are sufficient.
新しい暗号化タイプを定義する文書は、そのセキュリティはかなり評価することができるように、また、知られている弱点や攻撃を記述する必要があり、テストベクトルまたは定義された操作のための他の検証手順を含める必要があります。他の場所で容易に入手可能な情報への具体的な言及は十分です。
A checksum mechanism profile must define the following attributes and operations:
チェックサムメカニズムプロファイルは、以下の属性と操作を定義する必要があります。
associated encryption algorithm(s) This indicates the types of encryption keys this checksum mechanism can be used with.
関連した暗号化アルゴリズム（S）これは、このチェックサム機構と共に使用することができる暗号化キーのタイプを示します。
A keyed checksum mechanism may have more than one associated encryption algorithm if they share the same wire-key format, string-to-key function, default string-to-key-parameters, and key derivation function. (This combination means that, for example, a checksum type, key usage value, and password are adequate to get the specific key used to compute a checksum.)
それらが同じワイヤキーフォーマット、ストリングからキー機能、デフォルトの文字列のキーパラメータ、および鍵導出関数を共有する場合、キー付きチェックサム機構は、複数の関連した暗号化アルゴリズムを有することができます。 （この組み合わせは、例えば、チェックサムタイプ、キー使用値、およびパスワードがチェックサムを計算するために使用される特定のキーを取得するのに十分である、ということを意味します。）
An unkeyed checksum mechanism can be used with any encryption type, as the key is ignored, but its use must be limited to cases where the checksum itself is protected, to avoid trivial attacks.
キーは無視されるようキーなしのチェックサム機構は、任意の暗号化タイプを使用することができますが、その使用は些細な攻撃を避けるために、チェックサム自体が保護されている場合に限定されなければなりません。
get_mic function This function generates a MIC token for a given specific key (see section 3) and message (represented as an octet string) that may be used to verify the integrity of the associated message. This function is not required to return the same deterministic result for each use; it need only generate a token that the verify_mic routine can check.
get_mic関数この関数は、関連するメッセージの完全性を検証するために使用することができる（オクテット文字列として表される）所与の特定のキー（セクション3を参照）、メッセージのMICトークンを生成します。この機能は、用途ごとに同じ決定論的結果を返す必要はありません。それだけでverify_micルーチンがチェックできるというトークンを生成する必要があります。
The output of this function will also dictate the size of the checksum. It must be no larger than 65,535 octets.
この関数の出力は、チェックサムのサイズを決定します。それは65,535オクテットより大きくてはなりません。
verify_mic function Given a specific key, message, and MIC token, this function ascertains whether the message integrity has been compromised. For a deterministic get_mic routine, the corresponding verify_mic may simply generate another checksum and compare the two.
verify_mic機能は、特定のキー、メッセージ、およびMICトークンを考えると、この機能は、メッセージの完全性が損なわれているかどうかを確認します。決定的get_micルーチンのために、対応するverify_micは、単に別のチェックサムを生成し、両者を比較することができます。
The get_mic and verify_mic operations must allow inputs of arbitrary length; if any padding is needed, the padding scheme must be specified as part of these functions.
get_micとverify_mic動作は、任意の長さの入力を可能にしなければなりません。任意のパディングが必要な場合、パディング方式は、これらの機能の一部として指定する必要があります。
These operations and attributes are all that should be required to support Kerberos and various proposed preauthentication schemes.
これらの操作と属性は、Kerberosと様々な提案事前認証スキームをサポートする必要がすべきことはすべてしています。
As with encryption mechanism definition documents, documents defining new checksum mechanisms should indicate validation processes and known weaknesses.
暗号化メカニズムの定義文書と同じように、新しいチェックサムメカニズムを定義する文書は、検証プロセスおよび既知の脆弱性を示す必要があります。
The profile outlined in sections 3 and 4 describes a large number of operations that must be defined for encryption and checksum algorithms to be used with Kerberos. Here we describe a simpler profile that can generate both encryption and checksum mechanism definitions, filling in uses of key derivation in appropriate places, providing integrity protection, and defining multiple operations for the cryptosystem profile based on a smaller set of operations. Not all of the existing cryptosystems for Kerberos fit into this simplified profile, but we recommend that future cryptosystems use it or something based on it [4].
セクション3及び4に概説さプロファイルは、Kerberosで使用する暗号化とチェックサムアルゴリズムのために定義されなければならない動作の多数が記載されています。ここでは、完全性保護を提供し、適切な場所に鍵導出の用途に埋め、両方の暗号化とチェックサムメカニズムの定義を生成することができますシンプルなプロファイルを記述し、業務の小さいセットに基づいて暗号プロファイルに複数の操作を定義します。ないKerberosの既存の暗号システムのすべてが、この単純化されたプロファイルに適合し、我々はそれに基づいて将来の暗号がそれか何かを使用することをお勧めします[4]。
Not all the operations in the complete profiles are defined through this mechanism; several must still be defined for each new algorithm pair.
完全なプロファイルのないすべての操作は、この機構により定義されています。いくつかは、まだそれぞれの新しいアルゴリズムのペアを定義する必要があります。
Rather than define some scheme by which a "protocol key" is composed of a large number of encryption keys, we use keys derived from a base key to perform cryptographic operations. The base key must be used only for generating the derived keys, and this derivation must be non-invertible and entropy preserving. Given these restrictions, compromise of one derived key does not compromise others. Attack of the base key is limited, as it is only used for derivation and is not exposed to any user data.
「プロトコル・キー」は暗号鍵の多数で構成されるいくつかのスキームを定義するのではなく、我々は、暗号化操作を実行するベース鍵から導出鍵を使用します。ベース鍵は、導出鍵を生成するために使用しなければならず、この導出は、非可逆およびエントロピー保存しなければなりません。これらの制限を考えると、1つの派生キーの妥協は他を妥協しません。それが唯一の導出に使用され、任意のユーザデータに露出しないように、ベースキーの攻撃は、限られています。
To generate a derived key from a base key, we generate a pseudorandom octet string by using an algorithm DR, described below, and generate a key from that octet string by using a function dependent on the encryption algorithm. The input length needed for that function, which is also dependent on the encryption algorithm, dictates the length of the string to be generated by the DR algorithm (the value "k" below). These procedures are based on the key derivation in [Blumenthal96].
ベース鍵から導出鍵を生成するために、我々は、以下に説明するアルゴリズムDRを使用して擬似ランダムオクテットストリングを生成し、暗号化アルゴリズムに依存する関数を用いてそのオクテット列から鍵を生成します。また、暗号化アルゴリズムに依存してその機能のために必要な入力の長さは、DRアルゴリズム（以下、値「K」）によって生成される文字列の長さを規定します。これらの手順は、[Blumenthal96]における鍵導出に基づいています。
Derived Key = DK(Base Key, Well-Known Constant)
派生キー= DK（ベース鍵、コンスタントよく知られています）
DK(Key, Constant) = random-to-key(DR(Key, Constant))
DK（キー、定数）=ランダム・ツー・キー（）DR（、キー定数）
DR(Key, Constant) = k-truncate(E(Key, Constant, initial-cipher-state))
DR（キー、定数）= K-TRUNCATE（E（キー、定数、初期暗号化状態））
Here DR is the random-octet generation function described below, and DK is the key-derivation function produced from it. In this construction, E(Key, Plaintext, CipherState) is a cipher, Constant is a well-known constant determined by the specific usage of this function, and k-truncate truncates its argument by taking the first k bits. Here, k is the key generation seed length needed for the encryption system.
ここでDRは、後述するランダムオクテット生成関数であり、DKがそれから製造された鍵導出関数です。この構成では、E（鍵、平文、CipherState）は暗号で、定数は、この関数の特定の使用によって決定される周知の定数であり、k-切り捨ては、第kビットを取ることによって、その引数を切り捨て。ここで、kは暗号化システムのために必要な鍵生成シードの長さです。
The output of the DR function is a string of bits; the actual key is produced by applying the cryptosystem's random-to-key operation on this bitstring.
DR機能の出力は、ビット列です。実際のキーは、このビット列に暗号システムのランダム・ツー・キー操作を適用することによって製造されます。
If the Constant is smaller than the cipher block size of E, then it must be expanded with n-fold() so it can be encrypted. If the output of E is shorter than k bits, it is fed back into the encryption as many times as necessary. The construct is as follows (where | indicates concatentation):
定数は、Eの暗号ブロックサイズよりも小さい場合、それは（N倍で拡大しなければならない）ので、暗号化することができます。 Eの出力は、kビットよりも短い場合には、必要な回数だけバック暗号化に供給されます。 ：|（concatentationを示す）以下のように構築物は、あります
K1 = E(Key, n-fold(Constant), initial-cipher-state) K2 = E(Key, K1, initial-cipher-state) K3 = E(Key, K2, initial-cipher-state) K4 = ...
K1 = E（キー、N倍（定数）、初期暗号状態）K2 = E（キー、K1、初期暗号状態）K3 = E（キー、K2、初期暗号状態）K4 =。 。..
DR(Key, Constant) = k-truncate(K1 | K2 | K3 | K4 ...)
DR（キー、定数）= K-TRUNCATE（K1 | K2 | K3 | K4 ...）
n-fold is an algorithm that takes m input bits and "stretches" them to form n output bits with equal contribution from each input bit to the output, as described in [Blumenthal96]:
N倍の[Blumenthal96]に記載されているように、出力に各入力ビットから等しい寄与を有するm個の入力ビットと、それらを形成するための「ストレッチ」n個の出力ビットを要するアルゴリズムです。
We first define a primitive called n-folding, which takes a variable-length input block and produces a fixed-length output sequence. The intent is to give each input bit approximately equal weight in determining the value of each output bit. Note that whenever we need to treat a string of octets as a number, the assumed representation is Big-Endian -- Most Significant Byte first.
まず、可変長入力ブロックを取り、固定長の出力シーケンスを生成する、N折りと呼ばれるプリミティブを定義します。目的は、各出力ビットの値を決定する際に、各入力ビットにほぼ等しい重みを与えることです。私たちは数としてオクテットの文字列を処理するために必要なとき、仮定表現はビッグエンディアンであることに注意してください - 最上位バイトが最初。
To n-fold a number X, replicate the input value to a length that is the least common multiple of n and the length of X. Before each repetition, the input is rotated to the right by 13 bit positions. The successive n-bit chunks are added together using 1's-complement addition (that is, with end-around carry) to yield a n-bit result....
数XをN倍Nの最小公倍数と各繰り返しの前に、Xの長さである長さへの入力値を複製し、入力が13ビット位置だけ右に回転させられます。連続したnビットのチャンクは、nビットの結果を生成する（すなわち、エンド持ち歩くである）1's補体添加を使用して加算され....
Test vectors for n-fold are supplied in appendix A [5].
N倍のためのテストベクトルは、付録Aに供給される[5]。
In this section, n-fold is always used to produce c bits of output, where c is the cipher block size of E.
このセクションでは、N倍は常にcはE.の暗号ブロックサイズであり、出力のCビットを生成するために使用されます
The size of the Constant must not be larger than c, because reducing the length of the Constant by n-folding can cause collisions.
n型折りたたみによって一定の長さを低減することが、衝突を引き起こす可能性があるので、一定の大きさは、Cより大きくてはなりません。
If the size of the Constant is smaller than c, then the Constant must be n-folded to length c. This string is used as input to E. If the block size of E is less than the random-to-key input size, then the output from E is taken as input to a second invocation of E. This process is repeated until the number of bits accumulated is greater than or equal to the random-to-key input size. When enough bits have been computed, the first k are taken as the random data used to create the key with the algorithm-dependent random-to-key function.
定数の大きさがcよりも小さい場合は、定数は、長さcにn型に折り畳まれなければなりません。 Eのブロックサイズがランダムにキー入力サイズより小さい場合、この文字列は、その後、Eからの出力はEの第二の呼び出しへの入力として取り込まれる。このプロセスは数まで繰り返され、E.への入力として使用されます蓄積されたビットのランダムにキー入力の大きさ以上です。十分なビットが計算されている場合、最初のkは、アルゴリズムに依存するランダム・ツー・キー機能を持つキーを作成するために使用されるランダムデータとして取り込まれます。
As the derived key is the result of one or more encryptions in the base key, deriving the base key from the derived key is equivalent to determining the key from a very small number of plaintext/ciphertext pairs. Thus, this construction is as strong as the cryptosystem itself.
導出鍵は、基本キー内の1つまたは複数の暗号化の結果であるように、導出鍵からベース鍵を導出することは、平文/暗号文ペアの非常に少ない数のキーを決定することと等価です。したがって、この構造は、暗号そのものと同じくらい強いです。
These are the operations and attributes that must be defined:
これらは、定義されなければならない操作と属性です。
protocol key format string-to-key function default string-to-key parameters key-generation seed length, k random-to-key function As above for the normal encryption mechanism profile.
プロトコルキーフォーマットストリングからキー機能デフォルトストリングから重要なパラメータ鍵生成シード長、通常の暗号化メカニズムプロファイルの上記のようにランダムにキー機能をKです。
unkeyed hash algorithm, H This should be a collision-resistant hash algorithm with fixed-size output, suitable for use in an HMAC [HMAC]. It must support inputs of arbitrary length. Its output must be at least the message block size (below).
キーなしハッシュアルゴリズム、Hこれは、HMAC [HMAC]で使用するのに適した固定サイズの出力との衝突耐性ハッシュアルゴリズムであるべきです。これは、任意の長さの入力をサポートしている必要があります。その出力は、少なくともメッセージのブロックサイズ（以下）でなければなりません。
HMAC output size, h This indicates the size of the leading substring output by the HMAC function that should be used in transmitted messages. It should be at least half the output size of the hash function H, and at least 80 bits; it need not match the output size.
HMACの出力サイズ、Hこれは、送信されたメッセージで使用されるべきであるHMAC関数によって主要サブ出力の大きさを示しています。これは、少なくとも半分の出力ハッシュ関数Hの大きさ、および少なくとも80ビットであるべきです。それは、出力サイズと一致する必要はありません。
message block size, m This is the size of the smallest units the cipher can handle in the mode in which it is being used. Messages will be padded to a multiple of this size. If a block cipher is used in a mode that can handle messages that are not multiples of the cipher block size, such as CBC mode with cipher text stealing (CTS, see [RC5]), this value would be one octet. For traditional CBC mode with padding, it would be the underlying cipher's block size.
メッセージブロックサイズは、これは、暗号化は、それが使用されているモードで扱うことができる最小単位のサイズはM。メッセージは、このサイズの倍数に水増しされます。ブロック暗号は、暗号文を盗んで、そのようなCBCモードとして暗号ブロックサイズの倍数ではないメッセージを処理することができるモードで使用される場合（CTSを、[RC5]を参照）、この値は1つのオクテットであろう。詰め物との伝統的なCBCモードの場合は、基本となる暗号のブロックサイズになります。
This value must be a multiple of eight bits (one octet).
この値は8ビット（1つのオクテット）の倍数でなければなりません。
encryption/decryption functions, E and D These are basic encryption and decryption functions for messages of sizes that are multiples of the message block size. No integrity checking or confounder should be included here. For inputs these functions take the IV or similar data, a protocol-format key, and an octet string, returning a new IV and octet string.
暗号化/復号化機能、EおよびDは、これらのメッセージのブロックサイズの倍数であるサイズのメッセージのための基本的な暗号化と復号化機能です。いいえ整合性チェックや交絡因子は、ここに含まれるべきではありません。入力の場合、これらの機能は、新しいIVとオクテット文字列を返す、IVまたは類似のデータ、プロトコル形式のキー、およびオクテット文字列を取ります。
The encryption function is not required to use CBC mode but is assumed to be using something with similar properties. In particular, prepending a cipher block-size confounder to the plaintext should alter the entire ciphertext (comparable to choosing and including a random initial vector for CBC mode).
暗号化機能は、CBCモードを使用する必要はありませんが、同様の性質を持つものを使用するものとします。具体的には、平文に暗号ブロックサイズの交絡因子を付加する（CBCモードのランダムな初期ベクトルを選択することとを含むと同等）全体暗号文を変更しなければなりません。
The result of encrypting one cipher block (of size c, above) must be deterministic for the random octet generation function DR in the previous section to work. For best security, it should also be no larger than c.
1つの暗号ブロック暗号の結果（サイズCのは、上記）動作するように、前のセクションでランダムオクテット生成関数DRのために決定的でなければなりません。最高のセキュリティを強化するために、それはまた、Cを超えないようにしてください。
cipher block size, c This is the block size of the block cipher underlying the encryption and decryption functions indicated above, used for key derivation and for the size of the message confounder and initial vector. (If a block cipher is not in use, some comparable parameter should be determined.) It must be at least 5 octets.
このC暗号ブロックサイズは、鍵導出のために、メッセージの交絡因子と初期ベクトルの大きさのために使用される上記に示した暗号化と復号化機能の基礎となるブロック暗号のブロックサイズです。 （ブロック暗号が使用されていない場合は、いくつかの同等のパラメータが決定されるべきである。）は、少なくとも5つのオクテットでなければなりません。
This is not actually an independent parameter; rather, it is a property of the functions E and D. It is listed here to clarify the distinction between it and the message block size, m.
これは、実際には独立したパラメータではありません。むしろ、それとメッセージブロックサイズ、Mとの区別を明確にするためにここに記載されている機能E及びDの性質です。
Although there are still a number of properties to specify, they are fewer and simpler than in the full profile.
指定するプロパティの数が残っているが、それらは完全プロフィールに比べて少なく、単純です。
The above key derivation function is used to produce three intermediate keys. One is used for computing checksums of unencrypted data. The other two are used for encrypting and checksumming plaintext to be sent encrypted.
上記鍵導出関数は、3つの中間鍵を生成するために使用されます。一つは暗号化されていないデータのチェックサムを計算するために使用されます。他の二つは、暗号化して送信する平文を暗号化し、チェックサムのために使用されています。
The ciphertext output is the concatenation of the output of the basic encryption function E and a (possibly truncated) HMAC using the specified hash function H, both applied to the plaintext with a random confounder prefix and sufficient padding to bring it to a multiple of the message block size. When the HMAC is computed, the key is used in the protocol key form.
暗号文出力は、基本的な暗号化関数Eの出力と指定されたハッシュ関数Hを用いて（おそらくは切り捨て）HMACを連結し、その両方は、ランダム交絡因子プレフィックスと十分なパディングで平文に適用さの倍数にそれをもたらすことメッセージブロックサイズ。 HMACを計算するときに、キーは、プロトコルキーの形態で使用されます。
Decryption is performed by removing the (partial) HMAC, decrypting the remainder, and verifying the HMAC. The cipher state is an initial vector, initialized to zero.
復号化は、（部分的）HMACを除去し、残りを解読し、HMACを検証することによって行われます。暗号状態はゼロに初期化初期ベクトル、です。
The substring notation "[1..h]" in the following table should be read as using 1-based indexing; leading substrings are used.
ストリング表記「[1..h」次の表の1ベースのインデックスを使用するものとして読まれるべきです。主要な部分文字列が使用されています。
Cryptosystem from Simplified Profile
------------------------------------------------------------------------
protocol key format As given.
specific key structure Three protocol-format keys: { Kc, Ke, Ki }.
特定のキー構造三つのプロトコルフォーマットキー：{Kcを、Keを、Kiを}。
key-generation seed As given. length
鍵生成シードが与えられたよう。長さ
required checksum As defined below in section 5.4. mechanism
セクション5.4で以下に定義されるチェックサムを必要としました。機構
cipher state Initial vector (usually of length c)
暗号状態初期ベクトル（通常長さCの）
initial cipher state All bits zero
すべてのビットがゼロに初期暗号状態
encryption function conf = Random string of length c pad = Shortest string to bring confounder and plaintext to a length that's a multiple of m. (C1, newIV) = E(Ke, conf | plaintext | pad, oldstate.ivec) H1 = HMAC(Ki, conf | plaintext | pad) ciphertext = C1 | H1[1..h] newstate.ivec = newIV
暗号化機能confに=長さcパッド=最短の文字列のランダムな文字列がmの倍数だ長さに交絡因子と平文をもたらすために。 （C1、newIV）= E（Keを、CONF |平文|パッド、oldstate.ivec）H1 = HMAC（KI、CONF |平文|パッド）暗号文= C1 | H1 [1..h] newstate.ivec = newIV
decryption function (C1,H1) = ciphertext (P1, newIV) = D(Ke, C1, oldstate.ivec) if (H1 != HMAC(Ki, P1)[1..h]) report error newstate.ivec = newIV
復号化機能（C1、H1）=暗号文（P1、newIV）= D（ケ、C1、oldstate.ivec）IF（H1！= HMAC（KI、P1）1..h]）エラー報告newstate.ivec = newIV
default string-to-key As given. params
デフォルトの文字列からキーへ与えられるように。 params
pseudo-random function tmp1 = H(octet-string) tmp2 = truncate tmp1 to multiple of m PRF = E(DK(protocol-key, prfconstant), tmp2, initial-cipher-state)
擬似ランダム関数TMP1 = H（オクテットストリング）TMP2 = MのPRF = E（DK（プロトコルキー、prfconstant）、TMP2、初期暗号状態）の倍数にTMP1を切り捨てます
The "prfconstant" used in the PRF operation is the three-octet string "prf".
PRF操作で使用される「prfconstantは、」「PRF」3オクテット文字列です。
Cryptosystem from Simplified Profile
------------------------------------------------------------------------
key generation functions:
string-to-key function As given.
与えられたとして、文字列からキーへの機能。
random-to-key function As given.
ランダム・ツー・キー機能与えられたよう。
key-derivation function The "well-known constant" used for the DK function is the key usage number, expressed as four octets in big-endian order, followed by one octet indicated below.
1つのオクテットに続くビッグエンディアン順における4つのオクテットは、以下に示すようにキー導出関数はDKの機能のために使用される「周知の定数は」鍵使用数である、発現。
Kc = DK(base-key, usage | 0x99);
Ke = DK(base-key, usage | 0xAA);
Ki = DK(base-key, usage | 0x55);
When an encryption system is defined with the simplified profile given in section 5.2, a checksum algorithm may be defined for it as follows:
暗号化システムは、セクション5.2で与えられた単純化されたプロファイルで定義されている場合、次のように、チェックサムアルゴリズムはそれを定義することができます。
Checksum Mechanism from Simplified Profile
--------------------------------------------------
associated cryptosystem As defined above.
get_mic HMAC(Kc, message)[1..h]
get_mic HMAC（Kcを、メッセージ）[1..h]
verify_mic get_mic and compare
verify_mic get_micと比較
The HMAC function and key Kc are as described in section 5.3.
HMAC関数及び鍵Kcはとしてのセクション5.3に記載されています。
These profiles describe the encryption and checksum systems defined for Kerberos. The astute reader will notice that some of them do not fulfill all the requirements outlined in previous sections. These systems are defined for backward compatibility; newer implementations should (whenever possible) attempt to utilize encryption systems that satisfy all the profile requirements.
これらのプロファイルは、Kerberos用に定義された暗号化とチェックサムのシステムを説明します。賢明な読者はそれらのいくつかは、前のセクションに記載されているすべての要件を満たしていないことがわかります。これらのシステムは、下位互換性のために定義されています。新しい実装では、（可能な限り）すべてのプロファイルの要件を満たす暗号化システムを利用することを試みるべきです。
The full list of current encryption and checksum type number assignments, including values currently reserved but not defined in this document, is given in section 8.
現在予約この文書で定義されていない値を含む現在の暗号化とチェックサムタイプ番号割り当ての完全なリストは、セクション8に記載されています。
These checksum types use no encryption keys and thus can be used in combination with any encryption type, but they may only be used with caution, in limited circumstances where the lack of a key does not provide a window for an attack, preferably as part of an encrypted message [6]. Keyed checksum algorithms are recommended.
これらのチェックサムの種類には、暗号化キーを使用しないため、任意の暗号化タイプと組み合わせて使用することができますが、彼らは唯一の好ましいの一環として、キーの欠如は攻撃のためにウィンドウを提供していない限定された状況では、注意して使用することができます暗号化されたメッセージ[6]。キー付きチェックサムアルゴリズムが推奨されています。
The RSA-MD5 checksum calculates a checksum by using the RSA MD5 algorithm [MD5-92]. The algorithm takes as input an input message of arbitrary length and produces as output a 128-bit (sixteen octet) checksum.
RSA-MD5チェックサムは、RSA MD5アルゴリズム[MD5-92]を使用してチェックサムを計算します。アルゴリズムは、入力として任意の長さの入力メッセージを受け取り、出力として128ビット（16オクテット）のチェックサムを生成します。
rsa-md5
----------------------------------------------
associated cryptosystem any
get_mic rsa-md5(msg)
get_mic RSA-MD5（MSG）
verify_mic get_mic and compare
verify_mic get_micと比較
The rsa-md5 checksum algorithm is assigned a checksum type number of seven (7).
RSA-MD5チェックサムアルゴリズムは、7つのチェックサムタイプ番号が割り当てられている（7）。
The RSA-MD4 checksum calculates a checksum using the RSA MD4 algorithm [MD4-92]. The algorithm takes as input an input message of arbitrary length and produces as output a 128-bit (sixteen octet) checksum.
RSA-MD4チェックサムは、RSA MD4アルゴリズム[MD4-92]を使用してチェックサムを計算します。アルゴリズムは、入力として任意の長さの入力メッセージを受け取り、出力として128ビット（16オクテット）のチェックサムを生成します。
rsa-md4
----------------------------------------------
associated cryptosystem any
get_mic md4(msg)
get_mic MD4（MSG）
verify_mic get_mic and compare
verify_mic get_micと比較
The rsa-md4 checksum algorithm is assigned a checksum type number of two (2).
RSA-MD4チェックサムアルゴリズムは、2つのチェックサムタイプ番号が割り当てられている（2）。
This CRC-32 checksum calculates a checksum based on a cyclic redundancy check as described in ISO 3309 [CRC] but modified as described below. The resulting checksum is four (4) octets in length. The CRC-32 is neither keyed nor collision-proof; thus, the use of this checksum is not recommended. An attacker using a probabilistic chosen-plaintext attack as described in [SG92] might be able to generate an alternative message that satisfies the checksum.
このCRC-32チェックサムはISO 3309 [CRC]に記載が、以下に説明するように修正された巡回冗長検査に基づいてチェックサムを計算します。得られたチェックサムは、長さが4つのオクテットです。 CRC-32は、キー入力や衝突防止でもありません。したがって、このチェックサムの使用は推奨されません。 [SG92]に記載されているように、確率的選択平文攻撃を使用して、攻撃者は、チェックサムを満たす別のメッセージを生成することができるかもしれません。
The CRC-32 checksum used in the des-cbc-crc encryption mode is identical to the 32-bit FCS described in ISO 3309 with two exceptions: The sum with the all-ones polynomial times x**k is omitted, and the final remainder is not ones-complemented. ISO 3309 describes the FCS in terms of bits, whereas this document describes the Kerberos protocol in terms of octets. To clarify the ISO 3309 definition for the purpose of computing the CRC-32 in the des-cbc-crc encryption mode, the ordering of bits in each octet shall be assumed to be LSB first. Given this assumed ordering of bits within an octet, the mapping of bits to polynomial coefficients shall be identical to that specified in ISO 3309.
最終全もの多項式時間Xと合計が** kが省略され、そして：DES-CBC-CRC暗号化モードで使用されるCRC-32チェックサムは、2つの例外を除き、ISO 3309に記載された32ビットのFCSと同一であります残りはもの-補完ではありません。この文書はオクテットの点でKerberosプロトコルを記載しているのに対し、ISO 3309は、ビットの点でFCSを記載しています。 DES-CBC-CRC暗号化モードでCRC-32を計算するためにISO 3309の定義を明確にするために、各オクテット内のビットの順序は、最初のLSBであると仮定しなければなりません。これはオクテット内のビットの順序を想定与え、多項式係数に対するビットのマッピングは、ISO 3309で指定されたものと同一でなければなりません。
Test values for this modified CRC function are included in appendix A.5.
この変形CRC関数の試験値は付録A.5に含まれています。
crc32
----------------------------------------------
associated cryptosystem any
get_mic crc32(msg)
get_mic CRC32（MSG）
verify_mic get_mic and compare
verify_mic get_micと比較
The crc32 checksum algorithm is assigned a checksum type number of one (1).
CRC32チェックサムアルゴリズムは、一つのチェックサムタイプ番号が割り当てられている（1）。
These encryption systems encrypt information under the Data Encryption Standard [DES77] by using the cipher block chaining mode [DESM80]. A checksum is computed as described below and placed in the cksum field. DES blocks are eight bytes. As a result, the data to be encrypted (the concatenation of confounder, checksum, and message) must be padded to an eight byte boundary before encryption. The values of the padding bytes are unspecified.
これらの暗号化システムは、暗号ブロック連鎖モード[DESM80]を使用して、データ暗号化標準[DES77]の情報を暗号化します。以下で説明するとcksumのフィールドに配置されたように、チェックサムが計算されます。 DESブロックは8バイトです。その結果、暗号化するデータ（交絡因子、チェックサム、およびメッセージの連結）は、暗号化前の8つのバイト境界までパディングされなければなりません。パディングバイトの値が指定されていません。
Plaintext and DES ciphertext are encoded as blocks of eight octets, which are concatenated to make the 64-bit inputs for the DES algorithms. The first octet supplies the eight most significant bits (with the octet's MSB used as the DES input block's MSB, etc.), the second octet the next eight bits, and so on. The eighth octet supplies the 8 least significant bits.
平文とDESの暗号文は、DESアルゴリズムのための64ビット入力を行うために連結された8バイトのブロックとして符号化されます。最初のオクテットはそうで上位8ビット（オクテットのMSB等DES入力ブロックのMSBとして使用して）、第2オクテットの次の8ビットを供給し、。第八のオクテットは8つの最下位ビットを供給する。
Encryption under DES using cipher block chaining requires an additional input in the form of an initialization vector; this vector is specified below for each encryption system.
暗号ブロック連鎖を使用して、DESの下の暗号化は、初期化ベクトルの形で追加の入力を必要とします。このベクトルは、各暗号化システムについては、以下を指定されています。
The DES specifications [DESI81] identify four 'weak' and twelve 'semi-weak' keys; these keys SHALL NOT be used for encrypting messages for use in Kerberos. The "variant keys" generated for the RSA-MD5-DES, RSA-MD4-DES, and DES-MAC checksum types by an eXclusive-OR of a DES key with a constant are not checked for this property.
DES仕様は[DESI81] 4「弱」および12「半弱」キーを識別する。これらのキーは、Kerberosで使用するためのメッセージを暗号化するために使用してはなりません。定数でDESキーの排他的論理和によりRSA-MD5-DES、RSA-MD4-DES、およびDES-MACチェックサム・タイプに対して生成された「バリアント・キーは、」このプロパティにチェックされません。
A DES key is eight octets of data. This consists of 56 bits of actual key data, and eight parity bits, one per octet. The key is encoded as a series of eight octets written in MSB-first order. The bits within the key are also encoded in MSB order. For example, if the encryption key is (B1,B2,...,B7,P1,B8,...,B14,P2,B15,...,B49,P7,B50,...,B56,P8), where B1,B2,...,B56 are the key bits in MSB order, and P1,P2,...,P8 are the parity bits, the first octet of the key would be B1,B2,...,B7,P1 (with B1 as the most significant bit). See the [DESM80] introduction for reference.
DESキーは、データの8つのオクテットです。これは、実際の鍵データの56ビット、8つのパリティビット、オクテット当たり一つから構成されています。キーは、MSBファーストために書かれた8つのオクテットの一連として符号化されます。キー内のビットもMSBの順に符号化されます。例えば、暗号化キーは、（B1、B2、...、B7、P1、B8、···、B14、P2、B15、...、B49、P7、B50、...、B56、P8である場合）、ここで、B1、B2、...は、B56は、MSBの順にキービットであり、P1、P2、...、P8パリティビットで、キーの最初のオクテットはB1、B2、あろう··· 、B7、P1（最上位ビットとしてB1を有します）。参照のための[DESM80]導入を参照してください。
Encryption Data Format
暗号化データフォーマット
The format for the data to be encrypted includes a one-block confounder, a checksum, the encoded plaintext, and any necessary padding, as described in the following diagram. The msg-seq field contains the part of the protocol message to be encrypted.
次の図で説明したように暗号化されるデータの形式は、1ブロックの交絡因子、チェックサム、符号化された平文、及び任意の必要なパディングを含みます。 MSG-seqのフィールドが暗号化されるプロトコルメッセージの一部が含まれています。
+-----------+----------+---------+-----+
|confounder | checksum | msg-seq | pad |
+-----------+----------+---------+-----+
One generates a random confounder of one block, placing it in 'confounder'; zeros out the 'checksum' field (of length appropriate to exactly hold the checksum to be computed); adds the necessary padding; calculates the appropriate checksum over the whole sequence, placing the result in 'checksum'; and then encrypts using the specified encryption type and the appropriate key.
一つは「交絡因子」に置く、一つのブロックのランダムな交絡因子を生成します。 （正確に計算されるチェックサムを保持するのに適切な長さの）「チェックサム」フィールドのうちのゼロ、必要なパディングを追加します。 「チェックサム」で結果を確定する、シーケンス全体にわたって適切なチェックサムを計算します。その後、指定された暗号化の種類と適切なキーを使用して暗号化します。
String or Random-Data to Key Transformation
鍵変換する文字列またはランダムデータ
To generate a DES key from two UTF-8 text strings (password and salt), the two strings are concatenated, password first, and the result is then padded with zero-valued octets to a multiple of eight octets.
2 UTF-8テキスト文字列（パスワード及び塩）からDES鍵を生成するために、二つの文字列が連結され、第一のパスワード、および結果は8つのオクテットの倍数にゼロ値のオクテットでパディングされます。
The top bit of each octet (always zero if the password is plain ASCII, as was assumed when the original specification was written) is discarded, and the remaining seven bits of each octet form a bitstring. This is then fan-folded and eXclusive-ORed with itself to produce a 56-bit string. An eight-octet key is formed from this string, each octet using seven bits from the bitstring, leaving the least significant bit unassigned. The key is then "corrected" by correcting the parity on the key, and if the key matches a 'weak' or 'semi-weak' key as described in the DES specification, it is eXclusive-ORed with the constant 0x00000000000000F0. This key is then used to generate a DES CBC checksum on the initial string with the salt appended. The result of the CBC checksum is then "corrected" as described above to form the result, which is returned as the key.
各オクテットの最上位ビットは破棄され、各オクテットの残りの7ビットはビット文字列を形成する（常に元の仕様が書き込まれたときに仮定したように、パスワードは、プレーンASCIIである場合はゼロ）。これは、56ビットのビット列を生成するために、それ自体で、次いでファン折りと排他的論理和です。 8オクテットキーが割り当てられていない最下位ビットを残して、この文字列、ビット文字列から7ビットを用いて各オクテットから形成されています。キーは、キーにパリティを補正することにより、「修正」であり、キーは、DES仕様に記載されているように「弱い」または「半弱」キーと一致した場合、それは一定の0x00000000000000F0との排他的論理和です。このキーは、その後、追加塩との最初の文字列のDES CBCチェックサムを生成するために使用されます。 CBCチェックサムの結果は、上記のように、キーとして返された結果を、形成する「補正」です。
For purposes of the string-to-key function, the DES CBC checksum is calculated by CBC encrypting a string using the key as IV and the final eight byte block as the checksum.
ストリングからキー機能の目的のために、DES CBCチェックサムは、IVとしてキーとチェックサムのような最後の8つのバイトブロックを使用して文字列を暗号化CBCによって計算されます。
Pseudocode follows:
擬似コードは次のとおりです。
removeMSBits(8byteblock) {
/* Treats a 64 bit block as 8 octets and removes the MSB in
each octet (in big endian mode) and concatenates the
result. E.g., the input octet string:
01110000 01100001 11110011 01110011 11110111 01101111
11110010 01100100
results in the output bitstring:
1110000 1100001 1110011 1110011 1110111 1101111
1110010 1100100 */
}
reverse(56bitblock) {
/* Treats a 56-bit block as a binary string and reverses it.
E.g., the input string:
1000001 1010100 1001000 1000101 1001110 1000001
0101110 1001101
results in the output string:
1011001 0111010 1000001 0111001 1010001 0001001
0010101 1000001 */
} add_parity_bits(56bitblock) {
/* Copies a 56-bit block into a 64-bit block, left shifts
content in each octet, and add DES parity bit.
E.g., the input string:
1100000 0001111 0011100 0110100 1000101 1100100
0110110 0010111
results in the output string:
11000001 00011111 00111000 01101000 10001010 11001000
01101101 00101111 */
}
key_correction(key) {
fixparity(key);
if (is_weak_key(key))
key = key XOR 0xF0;
return(key);
}
mit_des_string_to_key(string,salt) {
odd = 1;
s = string | salt;
tempstring = 0; /* 56-bit string */
pad(s); /* with nulls to 8 byte boundary */
for (8byteblock in s) {
56bitstring = removeMSBits(8byteblock);
if (odd == 0) reverse(56bitstring);
odd = ! odd;
tempstring = tempstring XOR 56bitstring;
}
tempkey = key_correction(add_parity_bits(tempstring));
key = key_correction(DES-CBC-check(s,tempkey));
return(key);
}
des_string_to_key(string,salt,params) {
if (length(params) == 0)
type = 0;
else if (length(params) == 1)
type = params[0];
else
error("invalid params");
if (type == 0)
mit_des_string_to_key(string,salt);
else
error("invalid params");
}
One common extension is to support the "AFS string-to-key" algorithm, which is not defined here, if the type value above is one (1).
一つの一般的な拡張は、上記のタイプの値が1（1）である場合、ここで定義されていない「AFS列対鍵」アルゴリズムをサポートすることです。
For generation of a key from a random bitstring, we start with a 56- bit string and, as with the string-to-key operation above, insert parity bits. If the result is a weak or semi-weak key, we modify it by eXclusive-OR with the constant 0x00000000000000F0:
ランダムビットストリングから鍵を生成するために、我々は、上記ストリングからキー操作と同様に、パリティビットを挿入し、56ビットのビット列から始めて。結果は、弱または半弱の鍵であるならば、我々は排他的論理和定数0x00000000000000F0とのことで、それを変更します。
des_random_to_key(bitstring) {
return key_correction(add_parity_bits(bitstring));
}
The des-cbc-md5 encryption mode encrypts information under DES in CBC mode with an all-zero initial vector and with an MD5 checksum (described in [MD5-92]) computed and placed in the checksum field.
DES-CBC-MD5暗号化モードは、すべてゼロの初期ベクトルとし、計算されたチェックサムフィールドに配置（[MD5-92]に記載されている）MD5チェックサムとCBCモードのDESの下で情報を暗号化します。
The encryption system parameters for des-cbc-md5 are as follows:
次のようにDES-CBC-MD5の暗号化システムパラメータは以下のとおりです。
des-cbc-md5
--------------------------------------------------------------------
protocol key format 8 bytes, parity in low bit of each
specific key structure copy of original key
元のキーの特定のキー構造のコピー
required checksum rsa-md5-des mechanism
必要なチェックサムRSA-MD5-DESメカニズム
key-generation seed 8 bytes length
鍵生成シード8バイト長
cipher state 8 bytes (CBC initial vector)
暗号状態8バイト（CBC初期ベクトル）
initial cipher state all-zero
すべてゼロの初期暗号状態
encryption function des-cbc(confounder | checksum | msg | pad, ivec=oldstate) where checksum = md5(confounder | 0000... | msg | pad)
暗号化機能DES-CBC（交絡因子|チェックサム| MSG |パッド、IVEC = oldstate）ここでチェックサム= MD5（交絡因子| 0000 ... | MSG |パッド）
newstate = last block of des-cbc output
DES-CBC出力のNewStateに=最後のブロック
decryption function decrypt encrypted text and verify checksum
復号化機能は、暗号化されたテキストを復号化し、チェックサムを検証します
newstate = last block of ciphertext
暗号文のNewStateに=最後のブロック
des-cbc-md5
--------------------------------------------------------------------
default string-to-key empty string
params
pseudo-random function des-cbc(md5(input-string), ivec=0)
擬似ランダム関数DES-CBC（MD5（入力文字列）、IVEC = 0）
key generation functions:
鍵生成機能：
string-to-key des_string_to_key
文字列からキーへのdes_string_to_key
random-to-key des_random_to_key
ランダムにキーdes_random_to_key
key-derivation identity
キー導出アイデンティティ
The des-cbc-md5 encryption type is assigned the etype value three (3).
DES-CBC-MD5暗号化タイプはETYPE値3が割り当てられている（3）。
The des-cbc-md4 encryption mode also encrypts information under DES in CBC mode, with an all-zero initial vector. An MD4 checksum (described in [MD4-92]) is computed and placed in the checksum field.
DES-CBC-MD4暗号化モードは、すべてゼロの初期ベクトルと、CBCモードのDESの下で情報を暗号化します。 （[MD4-92]に記載）MD4チェックサムが計算されたチェックサムフィールドに置かれます。
des-cbc-md4
--------------------------------------------------------------------
protocol key format 8 bytes, parity in low bit of each
specific key structure copy of original key
元のキーの特定のキー構造のコピー
required checksum rsa-md4-des mechanism
必要なチェックサムRSA-MD4-DESメカニズム
key-generation seed 8 bytes length
鍵生成シード8バイト長
cipher state 8 bytes (CBC initial vector)
暗号状態8バイト（CBC初期ベクトル）
initial cipher state all-zero
すべてゼロの初期暗号状態
encryption function des-cbc(confounder | checksum | msg | pad, ivec=oldstate) where checksum = md4(confounder | 0000... | msg | pad)
暗号化機能DES-CBC（交絡因子|チェックサム| MSG |パッド、IVEC = oldstate）ここでチェックサム= MD4（交絡因子| 0000 ... | MSG |パッド）
newstate = last block of des-cbc output
DES-CBC出力のNewStateに=最後のブロック
des-cbc-md4
--------------------------------------------------------------------
decryption function decrypt encrypted text and verify checksum
復号化機能は、暗号化されたテキストを復号化し、チェックサムを検証します
newstate = last block of ciphertext
暗号文のNewStateに=最後のブロック
default string-to-key empty string params
デフォルトの文字列からキーへの空の文字列のparams
pseudo-random function des-cbc(md5(input-string), ivec=0)
擬似ランダム関数DES-CBC（MD5（入力文字列）、IVEC = 0）
key generation functions:
鍵生成機能：
string-to-key des_string_to_key
文字列からキーへのdes_string_to_key
random-to-key copy input, then fix parity bits
ランダム・ツー・コピーキー入力し、パリティビットを修正
key-derivation identity
キー導出アイデンティティ
Note that des-cbc-md4 uses md5, not md4, in the PRF definition.
PRF定義ではなく、MD4、DES-CBC-MD4は、MD5を使用することに注意してください。
The des-cbc-md4 encryption algorithm is assigned the etype value two (2).
DES-CBC-MD4暗号化アルゴリズムはETYPE値2が割り当てられている（2）。
The des-cbc-crc encryption type uses DES in CBC mode with the key used as the initialization vector, with a four-octet CRC-based checksum computed as described in section 6.1.3. Note that this is not a standard CRC-32 checksum, but a slightly modified one.
DES-CBC-CRC暗号化の種類は、セクション6.1.3に記載したように計算された4オクテットCRCベースのチェックサムを用いて、初期化ベクトルとして使用される鍵とCBCモードのDESを使用します。これは標準CRC-32チェックサムが、わずかに改変ものではないことに留意されたいです。
des-cbc-crc
--------------------------------------------------------------------
protocol key format 8 bytes, parity in low bit of each
specific key structure copy of original key
元のキーの特定のキー構造のコピー
required checksum rsa-md5-des mechanism
必要なチェックサムRSA-MD5-DESメカニズム
key-generation seed 8 bytes length
鍵生成シード8バイト長
cipher state 8 bytes (CBC initial vector)
暗号状態8バイト（CBC初期ベクトル）
des-cbc-crc
--------------------------------------------------------------------
initial cipher state copy of original key
encryption function des-cbc(confounder | checksum | msg | pad, ivec=oldstate) where checksum = crc(confounder | 00000000 | msg | pad)
暗号化機能DES-CBC（交絡因子|チェックサム| MSG |パッド、IVEC = oldstate）ここでチェックサム= CRC（交絡因子| 00000000 | MSG |パッド）
newstate = last block of des-cbc output
DES-CBC出力のNewStateに=最後のブロック
decryption function decrypt encrypted text and verify checksum
復号化機能は、暗号化されたテキストを復号化し、チェックサムを検証します
newstate = last block of ciphertext
暗号文のNewStateに=最後のブロック
default string-to-key empty string params
デフォルトの文字列からキーへの空の文字列のparams
pseudo-random function des-cbc(md5(input-string), ivec=0)
擬似ランダム関数DES-CBC（MD5（入力文字列）、IVEC = 0）
key generation functions:
鍵生成機能：
string-to-key des_string_to_key
文字列からキーへのdes_string_to_key
random-to-key copy input, then fix parity bits
ランダム・ツー・コピーキー入力し、パリティビットを修正
key-derivation identity
キー導出アイデンティティ
The des-cbc-crc encryption algorithm is assigned the etype value one (1).
DES-CBC-CRC暗号化アルゴリズムはETYPE値1が割り当てられる（1）。
The RSA-MD5-DES checksum calculates a keyed collision-proof checksum by prepending an eight octet confounder before the text, applying the RSA MD5 checksum algorithm, and encrypting the confounder and the checksum by using DES in cipher-block-chaining (CBC) mode with a variant of the key, where the variant is computed by eXclusive-ORing the key with the hexadecimal constant 0xF0F0F0F0F0F0F0F0. The initialization vector should be zero. The resulting checksum is 24 octets long.
RSA-MD5、DESチェックサムは、テキストの前に8つのオクテット交絡因子を付加RSA MD5チェックサムアルゴリズムを適用し、交絡因子と暗号ブロック連鎖にDESを使用してチェックサムを暗号化することにより、キー付き衝突防止チェックサムを計算（CBC）変異体は、排他的論理和16進定数0xF0F0F0F0F0F0F0F0と鍵によって計算されたキーの変異体を有するモード。初期化ベクトルはゼロであるべきです。結果のチェックサムは24オクテットの長さです。
rsa-md5-des
----------------------------------------------------------------
associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc
get_mic des-cbc(key XOR 0xF0F0F0F0F0F0F0F0, conf | rsa-md5(conf | msg))
get_mic DES-CBC（キーXOR 0xF0F0F0F0F0F0F0F0、confに| RSA-MD5（confに| MSG））
verify_mic decrypt and verify rsa-md5 checksum
verify_mic解読し、RSA-MD5チェックサムを検証します
The rsa-md5-des checksum algorithm is assigned a checksum type number of eight (8).
RSA-MD5、DESチェックサムアルゴリズムは、8つのチェックサムタイプ番号が割り当てられている（8）。
The RSA-MD4-DES checksum calculates a keyed collision-proof checksum by prepending an eight octet confounder before the text, applying the RSA MD4 checksum algorithm [MD4-92], and encrypting the confounder and the checksum using DES in cipher-block-chaining (CBC) mode with a variant of the key, where the variant is computed by eXclusive-ORing the key with the constant 0xF0F0F0F0F0F0F0F0 [7]. The initialization vector should be zero. The resulting checksum is 24 octets long.
RSA-MD4-DESチェックサムは、テキストの前に8つのオクテット交絡因子を付加[MD4-92] RSA MD4チェックサムアルゴリズムを適用し、暗号ブロック - で交絡因子およびDESを使用してチェックサムを暗号化することにより、キー付き衝突防止チェックサムを計算します変異体は、排他的論理和により計算されたキーの変異体と連鎖（CBC）モード一定0xF0F0F0F0F0F0F0F0と鍵[7]。初期化ベクトルはゼロであるべきです。結果のチェックサムは24オクテットの長さです。
rsa-md4-des
----------------------------------------------------------------
associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc
get_mic des-cbc(key XOR 0xF0F0F0F0F0F0F0F0, conf | rsa-md4(conf | msg), ivec=0)
get_mic DES-CBC（キーXOR 0xF0F0F0F0F0F0F0F0、confに| RSA-MD4（confに| MSG）、IVEC = 0）
verify_mic decrypt and verify rsa-md4 checksum
verify_mic解読し、RSA-MD4チェックサムを検証します
The rsa-md4-des checksum algorithm is assigned a checksum type number of three (3).
RSA-MD4-DESチェックサムアルゴリズムは、3つのチェックサムタイプ番号が割り当てられます。
The RSA-MD4-DES-K checksum calculates a keyed collision-proof checksum by applying the RSA MD4 checksum algorithm and encrypting the results by using DES in cipher block chaining (CBC) mode with a DES key as both key and initialization vector. The resulting checksum is 16 octets long. This checksum is tamper-proof and believed to be collision-proof. Note that this checksum type is the old method for encoding the RSA-MD4-DES checksum; it is no longer recommended.
RSA-MD4-DES-Kチェックサムは、RSA MD4チェックサムアルゴリズムを適用し、鍵および初期化ベクトルの両方としてDES鍵で暗号ブロック連鎖（CBC）モードでDESを使用して結果を暗号化することにより、キー付き衝突防止チェックサムを計算します。結果のチェックサムは16オクテットの長さです。このチェックサムは、改ざん防止、衝突防止であると考えられています。このチェックサムタイプはRSA-MD4-DESチェックサムを符号化するための従来の方法であることに留意されたいです。それはもはや推奨されません。
rsa-md4-des-k
----------------------------------------------------------------
associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc
get_mic des-cbc(key, md4(msg), ivec=key)
get_mic DES-CBC（キー、MD4（MSG）、IVEC =キー）
verify_mic decrypt, compute checksum and compare
verify_mic、復号化チェックサムを計算し、比較します
The rsa-md4-des-k checksum algorithm is assigned a checksum type number of six (6).
RSA-MD4-DES-Kチェックサムアルゴリズムは、6つのチェックサムタイプ番号が割り当てられている（6）。
The DES-MAC checksum is computed by prepending an eight octet confounder to the plaintext, padding with zero-valued octets if necessary to bring the length to a multiple of eight octets, performing a DES CBC-mode encryption on the result by using the key and an initialization vector of zero, taking the last block of the ciphertext, prepending the same confounder, and encrypting the pair by using DES in cipher-block-chaining (CBC) mode with a variant of the key, where the variant is computed by eXclusive-ORing the key with the constant 0xF0F0F0F0F0F0F0F0. The initialization vector should be zero. The resulting checksum is 128 bits (sixteen octets) long, 64 bits of which are redundant. This checksum is tamper-proof and collision-proof.
必要であれば、DES-MACチェックサムは、キーを使用して結果にDES CBCモード暗号化を行う、8つのオクテットの倍数に長さを持ってゼロ値のオクテットでパディング、平文に8つのオクテット交絡因子を付加することによって計算されます。ゼロの初期化ベクトル、暗号文の最後のブロックを取る同じ交絡因子を付加し、変異体がによって計算されたキーの変異体と暗号ブロック連鎖（CBC）モードでDESを使用してペアを暗号化します排他的論理和定数0xF0F0F0F0F0F0F0F0とキー。初期化ベクトルはゼロであるべきです。得られたチェックサムは、128ビット（16オクテット）長、冗長であるの64ビットです。このチェックサムは、改ざん防止、衝突防止です。
des-mac
---------------------------------------------------------------------
associated des-cbc-md5, des-cbc-md4, des-cbc-crc
cryptosystem
get_mic des-cbc(key XOR 0xF0F0F0F0F0F0F0F0, conf | des-mac(key, conf | msg | pad, ivec=0), ivec=0)
get_mic DES-CBC（キーXOR 0xF0F0F0F0F0F0F0F0、confに| DES-MAC（キー、confに| MSG |パッド、IVEC = 0）、IVEC = 0）
verify_mic decrypt, compute DES MAC using confounder, compare
verify_mic復号化、交絡因子を使用してDES MACを計算し、比較します
The des-mac checksum algorithm is assigned a checksum type number of four (4).
DES-MACチェックサムアルゴリズムは、4つのチェックサムタイプ番号が割り当てられている（4）。
The DES-MAC-K checksum is computed by performing a DES CBC-mode encryption of the plaintext, with zero-valued padding bytes if necessary to bring the length to a multiple of eight octets, and by using the last block of the ciphertext as the checksum value. It is keyed with an encryption key that is also used as the initialization vector. The resulting checksum is 64 bits (eight octets) long. This checksum is tamper-proof and collision-proof. Note that this checksum type is the old method for encoding the DESMAC checksum; it is no longer recommended.
DES-MAC-Kチェックサムは、暗号文の最後のブロックなどを用いて、8つのオクテットの倍数の長さを持ってゼロ値パディングバイト必要であれば、平文のDES CBCモード暗号化を実行することによって計算されますチェックサム値。また、初期化ベクトルとして使用される暗号化キーとキーです。得られたチェックサムは64ビット（8バイト）の長さです。このチェックサムは、改ざん防止、衝突防止です。このチェックサムタイプがDESMACチェックサムをコード化するための古い方法であることに注意してください。それはもはや推奨されません。
des-mac-k
----------------------------------------------------------------
associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc
get_mic des-mac(key, msg | pad, ivec=key)
get_mic DES-MAC（キー、MSG |パッド、IVEC =キー）
verify_mic compute MAC and compare
verify_mic MACを計算し、比較します
The des-mac-k checksum algorithm is assigned a checksum type number of five (5).
DES-MAC-Kチェックサムアルゴリズムは、5つのチェックサムタイプ番号が割り当てられている（5）。
This encryption and checksum type pair is based on the Triple DES cryptosystem in Outer-CBC mode and on the HMAC-SHA1 message authentication algorithm.
この暗号化とチェックサムタイプのペアは、外側-CBCモードおよびHMAC-SHA1メッセージ認証アルゴリズムにトリプルDES暗号に基づいています。
A Triple DES key is the concatenation of three DES keys as described above for des-cbc-md5. A Triple DES key is generated from random data by creating three DES keys from separate sequences of random data.
トリプルDES鍵は、DES-CBC-MD5のために上記のように3つのDES鍵の連結です。トリプルDES鍵は、ランダムなデータの別の配列からの3つのDES鍵を作成することにより、ランダムデータから生成されます。
Encrypted data using this type must be generated as described in section 5.3. If the length of the input data is not a multiple of the block size, zero-valued octets must be used to pad the plaintext to the next eight-octet boundary. The confounder must be eight random octets (one block).
セクション5.3で説明したように、この型を使用して暗号化データが生成されなければなりません。入力データの長さがブロックサイズの倍数でない場合、ゼロ値のオクテットは、次の8オクテット境界にパッドに平文を使用しなければなりません。交絡因子は、8つのランダムオクテット（1つのブロック）でなければなりません。
The simplified profile for Triple DES, with key derivation as defined in section 5, is as follows:
次のようにトリプルDESのための簡略化プロファイルは、セクション5で定義されるように鍵導出です。
des3-cbc-hmac-sha1-kd, hmac-sha1-des3-kd
------------------------------------------------
protocol key format 24 bytes, parity in low
bit of each
key-generation seed 21 bytes length
鍵生成シード21のバイト長
des3-cbc-hmac-sha1-kd, hmac-sha1-des3-kd
------------------------------------------------
hash function SHA-1
HMAC output size 160 bits
HMACの出力サイズ160ビット
message block size 8 bytes
メッセージブロックサイズ8つのバイト
default string-to-key empty string params
デフォルトの文字列からキーへの空の文字列のparams
encryption and triple-DES encrypt and decryption functions decrypt, in outer-CBC mode (cipher block size 8 octets)
暗号化およびトリプルDES暗号化および復号化機能は、外側-CBCモードでは、復号化（暗号ブロックサイズ8つのオクテット）
key generation functions:
鍵生成機能：
random-to-key DES3random-to-key (see below)
ランダム・ツー・キーDES3ランダム・ツー・キー（下記参照）
string-to-key DES3string-to-key (see below)
文字列からキーへのDES3string・ツー・キー（下記参照）
The des3-cbc-hmac-sha1-kd encryption type is assigned the value sixteen (16). The hmac-sha1-des3-kd checksum algorithm is assigned a checksum type number of twelve (12).
DES3-CBC-HMAC-SHA1-KDの暗号化タイプは、値16（16）が割り当てられます。 HMAC-SHA1-DES3-KDチェックサムアルゴリズムは、12（12）のチェックサムタイプ番号が割り当てられます。
The 168 bits of random key data are converted to a protocol key value as follows. First, the 168 bits are divided into three groups of 56 bits, which are expanded individually into 64 bits as follows:
次のようにランダム鍵データの168ビットは、プロトコルキー値に変換されます。まず、168ビットは次のように64ビットに個別に展開されている56ビット、3つのグループに分けられます：
DES3random-to-key: 1 2 3 4 5 6 7 p 9 10 11 12 13 14 15 p 17 18 19 20 21 22 23 p 25 26 27 28 29 30 31 p 33 34 35 36 37 38 39 p 41 42 43 44 45 46 47 p 49 50 51 52 53 54 55 p 56 48 40 32 24 16 8 p
DES3random対鍵：1つの2 3 4 5 6 7 P 9 10 11 12 13 14 15 P 17 18 19 20 21 22 23、P 25 26 27 28 29 30 31 P 33 34 35 36 37 38 39 P 41 42 43 44 45 46 47 P 49 50 51 52 53 54 55 P 56 48 40 32 24 16 8 P
The "p" bits are parity bits computed over the data bits. The output of the three expansions, each corrected to avoid "weak" and "semi-weak" keys as in section 6.2, are concatenated to form the protocol key value.
「P」ビットは、データビット上で計算されたパリティビットです。各セクション6.2のような「弱い」と「半弱」キーを避けるために、補正3つの拡張の出力は、プロトコルキー値を形成するために連結されています。
The string-to-key function is used to transform UTF-8 passwords into DES3 keys. The DES3 string-to-key function relies on the "N-fold" algorithm and DK function, described in section 5.
文字列からキーへの機能は、DES3キーにUTF-8パスワードを変換するために使用されます。 DES3文字列からキーへの機能は、セクション5で説明した「N倍」アルゴリズムとDKの機能に依存しています。
The n-fold algorithm is applied to the password string concatenated with a salt value. For 3-key triple DES, the operation will involve a 168-fold of the input password string, to generate an intermediate key, from which the user's long-term key will be derived with the DK function. The DES3 string-to-key function is shown here in pseudocode:
N倍アルゴリズムは、ソルト値と連結パスワード文字列に適用されます。 3キートリプルDESの場合、操作は、ユーザの長期鍵はDK機能で導出されるから、中間鍵を生成するために、入力されたパスワード文字列の168倍を含むことになります。 DES3文字列からキーへの機能は、擬似コードにここに示されています：
DES3string-to-key(passwordString, salt, params)
if (params != emptyString)
error("invalid params");
s = passwordString + salt
tmpKey = random-to-key(168-fold(s))
key = DK (tmpKey, KerberosConstant)
Weak key checking is performed in the random-to-key and DK operations. The KerberosConstant value is the byte string {0x6b 0x65 0x72 0x62 0x65 0x72 0x6f 0x73}. These values correspond to the ASCII encoding for the string "kerberos".
弱い鍵チェックをするキー・ランダムとDK操作で行われます。 KerberosConstant値は{0x6b 0x65 0x72 0x62 0x65 0x72 0x73 0x6f}バイト列です。これらの値は、文字列「ケルベロス」のASCIIエンコーディングに対応しています。
Several Kerberos-based application protocols and preauthentication systems have been designed and deployed that perform encryption and message integrity checks in various ways. Although in some cases there may be good reason for specifying these protocols in terms of specific encryption or checksum algorithms, we anticipate that in many cases this will not be true, and more generic approaches independent of particular algorithms will be desirable. Rather than have each protocol designer reinvent schemes for protecting data, using multiple keys, etc., we have attempted to present in this section a general framework that should be sufficient not only for the Kerberos protocol itself but also for many preauthentication systems and application protocols, while trying to avoid some of the assumptions that can work their way into such protocol designs.
Kerberosベースのアプリケーションプロトコルと事前認証システムのいくつかは、さまざまな方法で暗号化し、メッセージの整合性チェックを実行することを設計し、配備されています。いくつかのケースでは、特定の暗号化またはチェックサムアルゴリズムの観点から、これらのプロトコルを指定するための十分な理由があるかもしれないが、我々は多くの場合、これは真実ではないだろうと予想し、特定のアルゴリズムに依存しない、より一般的なアプローチが望ましいであろう。各プロトコルの設計等、複数のキーを使用して、データを保護するためのスキームを改革有するのではなく、我々は、このセクションでKerberosプロトコル自体のためだけでなく、多くの事前認証システム及びアプリケーションプロトコルのためだけでなく、十分でなければならない一般的な枠組みを提示することを試みています、そのようなプロトコルの設計への道を働かせることができる仮定のいくつかを回避しようとしているとき。
Some problematic assumptions we've seen (and sometimes made) include the following: a random bitstring is always valid as a key (not true for DES keys with parity); the basic block encryption chaining mode provides no integrity checking, or can easily be separated from such checking (not true for many modes in development that do both simultaneously); a checksum for a message always results in the same value (not true if a confounder is incorporated); an initial vector is used (may not be true if a block cipher in CBC mode is not in use).
私たちが見て（そして時には製）きたいくつかの問題の仮定は次のとおりランダムビット列は常にキー（パリティ付きDESのキーには当てはまりません）として有効です。基本的なブロック暗号の連鎖モードは、チェックなしの完全性を提供しない、または簡単なチェック（両方を同時に行う開発中の多くのモードには当てはまりません）から分離することができます。 （交絡因子が組み込まれている場合は真ではない）メッセージのチェックサムが常に同じ値になります。使用される初期ベクトルは（CBCモードでブロック暗号を使用していない場合は真ではないかもしれません）。
Although such assumptions the may hold for any given set of encryption and checksum algorithms, they may not be true of the next algorithms to be defined, leaving the application protocol unable to make use of those algorithms without updates to its specification.
このような仮定はザが暗号化とチェックサムアルゴリズムの所与のセットに対して保持することができるが、彼らはその仕様への更新せずに、これらのアルゴリズムを利用することができないアプリケーションプロトコルを残して、定義されるべき次のアルゴリズムの真ではないかもしれません。
The Kerberos protocol uses only the attributes and operations described in sections 3 and 4. Preauthentication systems and application protocols making use of Kerberos are encouraged to use them as well. The specific key and string-to-key parameters should generally be treated as opaque. Although the string-to-key parameters are manipulated as an octet string, the representation for the specific key structure is implementation defined; it may not even be a single object.
Kerberosプロトコルは、同様にそれらを使用することが奨励される属性のみとセクション3および4事前認証システムおよびKerberosを利用するアプリケーションプロトコルで説明された動作を使用します。特定のキーと文字列のキーパラメータは、一般的に不透明なものとして扱われるべきです。ストリングからキーパラメータはオクテットストリングとして操作されているが、特定のキー構造の表現は、実装が定義されています。それも単一のオブジェクトではないかもしれません。
We don't recommend doing so, but some application protocols will undoubtedly continue to use the key data directly, even if only in some of the currently existing protocol specifications. An implementation intended to support general Kerberos applications may therefore need to make the key data available, as well as the attributes and operations described in sections 3 and 4 [8].
私たちは、そうすることはお勧めしませんが、いくつかのアプリケーションプロトコルは、間違いなく、現在、既存のプロトコル仕様の一部にしても場合にのみ、直接キーデータを使用し続けます。一般的なケルベロスアプリケーションをサポートすることを意図するもので実装従ってセクション3と4で説明されている属性と操作は、[8]キーデータを利用できるようにする必要があり、同様にしてもよいです。
The following encryption-type numbers are already assigned or reserved for use in Kerberos and related protocols.
次の暗号化型の番号が割り当て済みまたはKerberosおよび関連プロトコルで使用するために予約されています。
encryption type etype section or comment
-----------------------------------------------------------------
des-cbc-crc 1 6.2.3
des-cbc-md4 2 6.2.2
des-cbc-md5 3 6.2.1
[reserved] 4
des3-cbc-md5 5
[reserved] 6
des3-cbc-sha1 7
dsaWithSHA1-CmsOID 9 (pkinit)
md5WithRSAEncryption-CmsOID 10 (pkinit)
sha1WithRSAEncryption-CmsOID 11 (pkinit)
rc2CBC-EnvOID 12 (pkinit)
rsaEncryption-EnvOID 13 (pkinit from PKCS#1 v1.5)
rsaES-OAEP-ENV-OID 14 (pkinit from PKCS#1 v2.0)
des-ede3-cbc-Env-OID 15 (pkinit)
des3-cbc-sha1-kd 16 6.3
aes128-cts-hmac-sha1-96 17 [KRB5-AES]
aes256-cts-hmac-sha1-96 18 [KRB5-AES]
rc4-hmac 23 (Microsoft)
rc4-hmac-exp 24 (Microsoft)
subkey-keymaterial 65 (opaque; PacketCable)
(The "des3-cbc-sha1" assignment is a deprecated version using no key derivation. It should not be confused with des3-cbc-sha1-kd.)
（「DES3-CBC-SHA1」割り当てないキー導出を用いない推奨されたバージョンである。これは、DES3-CBC-SHA1-KDと混同すべきではありません。）
Several numbers have been reserved for use in encryption systems not defined here. Encryption-type numbers have unfortunately been overloaded on occasion in Kerberos-related protocols, so some of the reserved numbers do not and will not correspond to encryption systems fitting the profile presented here.
いくつかの数字は、ここで定義されていない暗号化システムで使用するために予約されています。暗号化タイプの番号が、残念ながらKerberos関連のプロトコルでの機会にオーバーロードされているので、予約された番号の一部にはありませんし、ここに提示したプロファイルをフィッティング暗号化システムに対応していません。
The following checksum-type numbers are assigned or reserved. As with encryption-type numbers, some overloading of checksum numbers has occurred.
以下のチェックサム型の番号が割り当てられるか、または予約されています。暗号化タイプの番号と同じように、チェックサム数字のいくつかのオーバーロードが発生しました。
Checksum type sumtype checksum section or
value size reference
---------------------------------------------------------------------
CRC32 1 4 6.1.3
rsa-md4 2 16 6.1.2
rsa-md4-des 3 24 6.2.5
des-mac 4 16 6.2.7
des-mac-k 5 8 6.2.8
rsa-md4-des-k 6 16 6.2.6
rsa-md5 7 16 6.1.1
rsa-md5-des 8 24 6.2.4
rsa-md5-des3 9 24 ??
sha1 (unkeyed) 10 20 ??
hmac-sha1-des3-kd 12 20 6.3
hmac-sha1-des3 13 20 ??
sha1 (unkeyed) 14 20 ??
hmac-sha1-96-aes128 15 20 [KRB5-AES]
hmac-sha1-96-aes256 16 20 [KRB5-AES]
[reserved] 0x8003 ? [GSS-KRB5]
Encryption and checksum-type numbers are signed 32-bit values. Zero is invalid, and negative numbers are reserved for local use. All standardized values must be positive.
暗号化とチェックサム型の数字は、32ビット値を署名されます。ゼロは無効であり、負の数は、ローカル使用のために予約されています。すべての標準化された値は正でなければなりません。
The "interface" described here is the minimal information that must be defined to make a cryptosystem useful within Kerberos in an interoperable fashion. The use of functional notation used in some places is not an attempt to define an API for cryptographic functionality within Kerberos. Actual implementations providing clean APIs will probably make additional information available, that could be derived from a specification written to the framework given here. For example, an application designer may wish to determine the largest number of bytes that can be encrypted without overflowing a certain size output buffer or conversely, the maximum number of bytes that might be obtained by decrypting a ciphertext message of a given size. (In fact, an implementation of the GSS-API Kerberos mechanism [GSS-KRB5] will require some of these.)
ここで説明する「インターフェースは、」相互運用可能な方法でのKerberos内で有用な暗号システムを作るために定義されなければならない最小限の情報です。いくつかの場所で使用される関数表記の使用は、Kerberos内の暗号化機能のためのAPIを定義しようとする試みではありません。きれいなAPIを提供する実際の実装は、おそらくここで与えられた枠組みに書き込まれた仕様から導出することができることを、追加情報が利用できるようになります。例えば、アプリケーション設計者は、特定のサイズの出力バッファまたは逆に、所与のサイズの暗号文メッセージを復号することによって得られるかもしれないバイトの最大数をオーバーフローすることなく暗号化することができるバイトの最大数を決定することを望むかもしれません。 （実際には、GSS-APIのKerberos機構[GSS-KRB5]の実装では、これらのいくつかが必要になります。）
The presence of a mechanism in this document should not be taken to indicate that it must be implemented for compliance with any specification; required mechanisms will be specified elsewhere. Indeed, some of the mechanisms described here for backward compatibility are now considered rather weak for protecting critical data.
この文書に記載されているメカニズムの存在は、それがどんな仕様に準拠して実施されなければならないことを示すために取られるべきではありません。必要なメカニズムは他の場所で指定されます。確かに、下位互換性のために、ここで説明したメカニズムのいくつかは、今、重要なデータを保護するためのかなり弱いと考えられています。
Recent years have brought so many advancements in large-scale attacks capability against DES that it is no longer considered a strong encryption mechanism. Triple-DES is generally preferred in its place, despite its poorer performance. See [ESP-DES] for a summary of some of the potential attacks and [EFF-DES] for a detailed discussion of the implementation of particular attacks. However, most Kerberos implementations still have DES as their primary interoperable encryption type.
近年では、それはもはや強力な暗号化メカニズムと考えられていることをDESに対して大規模な攻撃能力が非常に多くの進歩をもたらしていません。トリプルDESは、一般的にその貧しいパフォーマンスにもかかわらず、その場所に好まれています。特定の攻撃の実装の詳細な議論のための潜在的な攻撃のいくつかの要約と[EFF-DES]は[ESP-DES]を参照してください。しかし、ほとんどのKerberosの実装はまだ彼らの主要な相互運用性を暗号化タイプとしてDESを持っています。
DES has four 'weak' keys and twelve 'semi-weak' keys, and the use of single-DES here avoids them. However, DES also has 48 'possibly-weak' keys [Schneier96] (note that the tables in many editions of the reference contains errors) that are not avoided.
DESは、4「弱い」キーと12「半弱い」キーを持っており、ここではシングルDESの使用は、それらを避けることができます。しかし、DESも回避されないキーは、[Schneier96]（参照の多くのエディションのテーブルにエラーが含まれていることに注意）48「おそらく弱」を有します。
DES weak keys have the property that E1(E1(P)) = P (where E1 denotes encryption of a single block with key 1). DES semi-weak keys, or "dual" keys, are pairs of keys with the property that E1(P) = D2(P), and thus E2(E1(P)) = P. Because of the use of CBC mode and the leading random confounder, however, these properties are unlikely to present a security problem.
DES弱いキーは、E1（E1キー1つのブロックの暗号化を示す）（E1（P））= P特性を有します。 DES半弱いキー、または「デュアル」キー、ためCBCモードの使用E1（P）= D2（P）、及び従ってE2（E1（P））= P.性の鍵のペアであり、大手ランダム交絡因子は、しかし、これらのプロパティは、セキュリティ上の問題を提示することはほとんどありません。
Many of the choices concerning when to perform weak-key corrections relate more to compatibility with existing implementations than to any risk analysis.
弱鍵補正を実行する場合について選択肢の多くは、任意のリスク分析よりも既存の実装との互換性の詳細に関する。
Although checks are also done for the component DES keys in a triple-DES key, the nature of the weak keys make it extremely unlikely that they will weaken the triple-DES encryption. It is only slightly more likely than having the middle of the three sub-keys match one of the other two, which effectively converts the encryption to single-DES - a case we make no effort to avoid.
チェックはまた、トリプルDESのキーコンポーネントDES鍵のために行われますが、弱い鍵の性質は、彼らがトリプルDES暗号化を弱体化するということは極めてまれ作ります。我々は避けるために何の努力をしていない場合 - それはわずかに可能性が高い三つのサブキーの中央を持つより効果的にシングルDESに暗号化を変換し、他の2つのいずれかと一致しています。
The true CRC-32 checksum is not collision-proof; an attacker could use a probabilistic chosen-plaintext attack to generate a valid message even if a confounder is used [SG92]. The use of collision-proof checksums is of course recommended for environments where such attacks represent a significant threat. The "simplifications" (read: bugs) introduced when CRC-32 was implemented for Kerberos cause leading zeros effectively to be ignored, so messages differing only in leading zero bits will have the same checksum.
真のCRC-32チェックサムは、衝突防止ではありません。攻撃者は、交絡因子を用いた場合であっても有効なメッセージ[SG92]を生成するために、確率的選択平文攻撃を使用することができます。衝突防止チェックサムの使用は、このような攻撃は重大な脅威を表す環境のために推奨されるのは勿論です。 「単純化」（読み：バグを）だけ先行ゼロのビットの異なるメッセージが同じチェックサムを有することになるので、CRC-32は、効果的に無視される先行ゼロのKerberos原因のために実施されたときに導入しました。
[HMAC] and [IPSEC-HMAC] discuss weaknesses of the HMAC algorithm. Unlike [IPSEC-HMAC], the triple-DES specification here does not use the suggested truncation of the HMAC output. As pointed out in [IPSEC-HMAC], SHA-1 was not developed for use as a keyed hash function, which is a criterion of HMAC. [HMAC-TEST] contains test vectors for HMAC-SHA-1.
[HMAC]と[IPSEC-HMAC] HMACアルゴリズムの弱点を議論します。 [IPSEC-HMAC]とは異なり、ここではトリプルDES仕様は、HMAC出力の提案切り捨てを使用していません。 [IPSEC-HMAC]で指摘したように、SHA-1は、HMACの基準となる鍵付きハッシュ関数として使用するために開発されませんでした。 [HMAC-TEST] HMAC-SHA-1用のテストベクトルを含みます。
The mit_des_string_to_key function was originally constructed with the assumption that all input would be ASCII; it ignores the top bit of each input byte. Folding with XOR is also not an especially good mixing mechanism for preserving randomness.
mit_des_string_to_key機能はもともと、すべての入力はASCIIであろうと想定して構築しました。それは、各入力バイトの最上位ビットを無視します。 XORで折りたたみもランダム性を維持するために特に良好な混合メカニズムではありません。
The n-fold function used in the string-to-key operation for des3- cbc-hmac-sha1-kd was designed to cause each bit of input to contribute equally to the output. It was not designed to maximize or equally distribute randomness in the input, and conceivably randomness may be lost in cases of partially structured input. This should only be an issue for highly structured passwords, however.
des3- CBC-HMAC-SHA1-KDの文字列からキー操作で使用されるn倍関数は、入力の各ビットが出力に等しく寄与させるように設計しました。これは、最大又は等しく入力にランダムに分配するように設計されていない、と考えられるランダム性は、部分的に構造化された入力の場合には失われる可能性があります。これはしかし、高度に構造化されたパスワードの問題でなければなりません。
[RFC1851] discusses the relative strength of triple-DES encryption. The relatively slow speed of triple-DES encryption may also be an issue for some applications.
[RFC1851]はトリプルDES暗号化の相対強度を論じています。トリプルDES暗号化の比較的遅い速度もいくつかのアプリケーションのために問題になることがあります。
[Bellovin91] suggests that analyses of encryption schemes include a model of an attacker capable of submitting known plaintexts to be encrypted with an unknown key, as well as be able to perform many types of operations on known protocol messages. Recent experiences with the chosen-plaintext attacks on Kerberos version 4 bear out the value of this suggestion.
【Bellovin91】暗号化方式の分析は、未知の鍵で暗号化されることが知られている平文を送信することが可能な攻撃者のモデルを含み、ならびに既知のプロトコルメッセージに対する操作の多くの種類を実行することができることを示唆しています。 Kerberosバージョン4の選択平文攻撃との最近の経験は、この提案の価値を負うものとします。
The use of unkeyed encrypted checksums, such as those used in the single-DES cryptosystems specified in [Kerb1510], allows for cut-and-paste attacks, especially if a confounder is not used. In addition, unkeyed encrypted checksums are vulnerable to chosen-plaintext attacks: An attacker with access to an encryption oracle can easily encrypt the required unkeyed checksum along with the chosen plaintext. [Bellovin99] These weaknesses, combined with a common implementation design choice described below, allow for a cross-protocol attack from version 4 to version 5.
このような【Kerb1510]で指定されたシングルDESの暗号システムで使用されるようなキーなし暗号化されたチェックサムの使用は、交絡因子が使用されていない場合は特に、カットアンドペースト攻撃を可能にします。また、キーなし暗号化されたチェックサムは、選択平文攻撃に対して脆弱である：暗号化オラクルへのアクセス権を持つ攻撃者が簡単に選択平文と一緒に必要なキーなしのチェックサムを暗号化することができます。 【Bellovin99】一般的な実装設計上の選択と組み合わさこれらの弱点は、以下に説明する、バージョン5にバージョン4からのクロスプロトコル攻撃を可能にします。
The use of a random confounder is an important means to prevent an attacker from making effective use of protocol exchanges as an encryption oracle. In Kerberos version 4, the encryption of constant plaintext to constant ciphertext makes an effective encryption oracle for an attacker. The use of random confounders in [Kerb1510] frustrates this sort of chosen-plaintext attack.
ランダム交絡因子の使用は、暗号化Oracleなどのプロトコル交換を有効に活用し、攻撃者を防ぐための重要な手段です。 Kerberosバージョン4では、一定の暗号文に対して一定の平文の暗号化は、攻撃者のための効果的な暗号化オラクルになります。 [Kerb1510]内のランダムな交絡因子の使用は、選択平文攻撃のこの種を失望させます。
Using the same key for multiple purposes can enable or increase the scope of chosen-plaintext attacks. Some software that implements both versions 4 and 5 of the Kerberos protocol uses the same keys for both versions. This enables the encryption oracle of version 4 to be used to attack version 5. Vulnerabilities to attacks such as this cross-protocol attack make it unwise to use a key for multiple purposes.
複数の目的のために同じキーを使用すると、選択平文攻撃の範囲を有効にするか、または増やすことができます。 Kerberosプロトコルのバージョン4と5の両方を実装するいくつかのソフトウェアは、両方のバージョンのために同じキーを使用します。これは、このクロスプロトコル攻撃などの攻撃に5.脆弱性は、それが賢明複数の目的のためにキーを使用するようにするバージョンを攻撃するために使用するバージョン4の暗号化オラクルを可能にします。
This document, like the Kerberos protocol, does not address limiting the amount of data a key may be used with to a quantity based on the robustness of the algorithm or size of the key. It is assumed that any defined algorithms and key sizes will be strong enough to support very large amounts of data, or they will be deprecated once significant attacks are known.
この文書では、Kerberosプロトコルと同様に、キーは、キーのアルゴリズム又はサイズの堅牢性に基づく量にして使用することができるデータの量を制限対処していません。任意の定義されたアルゴリズムとキーサイズは非常に大量のデータをサポートするのに十分な強されることが前提とされる、または彼らはかつて重要な攻撃が知られている廃止されます。
This document also places no bounds on the amount of data that can be handled in various operations. To avoid denial of service attacks, implementations will probably seek to restrict message sizes at some higher level.
この文書はまた、種々の操作で扱うことができるデータの量には限界を配置しません。サービス拒否（DoS）攻撃を避けるために、実装は、おそらくいくつかのより高いレベルでのメッセージのサイズを制限していきます。
Two registries for numeric values have been created: Kerberos Encryption Type Numbers and Kerberos Checksum Type Numbers. These are signed values ranging from -2147483648 to 2147483647. Positive values should be assigned only for algorithms specified in accordance with this specification for use with Kerberos or related protocols. Negative values are for private use; local and experimental algorithms should use these values. Zero is reserved and may not be assigned.
数値の二つのレジストリが作成されています：Kerberosの暗号化タイプ番号とKerberosチェックサムタイプ番号。 -2147483648から2147483647正の値の範囲のこれらの署名されている値は、Kerberosまたは関連するプロトコルで使用するための本明細書に応じて指定されたアルゴリズムに対してのみ割り当てられるべきです。負の値は、私的使用のためのものです。ローカルおよび実験的なアルゴリズムは、これらの値を使用する必要があります。ゼロが予約されており、譲渡することはできません。
Positive encryption- and checksum-type numbers may be assigned following either of two policies described in [BCP26].
正encryption-チェックサム型の番号は、[BCP26]に記載の2つのポリシーのいずれかの次の割り当てられてもよいです。
Standards-track specifications may be assigned values under the Standards Action policy.
標準トラック仕様が標準化アクションポリシーの下で値を割り当てることもできます。
Specifications in non-standards track RFCs may be assigned values after Expert Review. A non-IETF specification may be assigned values by publishing an Informational or standards-track RFC referencing the external specification; that specification must be public and published in some permanent record, much like the IETF RFCs. It is highly desirable, though not required, that the full specification be published as an IETF RFC.
非標準化トラックのRFCでの仕様は、専門家のレビューの後に値を割り当てることもできます。非IETF仕様では、外部仕様を参照する情報または標準トラックRFCを発行することによって値を割り当てることができます。その仕様は、多くのIETFのRFCのように、公共およびいくつかの永続的な記録で公開されている必要があります。完全な仕様はIETF RFCとして公開されていることが、必要ではないが、非常に望ましいです。
Smaller encryption type values should be used for IETF standards-track mechanisms, and much higher values (16777216 and above) for other mechanisms. (Rationale: In the Kerberos ASN.1 encoding, smaller numbers encode to smaller octet sequences, so this favors standards-track mechanisms with slightly smaller messages.) Aside from that guideline, IANA may choose numbers as it sees fit.
小さな暗号化タイプの値は、IETF標準トラック機構、および他の機構のためにはるかに高い値（16777216以上）のために使用されるべきです。 （理由：ケルベロスASN.1符号化では、より小さな数字が小さいオクテット配列をコードするので、これはわずかに小さいメッセージで標準トラック機構を好む）別にそのガイドラインから、それが適当と考えるように、IANAは、数字を選択してもよいです。
Internet-Draft specifications should not include values for encryption- and checksum-type numbers. Instead, they should indicate that values would be assigned by IANA when the document is approved as an RFC. For development and interoperability testing, values in the private-use range (negative values) may be used but should not be included in the draft specification.
インターネットドラフト仕様はencryption-とチェックサム型の数値の値を含めるべきではありません。その代わりに、彼らは文書がRFCとして承認されたときの値はIANAによって割り当てられることを示す必要があります。開発および相互運用性試験のために、私的利用の範囲内の値（負の値）を使用することができるが、ドラフト仕様に含まれるべきではありません。
Each registered value should have an associated unique reference name. The lists given in section 8 were used to create the initial registry; they include reservations for specifications in progress in parallel with this document, and certain other values believed to already be in use.
登録された各値は、関連付けられた一意の参照名を持つ必要があります。セクション8で与えられたリストは、最初のレジストリを作成するために使用されました。彼らは、この文書と並行して進行中の仕様の予約、およびすでに使用中であると考えられ、特定の他の値が含まれます。
This document is an extension of the encryption specification included in [Kerb1510] by B. Clifford Neuman and John Kohl, and much of the text of the background, concepts, and DES specifications is drawn directly from that document.
この文書では、B.クリフォード・ノイマンとジョン・コールズで[Kerb1510]に含まれる暗号仕様を拡張したもので、背景のテキスト、概念、およびDESの仕様の多くは、その文書から直接描かれています。
The abstract framework presented in this document was put together by Jeff Altman, Sam Hartman, Jeff Hutzelman, Cliff Neuman, Ken Raeburn, and Tom Yu, and the details were refined several times based on comments from John Brezak and others.
この文書の抽象的枠組みはジェフ・アルトマン、サム・ハートマン、ジェフHutzelman、クリフニューマン、ケン・レイバーン、そしてトム・ゆうによって一緒に入れ、詳細はジョンBrezakと他人からのコメントに基づいて、数回を精密化しました。
Marc Horowitz wrote the original specification of triple-DES and key derivation in a pair of Internet-Drafts (under the names draft-horowitz-key-derivation and draft-horowitz-kerb-key-derivation) that were later folded into a draft revision of [Kerb1510], from which this document was later split off.
マーク・ホロウィッツは、後に改正案に折り畳まれたインターネットドラフト（草案の名称で、ホロヴィッツ - キー派生とドラフトホロヴィッツ・縁石・キー導出）のペアでトリプルDESの本来の仕様と鍵の導出を書きました[Kerb1510]、そこからこの文書は、後でオフに分割されました。
Tom Yu provided the text describing the modifications to the standard CRC algorithm as Kerberos implementations actually use it, and some of the text in the Security Considerations section.
トムゆうはKerberos実装は、実際にそれを使用するなどの標準的なCRCアルゴリズムに変更を説明するテキスト、およびセキュリティに関する注意事項セクション内のテキストの一部を提供します。
Miroslav Jurisic provided information for one of the UTF-8 test cases for the string-to-key functions.
ミロスラフJurisicはストリングからキー機能用のUTF-8のテストケースのための情報を提供しました。
Marcus Watts noticed some errors in earlier versions and pointed out that the simplified profile could easily be modified to support cipher text stealing modes.
マーカス・ワッツは、以前のバージョンでは多少の誤差が気づき、単純化されたプロファイルを簡単に暗号文スチールモードをサポートするように変更することができることを指摘しました。
Simon Josefsson contributed some clarifications to the DES "CBC checksum" and string-to-key and weak key descriptions, and some test vectors.
サイモンJosefsson氏は、DES、「CBCチェックサム」と文字列のキーと弱いキー説明、およびいくつかのテストベクトルにいくつかの明確化に貢献しました。
Simon Josefsson, Louis LeVay, and others also caught some errors in earlier versions of this document.
サイモンJosefsson氏、ルイス・LeVay、その他にも、この文書の以前のバージョンではいくつかのエラーをキャッチ。
A. Test Vectors
A.テストベクトル
This section provides test vectors for various functions defined or described in this document. For convenience, most inputs are ASCII strings, though some UTF-8 samples are provided for string-to-key functions. Keys and other binary data are specified as hexadecimal strings.
このセクションでは、この文書で定義され又は説明される様々な機能のためのテストベクトルを提供します。いくつかのUTF-8のサンプルは、文字列からキーへの機能のために提供されているものの便宜上、ほとんどの入力は、ASCII文字列です。キーおよび他のバイナリデータは16進文字列として指定されています。
A.1. n-fold
A.1。 n重
The n-fold function is defined in section 5.1. As noted there, the sample vector in the original paper defining the algorithm appears to be incorrect. Here are some test cases provided by Marc Horowitz and Simon Josefsson:
n重の機能は、セクション5.1で定義されています。そこに述べたように、アルゴリズムを定義し、元の紙のサンプルベクトルが誤っていることが表示されます。ここではマーク・ホロウィッツとサイモンJosefsson氏が提供するいくつかのテストケースは以下のとおりです。
64-fold("012345") = 64-fold(303132333435) = be072631276b1955
64倍（ "012345"）= 64倍（303132333435）= be072631276b1955
56-fold("password") = 56-fold(70617373776f7264) = 78a07b6caf85fa
56倍（ "パスワード"）= 56倍（70617373776f7264）= 78a07b6caf85fa
64-fold("Rough Consensus, and Running Code") = 64-fold(526f75676820436f6e73656e7375732c20616e642052756e 6e696e6720436f6465) = bb6ed30870b7f0e0
64倍（ "ラフコンセンサス、実行コード"）= 64倍（526f75676820436f6e73656e7375732c20616e642052756e 6e696e6720436f6465）= bb6ed30870b7f0e0
168-fold("password") = 168-fold(70617373776f7264) = 59e4a8ca7c0385c3c37b3f6d2000247cb6e6bd5b3e
168倍（ "パスワード"）= 168倍（70617373776f7264）= 59e4a8ca7c0385c3c37b3f6d2000247cb6e6bd5b3e
192-fold("MASSACHVSETTS INSTITVTE OF TECHNOLOGY") 192-fold(4d41535341434856534554545320494e5354495456544520 4f4620544543484e4f4c4f4759) = db3b0d8f0b061e603282b308a50841229ad798fab9540c1b
192倍（ "マサチューセッツ工科大学"）192倍（4d41535341434856534554545320494e5354495456544520 4f4620544543484e4f4c4f4759）= db3b0d8f0b061e603282b308a50841229ad798fab9540c1b
168-fold("Q") = 168-fold(51) = 518a54a2 15a8452a 518a54a2 15a8452a 518a54a2 15
168倍（ "Q"）= 168倍（51）= 518a54a2 15a8452a 518a54a2 15a8452a 518a54a2 15
168-fold("ba") = 168-fold(6261) = fb25d531 ae897449 9f52fd92 ea9857c4 ba24cf29 7e
168倍（ "BA"）= 168倍（6261）= fb25d531 ae897449 9f52fd92 ea9857c4 ba24cf29 7E
Here are some additional values corresponding to folded values of the string "kerberos"; the 64-bit form is used in the des3 string-to-key (section 6.3.1).
ここでは、文字列「ケルベロス」の折りたたまれた値に対応するいくつかの追加の値です。 64ビット形式は、DES3ストリングからキー（セクション6.3.1）に使用されます。
64-fold("kerberos") = 6b657262 65726f73 128-fold("kerberos") = 6b657262 65726f73 7b9b5b2b 93132b93 168-fold("kerberos") = 8372c236 344e5f15 50cd0747 e15d62ca 7a5a3bce a4 256-fold("kerberos") = 6b657262 65726f73 7b9b5b2b 93132b93 5c9bdcda d95c9899 c4cae4de e6d6cae4
64倍（ "ケルベロス"）= 6b657262 65726f73 128倍（ "ケルベロス"）= 6b657262 65726f73 7b9b5b2b 93132b93 168倍（ "ケルベロス"）= 8372c236 344e5f15 50cd0747 e15d62ca 7a5a3bce A4 256倍（ "ケルベロス"）= 6b657262 65726f73 7b9b5b2b 93132b93 5c9bdcda d95c9899 c4cae4de e6d6cae4
Note that the initial octets exactly match the input string when the output length is a multiple of the input length.
出力長は入力長の倍数であるとき、最初のオクテットは正確に入力文字列と一致していることに注意してください。
A.2. mit_des_string_to_key
A.2。 mit_des_string_to_key
The function mit_des_string_to_key is defined in section 6.2. We present here several test values, with some of the intermediate results. The fourth test demonstrates the use of UTF-8 with three characters. The last two tests are specifically constructed so as to trigger the weak-key fixups for the intermediate key produced by fan-folding; we have no test cases that cause such fixups for the final key.
機能mit_des_string_to_keyはセクション6.2で定義されています。当社は、中間結果のいくつかと、ここでいくつかのテスト値を提示します。第四の試験は、3つの文字でUTF-8を使用することを示しています。最後の二つの試験は、特にファンフォールディングによって生成された中間鍵の弱鍵フィックスアップをトリガするように構成されています。私たちは、最終的なキーのため、このようなフィックスアップの原因となるようなテストケースを持っていません。
UTF-8 encodings used in test vector: eszett U+00DF C3 9F s-caron U+0161 C5 A1 c-acute U+0107 C4 87 g-clef U+1011E F0 9D 84 9E
UTF-8のテストベクタで使用エンコーディング：エスツェットU + 00DF C3 9F S-カロンU + 0161 C5 A1 C-急性U + 0107 C4 87グラム、音部記号U + 1011E F0 9D 84 9E
Test vector:
テストベクトル：
salt: "ATHENA.MIT.EDUraeburn" 415448454e412e4d49542e4544557261656275726e password: "password" 70617373776f7264 fan-fold result: c01e38688ac86c2e intermediate key: c11f38688ac86d2f DES key: cbc22fae235298e3
塩： "ATHENA.MIT.EDUraeburn" 415448454e412e4d49542e4544557261656275726eパスワード： "パスワード" 70617373776f7264ファン倍の結果：c01e38688ac86c2e中間鍵：DESキーc11f38688ac86d2f：cbc22fae235298e3
salt: "WHITEHOUSE.GOVdanny" 5748495445484f5553452e474f5664616e6e79 password: "potatoe" 706f7461746f65 fan-fold result: a028944ee63c0416 intermediate key: a129944fe63d0416 DES key: df3d32a74fd92a01
塩： "WHITEHOUSE.GOVdanny" 5748495445484f5553452e474f5664616e6e79パスワード： "ジャガイモ" 706f7461746f65ファン倍結果：a028944ee63c0416中間鍵：DESキーa129944fe63d0416：df3d32a74fd92a01
salt: "EXAMPLE.COMpianist" 4558414D504C452E434F4D7069616E697374 password: g-clef (U+1011E) f09d849e fan-fold result: 3c4a262c18fab090 intermediate key: 3d4a262c19fbb091
塩： "EXAMPLE.COMpianist" 4558414D504C452E434F4D7069616E697374パスワード：G-音部記号（U + 1011E）f09d849eファン倍結果：3c4a262c18fab090中間鍵：3d4a262c19fbb091
DES key: 4ffb26bab0cd9413
DESキー：4ffb26bab0cd9413
salt: "ATHENA.MIT.EDUJuri" + s-caron(U+0161) + "i" + c-acute(U+0107) 415448454e412e4d49542e4544554a757269c5a169c487 password: eszett(U+00DF) c39f fan-fold result:b8f6c40e305afc9e intermediate key: b9f7c40e315bfd9e DES key: 62c81a5232b5e69d
塩： "ATHENA.MIT.EDUJuri" + S-キャロン（U + 0161）+ "I" + C-急性（U + 0107）415448454e412e4d49542e4544554a757269c5a169c487パスワード：b8f6c40e305afc9e中間鍵：エスツェット（U + 00DF）ファン倍結果c39f 62c81a5232b5e69d：DESキーb9f7c40e315bfd9e
salt: "AAAAAAAA" 4141414141414141 password: "11119999" 3131313139393939 fan-fold result: e0e0e0e0f0f0f0f0 intermediate key: e0e0e0e0f1f1f101 DES key: 984054d0f1a73e31
塩： "AAAAAAAA" 4141414141414141パスワード： "11119999" 3131313139393939ファン倍の結果：e0e0e0e0f0f0f0f0中間鍵：e0e0e0e0f1f1f101 DESキー：984054d0f1a73e31
salt: "FFFFAAAA" 4646464641414141 password: "NNNN6666" 4e4e4e4e36363636 fan-fold result: 1e1e1e1e0e0e0e0e intermediate key: 1f1f1f1f0e0e0efe DES key: c4bf6b25adf7a4f8
塩： "FFFFAAAA" 4646464641414141パスワード： "NNNN6666" 4e4e4e4e36363636ファン倍の結果：DESキー1f1f1f1f0e0e0efe：c4bf6b25adf7a4f8中間鍵1e1e1e1e0e0e0e0e
This trace provided by Simon Josefsson shows the intermediate processing stages of one of the test inputs:
サイモンJosefsson氏によって提供されるこのトレースは、テスト入力の一方の中間処理段階を示しています。
string_to_key (des-cbc-md5, string, salt)
;; string:
;; `password' (length 8 bytes)
;; 70 61 73 73 77 6f 72 64
;; salt:
;; `ATHENA.MIT.EDUraeburn' (length 21 bytes)
;; 41 54 48 45 4e 41 2e 4d 49 54 2e 45 44 55 72 61
;; 65 62 75 72 6e
des_string_to_key (string, salt)
;; String:
;; `password' (length 8 bytes)
;; 70 61 73 73 77 6f 72 64
;; Salt:
;; `ATHENA.MIT.EDUraeburn' (length 21 bytes)
;; 41 54 48 45 4e 41 2e 4d 49 54 2e 45 44 55 72 61
;; 65 62 75 72 6e
odd = 1;
s = string | salt;
tempstring = 0; /* 56-bit string */
pad(s); /* with nulls to 8 byte boundary */
;; s = pad(string|salt):
;; `passwordATHENA.MIT.EDUraeburn\x00\x00\x00'
;; (length 32 bytes)
;; 70 61 73 73 77 6f 72 64 41 54 48 45 4e 41 2e 4d
;; 49 54 2e 45 44 55 72 61 65 62 75 72 6e 00 00 00
for (8byteblock in s) {
;; loop iteration 0
;; 8byteblock:
;; `password' (length 8 bytes)
;; 70 61 73 73 77 6f 72 64
;; 01110000 01100001 01110011 01110011 01110111 01101111
;; 01110010 01100100
56bitstring = removeMSBits(8byteblock);
;; 56bitstring:
;; 1110000 1100001 1110011 1110011 1110111 1101111
;; 1110010 1100100
if (odd == 0) reverse(56bitstring); ;; odd=1
odd = ! odd
tempstring = tempstring XOR 56bitstring;
;; tempstring
;; 1110000 1100001 1110011 1110011 1110111 1101111
;; 1110010 1100100
for (8byteblock in s) {
;; loop iteration 1
;; 8byteblock:
;; `ATHENA.M' (length 8 bytes)
;; 41 54 48 45 4e 41 2e 4d
;; 01000001 01010100 01001000 01000101 01001110 01000001
;; 00101110 01001101
56bitstring = removeMSBits(8byteblock);
;; 56bitstring:
;; 1000001 1010100 1001000 1000101 1001110 1000001
;; 0101110 1001101
if (odd == 0) reverse(56bitstring); ;; odd=0
reverse(56bitstring)
;; 56bitstring after reverse
;; 1011001 0111010 1000001 0111001 1010001 0001001
;; 0010101 1000001
odd = ! odd
tempstring = tempstring XOR 56bitstring;
;; tempstring
;; 0101001 1011011 0110010 1001010 0100110 1100110
;; 1100111 0100101
for (8byteblock in s) { ;; loop iteration 2 ;; 8byteblock: ;; `IT.EDUra' (length 8 bytes) ;; 49 54 2e 45 44 55 72 61 ;; 01001001 01010100 00101110 01000101 01000100 01010101
{（Sにおける8byteblock）のために;;ループの反復2 ;; 8byteblock：;; `IT.EDUra」（長さ8バイト）;; 49 54 2E 45 44 55 72 61 ;; 01001001 01010100 00101110 01000101 01000100 01010101
;; 01110010 01100001
56bitstring = removeMSBits(8byteblock);
;; 56bitstring:
;; 1001001 1010100 0101110 1000101 1000100 1010101
;; 1110010 1100001
if (odd == 0) reverse(56bitstring); ;; odd=1
odd = ! odd
tempstring = tempstring XOR 56bitstring;
;; tempstring
;; 1100000 0001111 0011100 0001111 1100010 0110011
;; 0010101 1000100
for (8byteblock in s) {
;; loop iteration 3
;; 8byteblock:
;; `eburn\x00\x00\x00' (length 8 bytes)
;; 65 62 75 72 6e 00 00 00
;; 01100101 01100010 01110101 01110010 01101110 00000000
;; 00000000 00000000
56bitstring = removeMSBits(8byteblock);
;; 56bitstring:
;; 1100101 1100010 1110101 1110010 1101110 0000000
;; 0000000 0000000
if (odd == 0) reverse(56bitstring); ;; odd=0
reverse(56bitstring)
;; 56bitstring after reverse
;; 0000000 0000000 0000000 0111011 0100111 1010111
;; 0100011 1010011
odd = ! odd
tempstring = tempstring XOR 56bitstring;
;; tempstring
;; 1100000 0001111 0011100 0110100 1000101 1100100
;; 0110110 0010111
for (8byteblock in s) { } ;; for loop terminated
（S内8byteblock）{}の;; forループを終了
tempkey = key_correction(add_parity_bits(tempstring)); ;; tempkey ;; `\xc1\x1f8h\x8a\xc8m\x2f' (length 8 bytes) ;; c1 1f 38 68 8a c8 6d 2f ;; 11000001 00011111 00111000 01101000 10001010 11001000 ;; 01101101 00101111
tempkey = key_correction（add_parity_bits（tempstring））。 ;; tempkey ;; `\ XC1 \ x1f8h \ x8a \ xc8m \ x2f」（長さ8バイト）;; 38 68 8aはC8 6dとの2F 1F C1 ;; 11000001 00011111 00111000 01101000 10001010 11001000 ;; 01101101 00101111
key = key_correction(DES-CBC-check(s,tempkey)); ;; key ;; `\xcb\xc2\x2f\xae\x23R\x98\xe3' (length 8 bytes)
キー= key_correction（DES-CBC-チェック（S、tempkey））。 ;;キー;; `\ XCB \ XC2 \ x2f \ XAE \ x23R \ x98 \ XE3' （長さ8バイト）
;; cb c2 2f ae 23 52 98 e3
;; 11001011 11000010 00101111 10101110 00100011 01010010
;; 10011000 11100011
;; string_to_key key: ;; `\xcb\xc2\x2f\xae\x23R\x98\xe3' (length 8 bytes) ;; cb c2 2f ae 23 52 98 e3
;; string_to_keyキー：;; `\ XCB \ XC2 \ x2f \ XAE \ x23R \ x98 \ XE3' （長さ8バイト）;; 2F AE 23 52 98 E3 C2 CB
A.3. DES3 DR and DK
A.3。 DES3 DRとDK
These tests show the derived-random and derived-key values for the des3-hmac-sha1-kd encryption scheme, using the DR and DK functions defined in section 6.3.1. The input keys were randomly generated; the usage values are from this specification.
これらの試験は、セクション6.3.1で定義されたDRとDK関数を使用して、ランダム由来および派生鍵DES3-HMAC-SHA1-KD暗号化方式の値を示しています。入力キーは、ランダムに生成されました。使用量の値は、この仕様書からです。
key: dce06b1f64c857a11c3db57c51899b2cc1791008ce973b92 usage: 0000000155 DR: 935079d14490a75c3093c4a6e8c3b049c71e6ee705 DK: 925179d04591a79b5d3192c4a7e9c289b049c71f6ee604cd
キー：dce06b1f64c857a11c3db57c51899b2cc1791008ce973b92用法：0000000155 DR：935079d14490a75c3093c4a6e8c3b049c71e6ee705 DK：925179d04591a79b5d3192c4a7e9c289b049c71f6ee604cd
key: 5e13d31c70ef765746578531cb51c15bf11ca82c97cee9f2 usage: 00000001aa DR: 9f58e5a047d894101c469845d67ae3c5249ed812f2 DK: 9e58e5a146d9942a101c469845d67a20e3c4259ed913f207
キー：5e13d31c70ef765746578531cb51c15bf11ca82c97cee9f2用法：00000001aa DR：9f58e5a047d894101c469845d67ae3c5249ed812f2 DK：9e58e5a146d9942a101c469845d67a20e3c4259ed913f207
key: 98e6fd8a04a4b6859b75a176540b9752bad3ecd610a252bc usage: 0000000155 DR: 12fff90c773f956d13fc2ca0d0840349dbd39908eb DK: 13fef80d763e94ec6d13fd2ca1d085070249dad39808eabf
キー：98e6fd8a04a4b6859b75a176540b9752bad3ecd610a252bc用法：0000000155 DR：12fff90c773f956d13fc2ca0d0840349dbd39908eb DK：13fef80d763e94ec6d13fd2ca1d085070249dad39808eabf
key: 622aec25a2fe2cad7094680b7c64940280084c1a7cec92b5 usage: 00000001aa DR: f8debf05b097e7dc0603686aca35d91fd9a5516a70 DK: f8dfbf04b097e6d9dc0702686bcb3489d91fd9a4516b703e
キー：622aec25a2fe2cad7094680b7c64940280084c1a7cec92b5用法：00000001aa DR：f8debf05b097e7dc0603686aca35d91fd9a5516a70 DK：f8dfbf04b097e6d9dc0702686bcb3489d91fd9a4516b703e
key: d3f8298ccb166438dcb9b93ee5a7629286a491f838f802fb usage: 6b65726265726f73 ("kerberos") DR: 2270db565d2a3d64cfbfdc5305d4f778a6de42d9da DK: 2370da575d2a3da864cebfdc5204d56df779a7df43d9da43
キー：d3f8298ccb166438dcb9b93ee5a7629286a491f838f802fb用法：6b65726265726f73（ "ケルベロス"）DR：2270db565d2a3d64cfbfdc5305d4f778a6de42d9da DK：2370da575d2a3da864cebfdc5204d56df779a7df43d9da43
key: c1081649ada74362e6a1459d01dfd30d67c2234c940704da usage: 0000000155 DR: 348056ec98fcc517171d2b4d7a9493af482d999175 DK: 348057ec98fdc48016161c2a4c7a943e92ae492c989175f7
キー：c1081649ada74362e6a1459d01dfd30d67c2234c940704da用法：0000000155 DR：348056ec98fcc517171d2b4d7a9493af482d999175 DK：348057ec98fdc48016161c2a4c7a943e92ae492c989175f7
key: 5d154af238f46713155719d55e2f1f790dd661f279a7917c usage: 00000001aa DR: a8818bc367dadacbe9a6c84627fb60c294b01215e5
キー：5d154af238f46713155719d55e2f1f790dd661f279a7917c用法：00000001aa DR：a8818bc367dadacbe9a6c84627fb60c294b01215e5
DK: a8808ac267dada3dcbe9a7c84626fbc761c294b01315e5c1
EU：a8808ac267dada3dcbe9a7c84626fbc761c294b01315e5c1
key: 798562e049852f57dc8c343ba17f2ca1d97394efc8adc443 usage: 0000000155 DR: c813f88b3be2b2f75424ce9175fbc8483b88c8713a DK: c813f88a3be3b334f75425ce9175fbe3c8493b89c8703b49
キー：798562e049852f57dc8c343ba17f2ca1d97394efc8adc443用法：0000000155 DR：c813f88b3be2b2f75424ce9175fbc8483b88c8713a DK：c813f88a3be3b334f75425ce9175fbe3c8493b89c8703b49
key: 26dce334b545292f2feab9a8701a89a4b99eb9942cecd016 usage: 00000001aa DR: f58efc6f83f93e55e695fd252cf8fe59f7d5ba37ec DK: f48ffd6e83f83e7354e694fd252cf83bfe58f7d5ba37ec5d
キー：26dce334b545292f2feab9a8701a89a4b99eb9942cecd016用法：00000001aa DR：f58efc6f83f93e55e695fd252cf8fe59f7d5ba37ec DK：f48ffd6e83f83e7354e694fd252cf83bfe58f7d5ba37ec5d
A.4. DES3string_to_key
A.4。 DES3string_to_key
These are the keys generated for some of the above input strings for triple-DES with key derivation as defined in section 6.3.1.
これらは、セクション6.3.1で定義されるように鍵導出とトリプルDESのための上記の入力文字列の一部について生成された鍵です。
salt: "ATHENA.MIT.EDUraeburn" passwd: "password" key: 850bb51358548cd05e86768c313e3bfef7511937dcf72c3e
塩： "ATHENA.MIT.EDUraeburn" passwdの： "パスワード" キー：850bb51358548cd05e86768c313e3bfef7511937dcf72c3e
salt: "WHITEHOUSE.GOVdanny" passwd: "potatoe" key: dfcd233dd0a43204ea6dc437fb15e061b02979c1f74f377a
塩： "WHITEHOUSE.GOVのダニー" passwdの： "ポテト" キー：dfcd233dd0a43204ea6dc437fb15e061b02979c1f74f377a
salt: "EXAMPLE.COMbuckaroo" passwd: "penny" key: 6d2fcdf2d6fbbc3ddcadb5da5710a23489b0d3b69d5d9d4a
塩： "EXAMPLE.COMbuckaroo" passwdの： "ペニー" キー：6d2fcdf2d6fbbc3ddcadb5da5710a23489b0d3b69d5d9d4a
salt: "ATHENA.MIT.EDUJuri" + s-caron(U+0161) + "i" + c-acute(U+0107) passwd: eszett(U+00DF) key: 16d5a40e1ce3bacb61b9dce00470324c831973a7b952feb0
塩： "ATHENA.MIT.EDUJuri" + S-カロン（U + 0161）+ "I" + C-急性（U + 0107）はpasswd：エスツェット（U + 00DF）キー：16d5a40e1ce3bacb61b9dce00470324c831973a7b952feb0を
salt: "EXAMPLE.COMpianist" passwd: g-clef(U+1011E) key: 85763726585dbc1cce6ec43e1f751f07f1c4cbb098f40b19
塩： "EXAMPLE.COMpianist" のpasswd：G-音部記号（U + 1011E）キー：85763726585dbc1cce6ec43e1f751f07f1c4cbb098f40b19
A.5. Modified CRC-32
A.5。変更されたCRC-32
Below are modified-CRC32 values for various ASCII and octet strings. Only the printable ASCII characters are checksummed, without a C-style trailing zero-valued octet. The 32-bit modified CRC and the sequence of output bytes as used in Kerberos are shown. (The octet values are separated here to emphasize that they are octet values and not 32-bit numbers, which will be the most convenient form for manipulation in some implementations. The bit and byte order used internally for such a number is irrelevant; the octet sequence generated is what is important.)
以下は、様々なASCIIとオクテット文字列に変更され、CRC32の値です。印刷可能なASCII文字だけがCスタイルの末尾のゼロ値のオクテットせずに、チェックサムされています。 32ビットCRCを修飾およびKerberosで使用されるように、出力バイトのシーケンスが示されています。 （オクテット値は、それらがオクテットの値ではなく、いくつかの実装形態では操作のための最も便利な形態であろう32ビット数、であることを強調するために、ここで分離されているような数のために内部的に使用されるビットおよびバイト順序は無関係である。オクテット生成されたシーケンスは重要なものです。）
mod-crc-32("foo") = 33 bc 32 73 mod-crc-32("test0123456789") = d6 88 3e b8 mod-crc-32("MASSACHVSETTS INSTITVTE OF TECHNOLOGY") = f7 80 41 e3 mod-crc-32(8000) = 4b 98 83 3b mod-crc-32(0008) = 32 88 db 0e mod-crc-32(0080) = 20 83 b8 ed mod-crc-32(80) = 20 83 b8 ed mod-crc-32(80000000) = 3b b6 59 ed mod-crc-32(00000001) = 96 30 07 77
MOD-CRC-32（ "FOO"）は33 BC 32 73 MOD-CRC-32（ "test0123456789を"）=（ "技術のMASSACHVSETTS INSTITVTE"）MOD-CRC-32 D6 88 3E B8を= = F7 80 41 E3 mod- CRC-32（8000）= 4B 98 83 3B MOD-CRC-32（0008）= 32 88デシベル0EのMOD-CRC-32（0080）= 20 83 B8のED MOD-CRC-32（80）= 20 83 B8 ED MOD-CRC-32（80000000）= 3B B6 59 ED MOD-CRC-32（00000001）= 96 30 07 77
B. Significant Changes from
B.著しい変動があったから
The encryption and checksum mechanism profiles are new. The old specification defined a few operations for various mechanisms but didn't outline what abstract properties should be required of new mechanisms, or how to ensure that a mechanism specification is complete enough for interoperability between implementations. The new profiles differ from the old specification in a few ways:
暗号化とチェックサムメカニズムプロファイルが新しいです。古い仕様では、さまざまなメカニズムのためのいくつかの操作を定義しますが、新しいメカニズムを必要としなければならない抽象何性質について概説していない、またはメカニズムの仕様が実装の間の相互運用性のために十分に完了したことを確認する方法。新しいプロファイルは、いくつかの方法で古い仕様とは異なります。
Some message definitions in [Kerb1510] could be read as permitting the initial vector to be specified by the application; the text was too vague. It is explicitly not permitted in this specification. Some encryption algorithms may not use initialization vectors, so relying on chosen, secret initialization vectors for security is unwise. Also, the prepended confounder in the existing algorithms is roughly equivalent to a per-message initialization vector that is revealed in encrypted form. However, carrying state across from one encryption to another is explicitly permitted through the opaque "cipher state" object.
【Kerb1510]におけるいくつかのメッセージ定義は、アプリケーションによって指定される初期ベクトルを許容するように読み取ることができます。テキストは、あまりにも漠然としました。これは、明示的にこの仕様で許可されていません。いくつかの暗号化アルゴリズムは、初期化ベクトルを使用するので、セキュリティのために選ばれた、秘密の初期化ベクトルに頼ることは賢明ではありませんしない場合があります。また、既存のアルゴリズムにおけるプリペンド交絡因子は、暗号化された形で明らかにされているメッセージごとの初期化ベクトルとほぼ同等です。しかし、別の暗号化から全体に状態を運ぶには、明示的に不透明な「暗号状態」オブジェクトを介して許可されています。
The use of key derivation is new.
鍵導出の使用が新しいです。
Several new methods are introduced, including generation of a key in wire-protocol format from random input data.
いくつかの新しい方法は、ランダム入力データからワイヤプロトコル形式でキーの生成を含む、導入されます。
The means for influencing the string-to-key algorithm are laid out more clearly.
文字列への鍵アルゴリズムに影響を与えるための手段は、より明確にレイアウトされています。
Triple-DES support is new.
トリプルDESのサポートが新しく追加されました。
The pseudo-random function is new.
擬似ランダム関数は、新しいです。
The des-cbc-crc, DES string-to-key and CRC descriptions have been updated to align them with existing implementations.
DES-CBC-CRCは、DESの文字列からキーへとCRCの説明は、既存の実装とそれらを合わせるように更新されました。
[Kerb1510] did not indicate what character set or encoding might be used for pass phrases and salts.
[Kerb1510]パスフレーズと塩のために使用される可能性がありますどのような文字セットやエンコーディングを示すものではありませんでした。
In [Kerb1510], key types, encryption algorithms, and checksum algorithms were only loosely associated, and the association was not well described. In this specification, key types and encryption algorithms have a one-to-one correspondence, and associations between encryption and checksum algorithms are described so that checksums can be computed given negotiated keys, without requiring further negotiation for checksum types.
[Kerb1510]、鍵のタイプ、暗号化アルゴリズム、およびチェックサムアルゴリズムでのみゆるく関連し、そして関連は十分に記載されていませんでした。本明細書では、キータイプおよび暗号化アルゴリズムは、1対1の対応を有し、かつチェックサムがチェックサムタイプのさらなる交渉を必要とせず、ネゴシエートキー所与計算することができるように暗号化とチェックサムアルゴリズムとの間の関連について説明します。
Notes
ノート
[1] Although Message Authentication Code (MAC) or Message Integrity Check (MIC) would be more appropriate terms for many of the uses in this document, we continue to use the term checksum for historical reasons.
[1]メッセージ認証コード（MAC）、またはメッセージ完全性チェック（MIC）はこの文書の用途の多くのためのより適切な用語だろうが、我々は歴史的な理由のために長期的なチェックサムを継続して使用します。
[2] Extending CBC mode across messages would be one obvious example of this chaining. Another might be the use of counter mode, with a counter randomly initialized and attached to the ciphertext; a second message could continue incrementing the counter when chaining the cipher state, thus avoiding having to transmit another counter value. However, this chaining is only useful for uninterrupted, ordered sequences of messages.
[2]メッセージを横切ってCBCモードの拡張は、このチェーンの1つの明らかな例であろう。もう一つは、ランダムに初期化され、暗号文に添付カウンタとカウンタモードの使用、かもしれません。第2のメッセージは、このように別のカウンタ値を送信する必要が回避、暗号状態を連鎖ときにカウンタを増分続けることができます。しかし、このチェーンが途切れないためにのみ有用である、メッセージの順序を命じました。
[3] In the case of Kerberos, the encrypted objects will generally be ASN.1 DER encodings, which contain indications of their length in the first few octets.
[3]ケルベロスの場合には、暗号化されたオブジェクトは、一般に、第1の数のオクテットにその長さの指示を含むASN.1 DERエンコーディング、あろう。
[4] As of the time of this writing, new modes of operation have been proposed, some of which may permit encryption and integrity protection simultaneously. After some of these proposals have been subjected to adequate analysis, we may wish to formulate a new simplified profile based on one of them.
[4]これを書いている時点では、操作の新しいモードは、そのうちのいくつかは、同時に暗号化と整合性の保護を許可することができ、提案されています。これらの提案のいくつかは、十分な分析が行われた後、我々はそれらのいずれかに基づいて、新しい単純化されたプロファイルを策定することを望むかもしれません。
[5] It should be noted that the sample vector in appendix B.2 of the original paper appears to be incorrect. Two independent implementations from the specification (one in C by Marc Horowitz, and another in Scheme by Bill Sommerfeld) agree on a value different from that in [Blumenthal96].
[5]元の紙の付録B.2のサンプルベクトルが間違っように見えることに留意すべきです。 （ビル・ゾンマーフェルトによってスキームにおけるマーク・ホロウィッツによってC内の1つ、および別の）仕様からの二つの独立した実装が[Blumenthal96]とは異なる値に合意します。
[6] For example, in MIT's implementation of [Kerb1510], the rsa-md5 unkeyed checksum of application data may be included in an authenticator encrypted in a service's key.
[6]例えば、[Kerb1510]のMITの実装では、アプリケーションデータのRSA-MD5キーなしチェックサムは、サービスのキーで暗号化されたオーセンティケータに含まれてもよいです。
[7] Using a variant of the key limits the use of a key to a particular function, separating the functions of generating a checksum from other encryption performed using the session key. The constant 0xF0F0F0F0F0F0F0F0 was chosen because it maintains key parity. The properties of DES precluded the use of the complement. The same constant is used for similar purpose in the Message Integrity Check in the Privacy Enhanced Mail standard.
[7]キーの変異体を使用することは、セッション鍵を使用して実行される他の暗号化からチェックサムを生成する機能を分離し、特定の機能へのキーの使用を制限します。それが重要なパリティを維持するので、一定の0xF0F0F0F0F0F0F0F0が選ばれました。 DESの性質は、補体の使用を排除しました。同じ定数は、プライバシー強化メールの標準におけるメッセージ完全性チェックで同様の目的のために使用されています。
[8] Perhaps one of the more common reasons for directly performing encryption is direct control over the negotiation and to select a "sufficiently strong" encryption algorithm (whatever that means in the context of a given application). Although Kerberos directly provides no direct facility for negotiating encryption types between the application client and server, there are other means to accomplish similar goals (for example, requesting only "strong" session key types from the KDC, and assuming that the type actually returned by the KDC will be understood and supported by the application server).
[8]おそらく直接暗号化を実行するためのより一般的な理由の一つは、ネゴシエーションを直接制御であり（すなわち、所与の用途の文脈で意味するものは何でも）「十分に強い」暗号化アルゴリズムを選択します。 Kerberosは直接アプリケーションのクライアントとサーバ間の暗号化タイプを交渉するためには直接的な機能を提供していませんが、そこKDCからの唯一の「強い」セッションキーの種類を要求、例えば（同様の目標を達成するために他の手段があり、種類が実際で返さことを想定しますKDCは）理解して、アプリケーション・サーバーによってサポートされます。
Normative References
引用規格
[BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
、BCP 26、RFC 2434、1998年10月[BCP26] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"。
[Bellare98] Bellare, M., Desai, A., Pointcheval, D., and P. Rogaway, "Relations Among Notions of Security for Public-Key Encryption Schemes". Extended abstract published in Advances in Cryptology-Crypto 98 Proceedings, Lecture Notes in Computer Science Vol. 1462, H. Krawcyzk ed., Springer-Verlag, 1998.
[Bellare98]ベラー、M.、デサイ、A.、Pointcheval、D.、およびP. Rogaway、 "公開鍵暗号化方式のセキュリティの観念の関係"。拡張抄録は、コンピュータサイエンス巻で暗号学、暗号の進歩98回の議事録、講義ノートに掲載されました。 1462年、H. Krawcyzk編、シュプリンガー・フェアラーク、1998。
[Blumenthal96] Blumenthal, U. and S. Bellovin, "A Better Key Schedule for DES-Like Ciphers", Proceedings of PRAGOCRYPT '96, 1996.
[Blumenthal96]ブルーメンソール、U.およびS. Bellovin氏、 "DES様暗号のためのより良い鍵スケジュール"、PRAGOCRYPT '96、1996年の議事。
[CRC] International Organization for Standardization, "ISO Information Processing Systems - Data Communication - High-Level Data Link Control Procedure - Frame Structure," IS 3309, 3rd Edition, October 1984.
[CRC]国際標準化機構は、「ISO情報処理システム - データ通信 - ハイレベルデータリンク制御手順 - フレーム構造は、」3309、第3版、1984年10月です。
[DES77] National Bureau of Standards, U.S. Department of Commerce, "Data Encryption Standard," Federal Information Processing Standards Publication 46, Washington, DC, 1977.
[DES77]国立標準局、米国商務省が、「データ暗号化規格、」連邦情報処理規格出版46、ワシントンD.C.、1977。
[DESI81] National Bureau of Standards, U.S. Department of Commerce, "Guidelines for implementing and using NBS Data Encryption Standard," Federal Information Processing Standards Publication 74, Washington, DC, 1981.
標準の[DESI81]国民局、米国商務省が、連邦情報処理規格出版74、ワシントンD.C.、1981年「NBSデータ暗号化規格を実装して使用するためのガイドライン」。
[DESM80] National Bureau of Standards, U.S. Department of Commerce, "DES Modes of Operation," Federal Information Processing Standards Publication 81, Springfield, VA, December 1980.
[DESM80]国立標準局、米国商務省が、「動作のDESモード、」連邦情報処理規格出版81、スプリングフィールド、バージニア州、1980年12月。
[Dolev91] Dolev, D., Dwork, C., and M. Naor, "Non-malleable cryptography", Proceedings of the 23rd Annual Symposium on Theory of Computing, ACM, 1991.
【Dolev91] Dolev、D.、Dwork、C.、およびM. Naor、 "非展性暗号"、コンピューティング、ACM、1991の理論第23回シンポジウム。
[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[HMAC] Krawczyk、H.、ベラー、M.、およびR.カネッティ、 "HMAC：メッセージ認証のための鍵付きハッシュ化"、RFC 2104、1997年2月。
[KRB5-AES] Raeburn, K., "Advanced Encryption Standard (AES) Encryption for Kerberos 5", RFC 3962, February 2005.
[KRB5-AES]レイバーン、K.、 "Kerberos 5のためのAdvanced Encryption Standard（AES）暗号化"、RFC 3962、2005年2月。
[MD4-92] Rivest, R., "The MD4 Message-Digest Algorithm", RFC 1320, April 1992.
[MD4-92]リベスト、R.、 "MD4メッセージダイジェストアルゴリズム"、RFC 1320、1992年4月。
[MD5-92] Rivest, R., "The MD5 Message-Digest Algorithm ", RFC 1321, April 1992.
[MD5-92]リベスト、R.、 "MD5メッセージダイジェストアルゴリズム"、RFC 1321、1992年4月。
[SG92] Stubblebine, S. and V. D. Gligor, "On Message Integrity in Cryptographic Protocols," in Proceedings of the IEEE Symposium on Research in Security and Privacy, Oakland, California, May 1992.
セキュリティとプライバシー、オークランド、カリフォルニア州、1992年5月の研究上のIEEEシンポジウムで「暗号プロトコルでメッセージ整合性には、」[SG92] Stubblebineが、S.とV. D. Gligor、。
Informative References
参考文献
[Bellovin91] Bellovin, S. M. and M. Merrit, "Limitations of the Kerberos Authentication System", in Proceedings of the Winter 1991 Usenix Security Conference, January, 1991.
[Bellovin91] Bellovin氏、S. M.とM. Merrit、冬1991年のUsenixセキュリティ会議、1991年1月の議事録では、 "Kerberos認証システムの制限"。
[Bellovin99] Bellovin, S. M. and D. Atkins, private communications, 1999.
【Bellovin99] Bellovin氏、S. M.とD.アトキンス、プライベート通信、1999。
[EFF-DES] Electronic Frontier Foundation, "Cracking DES: Secrets of Encryption Research, Wiretap Politics, and Chip Design", O'Reilly & Associates, Inc., May 1998.
[EFF-DES]電子フロンティア財団、「DESをクラック：暗号研究と盗聴政策、チップ設計の秘密」、オライリー＆アソシエーツ社、1998年5月。
[ESP-DES] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm With Explicit IV", RFC 2405, November 1998.
[ESP-DES] Madson、C.およびN. Doraswamy、 "明示的なIVとESP DES-CBC暗号アルゴリズム"、RFC 2405、1998年11月。
[GSS-KRB5] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, June 1996.
[GSS-KRB5]リン、J.、 "Kerberosバージョン5 GSS-APIメカニズム"、RFC 1964、1996年6月。
[HMAC-TEST] Cheng, P. and R. Glenn, "Test Cases for HMAC-MD5 and HMAC-SHA-1", RFC 2202, September 1997.
[HMAC-TEST]チェン、P.およびR.グレン、 "HMAC-MD5とHMAC-SHA-1のテストケース"、RFC 2202、1997年9月。
[IPSEC-HMAC] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.
[IPSEC-HMAC] Madson、C.およびR.グレン、 "ESPおよびAH内HMAC-SHA-1-96の使用"、RFC 2404、1998年11月。
[Kerb] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", Work in Progress, September 2004.
[カーブ]ニューマン、C.、ゆう、T.、ハートマン、S.、およびK.レイバーン、 "ケルベロスネットワーク認証サービス（V5）"、進歩、2004年9月での作業。
[Kerb1510] Kohl, J. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993.
【Kerb1510]コールズ、J.及びC.ノイマン、 "ケルベロスネットワーク認証サービス（V5）"、RFC 1510、1993年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月。
[RFC1851] Karn, P., Metzger, P., and W. Simpson, "The ESP Triple DES Transform", RFC 1851, September 1995.
[RFC1851]カーン、P.、メッツガー、P.、およびW.シンプソンは、 "ESPトリプルDESは、トランスフォーム"、RFC 1851、1995年9月。
[Schneier96] Schneier, B., "Applied Cryptography Second Edition", John Wiley & Sons, New York, NY, 1996. ISBN 0-471- 12845-7.
[Schneier96]シュナイアー、B.、 "応用暗号第二版"、John Wiley＆Sons、ニューヨーク、NY、1996年ISBN 0-471- 12845から7。
Editor'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機能のための基金は現在、インターネット協会によって提供されます。