RFC3961 日本語訳
3961 Encryption and Checksum Specifications for Kerberos 5. K.Raeburn. February 2005. (Format: TXT=111865 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group K. Raeburn Request for Comments: 3961 MIT Category: Standards Track February 2005
コメントを求めるワーキンググループK.レイバーンの要求をネットワークでつないでください: 3961年のMITカテゴリ: 標準化過程2005年2月
Encryption and Checksum Specifications
for Kerberos 5
ケルベロス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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(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".
このドキュメントは使用のためにケルベロスプロトコルで暗号化とチェックサムメカニズムを定義するためにフレームワークについて説明します、ケルベロスプロトコルと、関連するプロトコルと、実際のメカニズム自体の間の抽象化層を定義して。 また、ドキュメントは数個のメカニズムを定義します。古い仕様が不正確であったときに、或るものは、RFC1510から取られて、この新しいフレームワークに合うようにフォームで変更されて、内容で時折変更されます。 また、新しいメカニズムはここに提示されます。 このドキュメントは、どのメカニズムが「実装するために、必要である」と考えられるかもしれないかを示しません。
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . 2 2。 概念. . . . . . . . . . . . . . . . . . . . . . . . . . 2 3。 暗号化アルゴリズムプロフィール. . . . . . . . . . . . . . . . 4 4。 チェックサムアルゴリズムプロフィール. . . . . . . . . . . . . . . . . 9 5。 CBCのための簡易型のプロフィールは主要な派生. . . 10 5.1で解かれます。 主要な派生機能. . . . . . . . . . . . . . . 10 5.2。 簡易型のプロフィールパラメタ. . . . . . . . . . . . . 12 5.3。 暗号系プロフィールは簡易型のプロフィール. . . 13 5.4を基礎づけました。 チェックサムプロフィールは簡易型のプロフィール. . . . . 16 6を基礎づけました。 ケルベロス暗号化とチェックサムアルゴリズム. . 16 6.1のためのプロフィール。 チェックサム. . . . . . . . . . . . . . . . . . . 17 6.2をUnkeyedしました。 DESベースの暗号化とチェックサムは.186.3をタイプします。 三重のDESは暗号化とチェックサムタイプ. . . . 28 7を基礎づけました。 この仕様. . . . 30の外におけるケルベロス暗号化の使用
Raeburn Standards Track [Page 1] RFC 3961 Encryption and Checksum Specifications February 2005
レイバーン標準化過程[1ページ]RFC3961暗号化とチェックサム仕様2005年2月
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
8. 規定番号. . . . . . . . . . . . . . . . . . . . . . 31 9。 実装注意. . . . . . . . . . . . . . . . . . . . 32 10。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 33 11。 IANA問題. . . . . . . . . . . . . . . . . . . . . 35 12。 承認。 . . . . . . . . . . . . . . . . . . . . . . .38A.1n倍の.38にベクトルをテストしてください。36 A. A.2_主要な.39A.3へのmit_des_ストリング_。 DES3 DRとDK. . . . . . . . . . . . . . . . . . . . 43A.4。 _主要な.44A.5へのDES3string_。 RFC1510.45からの変更されたCRC-32. . . . . . . . . . . . . . . . . . . . 44B.著しい変化は.46の引用規格に注意します。 . . . . . . . . . . . . . . . . . . . . . . 47 有益な参照。 . . . . . . . . . . . . . . . . . . . . . 48エディタのアドレス。 . . . . . . . . . . . . . . . . . . . . . . . . 49 完全な著作権宣言文。 . . . . . . . . . . . . . . . . . . . . 50
1. Introduction
1. 序論
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.
ケルベロスプロトコル[縁石]は任意のサイズに関するメッセージを暗号化するように設計されています、ブロック暗号化暗号か一般的にないストリーム暗号化暗号を使用して。 暗号化は、交換処理に参加するネットワーク実体のアイデンティティを立証するのに使用されます。 しかしながら、ケルベロスプロトコルの何も、どんな特定の暗号化アルゴリズムも使用されるのを必要としません、アルゴリズムが、ある操作を含んでいる限り。
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.
以下のセクションはメカニズムが現在ケルベロスのために定義した暗号化とチェックサムを指定します、将来のメカニズムを定義するためのフレームワークと同様に。それぞれのためのコード化、推論、詰め物、および他の要件は説明されます。 付録Aはいくつかの機能のためにテストベクトルを与えます。
2. Concepts
2. 概念
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.
暗号化とチェックサムメカニズムの両方が後のセクションで輪郭を描かれます。 各プロフィールはメカニズムのために定義しなければならない操作と属性の収集を指定します。 これらの操作と属性のすべてを定義しないなら、ケルベロス暗号化かチェックサムメカニズム仕様が完全ではありません。
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
暗号化メカニズムはオリジナルの平文の秘密性と保全に備えなければなりません。 (チェックサムを取り入れると、暗号化モードが保全チェック自体を提供しないならチェックする保全は可能にするかもしれません。) また、それは非展性を提供しなければなりません。
Raeburn Standards Track [Page 2] RFC 3961 Encryption and Checksum Specifications February 2005
レイバーン標準化過程[2ページ]RFC3961暗号化とチェックサム仕様2005年2月
[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。] 平文にprependedされた無作為の交絡因子の使用はお勧めです。 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.
私たちはケルベロスの中でキーの異なった用途を列挙して、「用法番号」を入力にすることによって、暗号化かチェックサムメカニズムにこれをします。 このドキュメントの範囲の外にそのような列挙はあります。 後のセクションは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.
ケルベロス暗号化とチェックサムタイプで定義された新しいプロトコルはそれら自身の主要な用法値を使用するべきです。 主要な用法は未署名の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はバイトに噛み付きました。 他のバイトサイズがある環境は、正しい結果を得るためにこの振舞いを見習わなければならないでしょう。
Raeburn Standards Track [Page 3] RFC 3961 Encryption and Checksum Specifications February 2005
レイバーン標準化過程[3ページ]RFC3961暗号化とチェックサム仕様2005年2月
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.
アルゴリズム識別の暗号化タイプ(または、"etype")かチェックサム形式数がケルベロスプロトコルの中で各アルゴリズムに選任されます。 セクション8で現在の形式数課題に関する完全リストを与えます。
3. Encryption Algorithm Profile
3. 暗号化アルゴリズムプロフィール
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.
暗号化メカニズムプロフィールは以下の属性と操作を定義しなければなりません。 数学の意味で操作を機能と定義しなければなりません。 どんな追加しているか暗黙の入力(ケルベロス主体名かメッセージ通番などの)も受入れられません。
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.
プロトコルキー形式Thisは、どの八重奏ストリング値が有効なキーを表すかを説明します。 完全に濃い主要な空間を持っていない暗号化メカニズムのために、これはキーをコード化するのに使用される表現について説明するでしょう。 それは無効の特定の値について説明する必要はありません。 すべてのキー生成で、ルーチンはそのような値を避けるべきです。
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.
特定の主要な構造Thisはチェックサムについて全くプロトコル形式ではなく、材料が選ばれたキーから派生して、以前はよく暗号化していた合わせることの記述であるデータを解読するか、計算するか、または確かめます。 例えば、それは単一のキーであるかもしれません(キー、または追加データへのオリジナルのキーの組み合わせの1セット)。 作者は、オリジナルのキーから一方向主要な派生機能で得られた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.
必要なチェックサムメカニズムThisはこの暗号化メカニズムが使用されているとき利用可能であるに違いないチェックサムメカニズムを示します。 チェックサムメカニズムを交渉するためにメカニズムでケルベロスでいいえを築き上げるので、暗号化メカニズムがいったん決められると、対応するチェックサムメカニズムを使用できます。
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 Thisは暗号化体系のもので主要な機能に無作為の状態で(以下で、説明されます)キーを生成するのに必要である無作為のbitstringの長さです。 これは、キー生成機能と共に与えられた長さの無作為のbitstringを生産するための様々なテクニックを使用できるための一定の価値でなければなりません。
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
異なったタイプの入力から件数でキー生成機能キーズを生成しなければなりません。 すべての機能仕様が、適切なワイヤ形式でキーを生成する方法を示さなければならなくて、暗号化されたデータの秘密性にかなり感染するキーを生成するのを避けなければなりません、暗号系にそのようなものがあるなら。 それぞれからのエントロピー
Raeburn Standards Track [Page 4] RFC 3961 Encryption and Checksum Specifications February 2005
レイバーン標準化過程[4ページ]RFC3961暗号化とチェックサム仕様2005年2月
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ストリングと不透明な八重奏ストリングからキーを生成する->(プロトコル主要な)。 ストリングの1つは通常主体のパス句ですが、一般にそれは単に秘密のストリングです。 もう片方のストリングは同じパスワードと異なったキーが異なったユーザか分野に生産されるつもりであった「塩」ストリングです。提供されたストリングはUTF-8コード化を使用するでしょうが、ユニコードのどんな特定のバージョンも想定するべきではありません。 すべての有効なUTF-8ストリングが許容されるべきです。 この機能を適用する前に、最初に、他のencodingsに提供されたストリングを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.
3番目の主張(八重奏ストリング)は、メカニズム特有のパラメタをこの機能に通過するのに使用されるかもしれません。 以来そうするのは特定の暗号化システムに関する知識を含意して、非デフォルトがパラメタ値であると生成するのは、珍しい操作であるべきです、そして、通常のケルベロスアプリケーションがKey Distributionセンターによって供給されたか何らかのメカニズム特有の恒常価値をデフォルトとした不透明なオブジェクトとしてこのパラメタブロックを扱うことができるべきです。
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.
キーに無作為である、(この機能が特定のサイズの無作為のbitstringからキーを生成するbitstring[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
ストリングからキーへのパラメタ形式Thisはその機能のための追加パラメタを構成するために上で主要な機能へのストリングに通過できるデータのブロックの形式について説明します。 また、値、許容パラメタの領域がそうするべきであるコード化パラメタのメカニズムと共に、説明されて、偽造しているKDCが妥協するのを許容するのを避けてください。
Raeburn Standards Track [Page 5] RFC 3961 Encryption and Checksum Specifications February 2005
レイバーン標準化過程[5ページ]RFC3961暗号化とチェックサム仕様2005年2月
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.
ユーザのパスワード。 実用的であるなら、コード化を組み立てるのは、結果として起こるキーを容認できないほど弱める値をコード化できないくらい望ましいかもしれません。
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.
アプリケーション・プロトコル(何らかのケルベロス)が明らかにパラメタ値を設定しないとき、デフォルトストリングから重要へのこのデフォルトが"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.
暗号州のThisは1つの暗号化か復号化操作から次まで持ち越すことができるどんな情報についても説明します、与えられた特定のキーによる使用のために。 例えば、CBCモードで使用されるブロック暗号は1ブロックの初期ベクトルを暗号状態に置くかもしれません。 他の暗号化モードは一回だけか他のデータを追跡するかもしれません。
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.
この州が非空でなければならなく、暗号化に影響を及ぼさなければならないので、メッセージは同次で解読されて、それらが暗号化されたaでした、暗号状態が、ある暗号化から次まで持ち越されるならことです。 崩壊したメッセージと故障しているかなくなったメッセージを区別するのは必要ではありません。 望んでいるなら、より高いレベルで一連番号を含んで、暗号化操作の間の暗号状態が「チェーン」でないことによって、これができます。
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.
初期の暗号は->(状態)を述べます(特定のキー、方向)。それが前の暗号化か復号化操作から持ち越されないなら、これは初期の価値の世代について暗号状態に説明します。
Raeburn Standards Track [Page 6] RFC 3961 Encryption and Checksum Specifications February 2005
レイバーン標準化過程[6ページ]RFC3961暗号化とチェックサム仕様2005年2月
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操作に使用される初期ベクトルのコントロールをどの度合いに運動させることができますか? いくつかの既存の実装が、初期ベクトルを設定することを許可します。 このフレームワークは暗号状態(向こうでは、「初期化し」て、「前の暗号化から、運ぶ」)のアプリケーション制御装置に備えません、初期の暗号状態のフォームと内容が暗号化システムの間で異なることができて、いつも1単滑車の無作為のデータであるかもしれないというわけではないので。
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.
新しいケルベロスアプリケーション・プロトコルが初期ベクトルのコントロールを仮定するべきではありませんか、またはそれは存在してさえいます。 しかしながら、明らかにそれを設定するアプリケーションが遭遇するといけないので、一般的な目的実装は能力を提供したがっているかもしれません。
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.
特定のキーと暗号状態への値が正しく生産されていると仮定する場合、どんな入力八重奏ストリングも誤り表示をもたらしてはいけません。
Raeburn Standards Track [Page 7] RFC 3961 Encryption and Checksum Specifications February 2005
レイバーン標準化過程[7ページ]RFC3961暗号化とチェックサム仕様2005年2月
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.
これらの操作と属性はケルベロスと様々な提案された前認証体系をサポートするのに必要であるすべてです。
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.
あるアプリケーション・プロトコルの便利を、それは暗号化プロフィールを使用したがっているかもしれなくて、私たちは、終わりに、暗号文の解読されたバージョンの長さには付加的な八重奏が決してないように、メッセージサイズがどんな与えられた平文入力サイズのためにもその与えられたサイズとそのサイズの間に存在しなければならないという規制と6万5535を言い足します。
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>は各メッセージMあたりL1 L2<L1+6万5536と等しいです。|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.
また新しい暗号化タイプを定義すると説明されるべきであるドキュメントは、セキュリティを公正に査定できるように弱点か攻撃を知っていて、操作のための手順が定義したテストベクトルか他の合法化を含んでいるはずです。 ほかの場所で容易に入手できている情報の特定指示は十分です。
Raeburn Standards Track [Page 8] RFC 3961 Encryption and Checksum Specifications February 2005
レイバーン標準化過程[8ページ]RFC3961暗号化とチェックサム仕様2005年2月
4. Checksum Algorithm Profile
4. チェックサムアルゴリズムプロフィール
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.)
合わせられたチェックサムメカニズムには、彼らが同じワイヤ主要な形式、ストリングから主要な機能、デフォルトのストリングから重要パラメタ、および主要な派生機能を共有するなら、1つ以上の関連暗号化アルゴリズムがあるかもしれません。 (この組み合わせはそれを意味して、例えば、チェックサムタイプ、主要な用法値、およびパスワードはチェックサムを計算するのに特定のキーを使用させるために適切です。)
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.
_機能が使用されるかもしれない与えられた特定のキー(セクション3を見る)とメッセージ(八重奏ストリングとして、表される)のためにMICトークンを生成するmic機能Thisに関連メッセージの保全について確かめさせてください。 この機能は各使用のために同じ決定論的な結果を返すのに必要ではありません。 トークンがそれであると生成するだけでよい、micルーチンがチェックできる_について確かめてください。
The output of this function will also dictate the size of the
checksum. It must be no larger than 65,535 octets.
また、この機能の出力はチェックサムのサイズを決めるでしょう。 それは6万5535の八重奏より大きいはずがありません。
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.
_メッセージの保全が感染されたか否かに関係なく、Givenのa特定のキー、メッセージ、およびMICトークン、この機能が確かめるmic機能について確かめてください。 aにおける決定論、micに日常的に_をならせてください、対応は、micが単に別のチェックサムを生成するかもしれない_について確かめて、2を比較します。
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.
_micを手に入れてください、そして、_操作が任意の長さの入力を許さなければならないmicについて確かめてください。 何か詰め物が必要であるなら、これらの一部が機能するとき、詰め物体系を指定しなければなりません。
These operations and attributes are all that should be required to support Kerberos and various proposed preauthentication schemes.
これらの操作と属性はケルベロスと様々な提案された前認証体系をサポートするのに必要であるべきであるすべてです。
As with encryption mechanism definition documents, documents defining new checksum mechanisms should indicate validation processes and known weaknesses.
暗号化メカニズム定義ドキュメントなら、新しいチェックサムメカニズムを定義するドキュメントは合法化プロセスと知られている弱点を示すはずです。
Raeburn Standards Track [Page 9] RFC 3961 Encryption and Checksum Specifications February 2005
レイバーン標準化過程[9ページ]RFC3961暗号化とチェックサム仕様2005年2月
5. Simplified Profile for CBC Ciphers with Key Derivation
5. 主要な派生があるCBC暗号のための簡易型のプロフィール
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で概説されたプロフィールは暗号化とチェックサムアルゴリズムがケルベロスで使用されるために定義しなければならない多くの操作について説明します。 ここで、私たちは暗号化とチェックサムの両方にメカニズム定義を生成することができるより簡単なプロフィールについて説明します、適切な場所の主要な派生の用途に記入して、より小さい操作に基づく暗号系プロフィールのために保全保護を提供して、同時併行処理を定義して。 この簡易型のプロフィールに合われたケルベロスのための既存の暗号系のすべてではなく、私たちが、将来の暗号系がそれを使用するか、または何かが[4]をそれに基礎づけたことを勧めます。
Not all the operations in the complete profiles are defined through this mechanism; several must still be defined for each new algorithm pair.
完全なプロフィールでのすべての操作がこのメカニズムを通して定義されるというわけではありません。 それぞれの新しいアルゴリズム組のためにまだ数個を定義しなければなりません。
5.1. A Key Derivation Function
5.1. 主要な派生機能
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.
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.
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].
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].
Derived Key = DK(Base Key, Well-Known Constant)
Derived Key = DK(Base Key, Well-Known Constant)
DK(Key, Constant) = random-to-key(DR(Key, Constant))
DK(Key, Constant) = random-to-key(DR(Key, Constant))
DR(Key, Constant) = k-truncate(E(Key, Constant,
initial-cipher-state))
DR(Key, Constant) = k-truncate(E(Key, Constant, initial-cipher-state))
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
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
Raeburn Standards Track [Page 10] RFC 3961 Encryption and Checksum Specifications February 2005
Raeburn Standards Track [Page 10] RFC 3961 Encryption and Checksum Specifications February 2005
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.
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.
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.
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.
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):
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):
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(Key, n-fold(Constant), initial-cipher-state) K2 = E(Key, K1, initial-cipher-state) K3 = E(Key, K2, initial-cipher-state) K4 = ...
DR(Key, Constant) = k-truncate(K1 | K2 | K3 | K4 ...)
DR(Key, Constant) = 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-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]:
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.
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.
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....
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....
Test vectors for n-fold are supplied in appendix A [5].
Test vectors for n-fold are supplied in appendix 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.
In this section, n-fold is always used to produce c bits of output, where c is the cipher block size of E.
The size of the Constant must not be larger than c, because reducing the length of the Constant by n-folding can cause collisions.
The size of the Constant must not be larger than c, because reducing the length of the Constant by n-folding can cause collisions.
Raeburn Standards Track [Page 11] RFC 3961 Encryption and Checksum Specifications February 2005
Raeburn Standards Track [Page 11] RFC 3961 Encryption and Checksum Specifications February 2005
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.
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.
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.
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.
5.2. Simplified Profile Parameters
5.2. Simplified Profile Parameters
These are the operations and attributes that must be defined:
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.
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.
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).
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).
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 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.
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
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
Raeburn Standards Track [Page 12] RFC 3961 Encryption and Checksum Specifications February 2005
Raeburn Standards Track [Page 12] RFC 3961 Encryption and Checksum Specifications February 2005
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.
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.
This value must be a multiple of eight bits (one octet).
This value must be a multiple of eight bits (one octet).
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.
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.
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).
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).
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.
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.
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.
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.
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.
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.
Although there are still a number of properties to specify, they are fewer and simpler than in the full profile.
Although there are still a number of properties to specify, they are fewer and simpler than in the full profile.
5.3. Cryptosystem Profile Based on Simplified Profile
5.3. Cryptosystem Profile Based on Simplified 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.
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.
Raeburn Standards Track [Page 13] RFC 3961 Encryption and Checksum Specifications February 2005
Raeburn Standards Track [Page 13] RFC 3961 Encryption and Checksum Specifications February 2005
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.
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.
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.
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.
The substring notation "[1..h]" in the following table should be read as using 1-based indexing; leading substrings are used.
The substring notation "[1..h]" in the following table should be read as using 1-based indexing; leading substrings are used.
Raeburn Standards Track [Page 14] RFC 3961 Encryption and Checksum Specifications February 2005
Raeburn Standards Track [Page 14] RFC 3961 Encryption and Checksum Specifications February 2005
Cryptosystem from Simplified Profile
------------------------------------------------------------------------
protocol key format As given.
Cryptosystem from Simplified Profile ------------------------------------------------------------------------ protocol key format As given.
specific key structure Three protocol-format keys: { Kc, Ke, Ki }.
specific key structure Three protocol-format keys: { Kc, Ke, Ki }.
key-generation seed As given. length
key-generation seed As given. length
required checksum As defined below in section 5.4. mechanism
required checksum As defined below in section 5.4. mechanism
cipher state Initial vector (usually of length c)
cipher state Initial vector (usually of length c)
initial cipher state All bits zero
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
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
decryption function (C1,H1) = ciphertext
(P1, newIV) = D(Ke, C1, oldstate.ivec)
if (H1 != HMAC(Ki, P1)[1..h])
report error
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
default string-to-key As given. params
default string-to-key As given. 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)
pseudo-random function tmp1 = H(octet-string) tmp2 = truncate tmp1 to multiple of m PRF = E(DK(protocol-key, prfconstant), tmp2, initial-cipher-state)
The "prfconstant" used in the PRF operation is the three-octet string "prf".
The "prfconstant" used in the PRF operation is the three-octet string "prf".
Raeburn Standards Track [Page 15] RFC 3961 Encryption and Checksum Specifications February 2005
Raeburn Standards Track [Page 15] RFC 3961 Encryption and Checksum Specifications February 2005
Cryptosystem from Simplified Profile
------------------------------------------------------------------------
key generation functions:
Cryptosystem from Simplified Profile ------------------------------------------------------------------------ key generation functions:
string-to-key function As given.
string-to-key function As given.
random-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.
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.
Kc = DK(base-key, usage | 0x99);
Ke = DK(base-key, usage | 0xAA);
Ki = DK(base-key, usage | 0x55);
Kc = DK(base-key, usage | 0x99); Ke = DK(base-key, usage | 0xAA); Ki = DK(base-key, usage | 0x55);
5.4. Checksum Profiles Based on Simplified Profile
5.4. Checksum Profiles Based on Simplified Profile
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:
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:
Checksum Mechanism from Simplified Profile
--------------------------------------------------
associated cryptosystem As defined above.
Checksum Mechanism from Simplified Profile -------------------------------------------------- associated cryptosystem As defined above.
get_mic HMAC(Kc, message)[1..h]
get_mic HMAC(Kc, message)[1..h]
verify_mic get_mic and compare
verify_mic get_mic and compare
The HMAC function and key Kc are as described in section 5.3.
The HMAC function and key Kc are as described in section 5.3.
6. Profiles for Kerberos Encryption and Checksum Algorithms
6. Profiles for Kerberos Encryption and Checksum Algorithms
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.
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.
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.
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.
Raeburn Standards Track [Page 16] RFC 3961 Encryption and Checksum Specifications February 2005
Raeburn Standards Track [Page 16] RFC 3961 Encryption and Checksum Specifications February 2005
6.1. Unkeyed Checksums
6.1. Unkeyed Checksums
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.
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.1.1. The RSA MD5 Checksum
6.1.1. The RSA MD5 Checksum
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.
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
----------------------------------------------
associated cryptosystem any
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 and compare
The rsa-md5 checksum algorithm is assigned a checksum type number of seven (7).
The rsa-md5 checksum algorithm is assigned a checksum type number of seven (7).
6.1.2. The RSA MD4 Checksum
6.1.2. The RSA MD4 Checksum
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.
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
----------------------------------------------
associated cryptosystem any
rsa-md4 ---------------------------------------------- associated cryptosystem any
get_mic md4(msg)
get_mic md4(msg)
verify_mic get_mic and compare
verify_mic get_mic and compare
The rsa-md4 checksum algorithm is assigned a checksum type number of two (2).
The rsa-md4 checksum algorithm is assigned a checksum type number of two (2).
Raeburn Standards Track [Page 17] RFC 3961 Encryption and Checksum Specifications February 2005
Raeburn Standards Track [Page 17] RFC 3961 Encryption and Checksum Specifications February 2005
6.1.3. CRC-32 Checksum
6.1.3. CRC-32 Checksum
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.
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.
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.
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.
Test values for this modified CRC function are included in appendix A.5.
Test values for this modified CRC function are included in appendix A.5.
crc32
----------------------------------------------
associated cryptosystem any
crc32 ---------------------------------------------- associated cryptosystem any
get_mic crc32(msg)
get_mic crc32(msg)
verify_mic get_mic and compare
verify_mic get_mic and compare
The crc32 checksum algorithm is assigned a checksum type number of one (1).
The crc32 checksum algorithm is assigned a checksum type number of one (1).
6.2. DES-Based Encryption and Checksum Types
6.2. DES-Based Encryption and Checksum Types
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.
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.
Raeburn Standards Track [Page 18] RFC 3961 Encryption and Checksum Specifications February 2005
Raeburn Standards Track [Page 18] RFC 3961 Encryption and Checksum Specifications February 2005
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.
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.
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.
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.
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.
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.
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.
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.
Encryption Data Format
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.
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.
+-----------+----------+---------+-----+
|confounder | checksum | msg-seq | pad |
+-----------+----------+---------+-----+
+-----------+----------+---------+-----+ |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.
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.
Raeburn Standards Track [Page 19] RFC 3961 Encryption and Checksum Specifications February 2005
Raeburn Standards Track [Page 19] RFC 3961 Encryption and Checksum Specifications February 2005
String or Random-Data to Key Transformation
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.
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.
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.
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.
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.
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.
Pseudocode follows:
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 */
}
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 */
}
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 */ }
Raeburn Standards Track [Page 20] RFC 3961 Encryption and Checksum Specifications February 2005
Raeburn Standards Track [Page 20] RFC 3961 Encryption and Checksum Specifications February 2005
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 */
}
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);
}
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);
}
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");
}
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"); }
Raeburn Standards Track [Page 21] RFC 3961 Encryption and Checksum Specifications February 2005
Raeburn Standards Track [Page 21] RFC 3961 Encryption and Checksum Specifications February 2005
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).
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).
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:
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:
des_random_to_key(bitstring) {
return key_correction(add_parity_bits(bitstring));
}
des_random_to_key(bitstring) { return key_correction(add_parity_bits(bitstring)); }
6.2.1. DES with MD5
6.2.1. DES with MD5
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.
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.
The encryption system parameters for des-cbc-md5 are as follows:
The encryption system parameters for des-cbc-md5 are as follows:
des-cbc-md5
--------------------------------------------------------------------
protocol key format 8 bytes, parity in low bit of each
des-cbc-md5 -------------------------------------------------------------------- protocol key format 8 bytes, parity in low bit of each
specific key structure copy of original key
specific key structure copy of original key
required checksum rsa-md5-des mechanism
required checksum rsa-md5-des mechanism
key-generation seed 8 bytes length
key-generation seed 8 bytes length
cipher state 8 bytes (CBC initial vector)
cipher state 8 bytes (CBC initial vector)
initial cipher state all-zero
initial cipher state all-zero
encryption function des-cbc(confounder | checksum | msg | pad,
ivec=oldstate)
where
checksum = md5(confounder | 0000...
| msg | pad)
encryption function des-cbc(confounder | checksum | msg | pad, ivec=oldstate) where checksum = md5(confounder | 0000... | msg | pad)
newstate = last block of des-cbc output
newstate = last block of des-cbc output
decryption function decrypt encrypted text and verify checksum
decryption function decrypt encrypted text and verify checksum
newstate = last block of ciphertext
newstate = last block of ciphertext
Raeburn Standards Track [Page 22] RFC 3961 Encryption and Checksum Specifications February 2005
Raeburn Standards Track [Page 22] RFC 3961 Encryption and Checksum Specifications February 2005
des-cbc-md5
--------------------------------------------------------------------
default string-to-key empty string
params
des-cbc-md5 -------------------------------------------------------------------- default string-to-key empty string params
pseudo-random function des-cbc(md5(input-string), ivec=0)
pseudo-random function des-cbc(md5(input-string), ivec=0)
key generation functions:
key generation functions:
string-to-key des_string_to_key
string-to-key des_string_to_key
random-to-key des_random_to_key
random-to-key des_random_to_key
key-derivation identity
key-derivation identity
The des-cbc-md5 encryption type is assigned the etype value three (3).
The des-cbc-md5 encryption type is assigned the etype value three (3).
6.2.2. DES with MD4
6.2.2. DES with MD4
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.
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
--------------------------------------------------------------------
protocol key format 8 bytes, parity in low bit of each
des-cbc-md4 -------------------------------------------------------------------- protocol key format 8 bytes, parity in low bit of each
specific key structure copy of original key
specific key structure copy of original key
required checksum rsa-md4-des mechanism
required checksum rsa-md4-des mechanism
key-generation seed 8 bytes length
key-generation seed 8 bytes length
cipher state 8 bytes (CBC initial vector)
cipher state 8 bytes (CBC initial vector)
initial cipher state all-zero
initial cipher state all-zero
encryption function des-cbc(confounder | checksum | msg | pad,
ivec=oldstate)
where
checksum = md4(confounder | 0000...
| msg | pad)
encryption function des-cbc(confounder | checksum | msg | pad, ivec=oldstate) where checksum = md4(confounder | 0000... | msg | pad)
newstate = last block of des-cbc output
newstate = last block of des-cbc output
Raeburn Standards Track [Page 23] RFC 3961 Encryption and Checksum Specifications February 2005
Raeburn Standards Track [Page 23] RFC 3961 Encryption and Checksum Specifications February 2005
des-cbc-md4
--------------------------------------------------------------------
des-cbc-md4 --------------------------------------------------------------------
decryption function decrypt encrypted text and verify checksum
decryption function decrypt encrypted text and verify checksum
newstate = last block of ciphertext
newstate = last block of ciphertext
default string-to-key empty string params
default string-to-key empty string params
pseudo-random function des-cbc(md5(input-string), ivec=0)
pseudo-random function des-cbc(md5(input-string), ivec=0)
key generation functions:
key generation functions:
string-to-key des_string_to_key
string-to-key des_string_to_key
random-to-key copy input, then fix parity bits
random-to-key copy input, then fix parity bits
key-derivation identity
key-derivation identity
Note that des-cbc-md4 uses md5, not md4, in the PRF definition.
Note that des-cbc-md4 uses md5, not md4, in the PRF definition.
The des-cbc-md4 encryption algorithm is assigned the etype value two (2).
The des-cbc-md4 encryption algorithm is assigned the etype value two (2).
6.2.3. DES with CRC
6.2.3. DES with CRC
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.
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
--------------------------------------------------------------------
protocol key format 8 bytes, parity in low bit of each
des-cbc-crc -------------------------------------------------------------------- protocol key format 8 bytes, parity in low bit of each
specific key structure copy of original key
specific key structure copy of original key
required checksum rsa-md5-des mechanism
required checksum rsa-md5-des mechanism
key-generation seed 8 bytes length
key-generation seed 8 bytes length
cipher state 8 bytes (CBC initial vector)
cipher state 8 bytes (CBC initial vector)
Raeburn Standards Track [Page 24] RFC 3961 Encryption and Checksum Specifications February 2005
Raeburn Standards Track [Page 24] RFC 3961 Encryption and Checksum Specifications February 2005
des-cbc-crc
--------------------------------------------------------------------
initial cipher state copy of original key
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)
encryption function des-cbc(confounder | checksum | msg | pad, ivec=oldstate) where checksum = crc(confounder | 00000000 | msg | pad)
newstate = last block of des-cbc output
newstate = last block of des-cbc output
decryption function decrypt encrypted text and verify checksum
decryption function decrypt encrypted text and verify checksum
newstate = last block of ciphertext
newstate = last block of ciphertext
default string-to-key empty string params
default string-to-key empty string params
pseudo-random function des-cbc(md5(input-string), ivec=0)
pseudo-random function des-cbc(md5(input-string), ivec=0)
key generation functions:
key generation functions:
string-to-key des_string_to_key
string-to-key des_string_to_key
random-to-key copy input, then fix parity bits
random-to-key copy input, then fix parity bits
key-derivation identity
key-derivation identity
The des-cbc-crc encryption algorithm is assigned the etype value one (1).
The des-cbc-crc encryption algorithm is assigned the etype value one (1).
6.2.4. RSA MD5 Cryptographic Checksum Using DES
6.2.4. RSA MD5 Cryptographic Checksum Using DES
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.
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.
Raeburn Standards Track [Page 25] RFC 3961 Encryption and Checksum Specifications February 2005
Raeburn Standards Track [Page 25] RFC 3961 Encryption and Checksum Specifications February 2005
rsa-md5-des
----------------------------------------------------------------
associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc
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(key XOR 0xF0F0F0F0F0F0F0F0, conf | rsa-md5(conf | msg))
verify_mic decrypt and verify rsa-md5 checksum
verify_mic decrypt and verify rsa-md5 checksum
The rsa-md5-des checksum algorithm is assigned a checksum type number of eight (8).
The rsa-md5-des checksum algorithm is assigned a checksum type number of eight (8).
6.2.5. RSA MD4 Cryptographic Checksum Using DES
6.2.5. RSA MD4 Cryptographic Checksum Using DES
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.
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
----------------------------------------------------------------
associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc
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(key XOR 0xF0F0F0F0F0F0F0F0, conf | rsa-md4(conf | msg), ivec=0)
verify_mic decrypt and verify rsa-md4 checksum
verify_mic decrypt and verify rsa-md4 checksum
The rsa-md4-des checksum algorithm is assigned a checksum type number of three (3).
The rsa-md4-des checksum algorithm is assigned a checksum type number of three (3).
6.2.6. RSA MD4 Cryptographic Checksum Using DES Alternative
6.2.6. RSA MD4 Cryptographic Checksum Using DES Alternative
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.
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.
Raeburn Standards Track [Page 26] RFC 3961 Encryption and Checksum Specifications February 2005
Raeburn Standards Track [Page 26] RFC 3961 Encryption and Checksum Specifications February 2005
rsa-md4-des-k
----------------------------------------------------------------
associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc
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(key, md4(msg), ivec=key)
verify_mic decrypt, compute checksum and compare
verify_mic decrypt, compute checksum and compare
The rsa-md4-des-k checksum algorithm is assigned a checksum type number of six (6).
The rsa-md4-des-k checksum algorithm is assigned a checksum type number of six (6).
6.2.7. DES CBC Checksum
6.2.7. DES CBC Checksum
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.
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
---------------------------------------------------------------------
associated des-cbc-md5, des-cbc-md4, des-cbc-crc
cryptosystem
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(key XOR 0xF0F0F0F0F0F0F0F0, conf | des-mac(key, conf | msg | pad, ivec=0), ivec=0)
verify_mic decrypt, compute DES MAC using confounder, compare
verify_mic decrypt, compute DES MAC using confounder, compare
The des-mac checksum algorithm is assigned a checksum type number of four (4).
The des-mac checksum algorithm is assigned a checksum type number of four (4).
6.2.8. DES CBC Checksum Alternative
6.2.8. DES CBC Checksum Alternative
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
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
Raeburn Standards Track [Page 27] RFC 3961 Encryption and Checksum Specifications February 2005
Raeburn Standards Track [Page 27] RFC 3961 Encryption and Checksum Specifications February 2005
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.
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
----------------------------------------------------------------
associated cryptosystem des-cbc-md5, des-cbc-md4, des-cbc-crc
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(key, msg | pad, ivec=key)
verify_mic compute MAC and compare
verify_mic compute MAC and compare
The des-mac-k checksum algorithm is assigned a checksum type number of five (5).
The des-mac-k checksum algorithm is assigned a checksum type number of five (5).
6.3. Triple-DES Based Encryption and Checksum Types
6.3. Triple-DES Based Encryption and Checksum Types
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.
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.
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.
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.
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).
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).
The simplified profile for Triple DES, with key derivation as defined in section 5, is as follows:
The simplified profile for Triple DES, with key derivation as defined in section 5, is as follows:
des3-cbc-hmac-sha1-kd, hmac-sha1-des3-kd
------------------------------------------------
protocol key format 24 bytes, parity in low
bit of each
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
key-generation seed 21 bytes length
Raeburn Standards Track [Page 28] RFC 3961 Encryption and Checksum Specifications February 2005
Raeburn Standards Track [Page 28] RFC 3961 Encryption and Checksum Specifications February 2005
des3-cbc-hmac-sha1-kd, hmac-sha1-des3-kd
------------------------------------------------
hash function SHA-1
des3-cbc-hmac-sha1-kd, hmac-sha1-des3-kd ------------------------------------------------ hash function SHA-1
HMAC output size 160 bits
HMAC output size 160 bits
message block size 8 bytes
message block size 8 bytes
default string-to-key empty string
params
default string-to-key empty string params
encryption and triple-DES encrypt and
decryption functions decrypt, in outer-CBC
mode (cipher block size
8 octets)
encryption and triple-DES encrypt and decryption functions decrypt, in outer-CBC mode (cipher block size 8 octets)
key generation functions:
key generation functions:
random-to-key DES3random-to-key (see
below)
random-to-key DES3random-to-key (see below)
string-to-key DES3string-to-key (see
below)
string-to-key DES3string-to-key (see below)
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).
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).
6.3.1. Triple DES Key Production (random-to-key, string-to-key)
6.3.1. Triple DES Key Production (random-to-key, string-to-key)
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:
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:
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-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
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.
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.
Raeburn Standards Track [Page 29] RFC 3961 Encryption and Checksum Specifications February 2005
Raeburn Standards Track [Page 29] RFC 3961 Encryption and Checksum Specifications February 2005
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.
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.
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:
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:
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)
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".
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".
7. Use of Kerberos Encryption Outside This Specification
7. Use of Kerberos Encryption Outside This Specification
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.
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.
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).
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).
Raeburn Standards Track [Page 30] RFC 3961 Encryption and Checksum Specifications February 2005
Raeburn Standards Track [Page 30] RFC 3961 Encryption and Checksum Specifications February 2005
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.
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.
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.
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].
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].
8. Assigned Numbers
8. Assigned Numbers
The following encryption-type numbers are already assigned or reserved for use in Kerberos and related protocols.
The following encryption-type numbers are already assigned or reserved for use in Kerberos and related protocols.
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)
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)
Raeburn Standards Track [Page 31] RFC 3961 Encryption and Checksum Specifications February 2005
Raeburn Standards Track [Page 31] RFC 3961 Encryption and Checksum Specifications February 2005
(The "des3-cbc-sha1" assignment is a deprecated version using no key derivation. It should not be confused with des3-cbc-sha1-kd.)
(The "des3-cbc-sha1" assignment is a deprecated version using no key derivation. It should not be confused with 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.
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.
The following checksum-type numbers are assigned or reserved. As with encryption-type numbers, some overloading of checksum numbers has occurred.
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]
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.
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.
9. Implementation Notes
9. Implementation Notes
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
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
Raeburn Standards Track [Page 32] RFC 3961 Encryption and Checksum Specifications February 2005
Raeburn Standards Track [Page 32] RFC 3961 Encryption and Checksum Specifications February 2005
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.)
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.)
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.
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.
10. Security Considerations
10. Security Considerations
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.
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 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 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 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弱いキーには、特性がその1Eあります。(E1(P))はP(1Eが主要な1がある1単滑車の暗号化を指示するところ)と等しいです。 DESの準弱いキー、または「二元的な」キーがそのE1(P)=D2(P)、およびその結果、2E特性がある組のキーです。(E1(P))はCBCモードと主な無作為の交絡因子の使用のP.Becauseと等しく、しかしながら、これらの特性は警備上の問題を提示しそうにはありません。
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暗号化を弱めるのが非常にありそうもなくなります。 それは3個のサブキーの中央に他の2の1つを合わせるよりわずかにだけありそうです--私たちが避けない努力を全くするケース。事実上、その1つは、独身のDESに暗号化を変換します。
Raeburn Standards Track [Page 33] RFC 3961 Encryption and Checksum Specifications February 2005
レイバーン標準化過程[33ページ]RFC3961暗号化とチェックサム仕様2005年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がケルベロスのために実行されたとき導入された「簡素化」(: バグを読む)が無視されるために有効に先行ゼロを引き起こすので、先行ゼロビットだけにおいて異なるメッセージは同じチェックサムを持つでしょう。
[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_ストリング_は元々、すべての入力が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]は、暗号化計画の分析が未知のキーでコード化されるために知られている平文を提出できる攻撃者のモデルを含んで、知られているプロトコルメッセージに多くのタイプの操作を実行できると示唆します。 ケルベロスバージョン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
そして、[Kerb1510]で指定された独身のDES暗号系に使用されるものなどの「非-合わせ」られたコード化されたチェックサムの使用がカットを考慮する、-、ペースト、特に交絡因子が使用されていないなら、攻撃します。 さらに、「非-合わせ」られたコード化されたチェックサムは選ばれた平文攻撃に傷つきやすいです: 暗号化神託へのアクセスの攻撃者は容易に必要な「非-合わせ」られたチェックサムをコード化できます。
Raeburn Standards Track [Page 34] RFC 3961 Encryption and Checksum Specifications February 2005
レイバーン標準化過程[34ページ]RFC3961暗号化とチェックサム仕様2005年2月
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.
平文を選びます。 [Bellovin99] これらの以下で説明される一般的な実現デザイン選択に結合した弱点はバージョン4からバージョン5までの交差しているプロトコル攻撃を考慮します。
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.
無作為の交絡因子の使用は攻撃者が暗号化神託としてプロトコル交換をうまく利用するのを防ぐ重要な手段です。 ケルベロスバージョン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.
複数の目的に同じキーを使用するのは、選ばれた平文攻撃の範囲を可能にするか、または増加させることができます。 ケルベロスプロトコルの両方のバージョン4と5を実行する何らかのソフトウェアが両方のバージョンに同じキーを使用します。 これは、バージョン4に関する暗号化神託がバージョン5を攻撃するのに使用されるのを可能にします。 この交差しているプロトコル攻撃などの攻撃への脆弱性で、複数の目的にキーを使用するのは賢明でなくなります。
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.
ケルベロスプロトコルのように、このドキュメントはキーがアルゴリズムの丈夫さかキーのサイズに基づく量まで使用されるかもしれないデータ量をアドレス制限でないのにします。 どんな定義されたアルゴリズムと主要なサイズも非常に多量のデータを支持できるくらい強くなると思われるか、または重要な攻撃がいったん知られていると、それらは非難されるでしょう。
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.
また、このドキュメントは様々な操作で扱うことができるデータ量にノーバウンドを置きます。 サービス不能攻撃を避けるために、実現はたぶん何らかのより高いレベルにおけるメッセージサイズを制限しようとするでしょう。
11. IANA Considerations
11. IANA問題
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.
数値のための2つの登録を作成してあります: ケルベロス暗号化形式数とケルベロスチェックサムは数をタイプします。 これらは-2147483648〜2147483647まで及ぶサインされた値です。 正の数は使用のためのこの仕様通りにケルベロスか関連するプロトコルで指定されたアルゴリズムのためだけに割り当てられるべきです。 負の数は私用のためのものです。 地方の、そして、実験しているアルゴリズムはこれらの値を使用するべきです。 ゼロは、予約されていて、割り当てられないかもしれません。
Positive encryption- and checksum-type numbers may be assigned following either of two policies described in [BCP26].
[BCP26]で説明された2つの方針のどちらかに続くのは積極的な暗号化とチェックサム形式数に割り当てられるかもしれません。
Standards-track specifications may be assigned values under the Standards Action policy.
標準化過程仕様はStandards Action方針の下で割り当てられた値であるかもしれません。
Raeburn Standards Track [Page 35] RFC 3961 Encryption and Checksum Specifications February 2005
レイバーン標準化過程[35ページ]RFC3961暗号化とチェックサム仕様2005年2月
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.
非標準化過程RFCsの仕様はExpert Reviewの後の割り当てられた値であるかもしれません。 非IETF仕様は、外部仕様に参照をつけるInformationalを発行するのによる割り当てられた値か標準化過程RFCであるかもしれません。 その仕様は、公共で、IETF RFCsのような何らかの永久的な記録で広めなければなりません。 必要ではありませんが、完全な仕様が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.
インターネット草稿仕様は暗号化のための値とチェックサム形式数を含むべきではありません。 代わりに、彼らは、ドキュメントが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で与えられたリストは初期の登録を作成するのに使用されました。 彼らは、他の値が信じていたのをこのドキュメントと平行した進行中の、そして、確信している仕様が既に使用中であるように予約を含んでいます。
12. Acknowledgements
12. 承認
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.
[Kerb1510]にB.クリフォード・ヌーマンとジョン・コールで仕様を含んでいて、このドキュメントは暗号化の拡大です、そして、バックグラウンド、概念、および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]の改正案に折り重ねられた1組のインターネット草稿(名前の下では、horowitzの主要な派生と草稿horowitz縁石キー派生を作成する)における主要な派生を書きました。
Raeburn Standards Track [Page 36] RFC 3961 Encryption and Checksum Specifications February 2005
レイバーン標準化過程[36ページ]RFC3961暗号化とチェックサム仕様2005年2月
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.
トム・ユーはケルベロス実現が実際にそれを使用しながら標準のCRCアルゴリズムに変更を説明するテキスト、およびSecurity Considerations部のテキストのいくつかを提供しました。
Miroslav Jurisic provided information for one of the UTF-8 test cases for the string-to-key functions.
ミロスラフJurisicはUTF-8テストケースの1つの情報をストリングから主要な機能に提供しました。
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、ルイス・ルベイ、および他のものはこのドキュメントの以前のバージョンにおけるいくつかの誤りを捕らえました。
Raeburn Standards Track [Page 37] RFC 3961 Encryption and Checksum Specifications February 2005
レイバーン標準化過程[37ページ]RFC3961暗号化とチェックサム仕様2005年2月
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ストリングです。 キーと他の2進のデータは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倍の64倍の(「012345」)=(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倍(「技術のMASSACHVSETTS INSTITVTE」)の192倍(4d41535341434856534554545320494e5354495456544520 4f4620544543484e4f4c4f4759)の=db3b0d8f0b061e603282b308a50841229ad798fab9540c1b
168-fold("Q") =
168-fold(51) =
518a54a2 15a8452a 518a54a2 15a8452a
518a54a2 15
168倍の168倍の(「Q」)=(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).
ここに、ストリング"kerberos"の折り重ねられた値に対応するいくつかの加算値があります。 64ビットのフォームはdes3のストリングからキー(セクション6.3.1)で使用されます。
Raeburn Standards Track [Page 38] RFC 3961 Encryption and Checksum Specifications February 2005
レイバーン標準化過程[38ページ]RFC3961暗号化とチェックサム仕様2005年2月
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
8372c236 344e5f15 50cd0747 e15d62ca 7a5a3bce a4の256倍の6b657262 65726f73 7b9b5b2b 93132b93の168倍の6b657262 65726f73の128倍の64倍の("kerberos")=("kerberos")=("kerberos")=("kerberos")は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_ストリング_
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_ストリング_はセクション6.2で定義されます。 私たちはここに中間結果のいくつかでいくつかの試験値を提示します。 4番目のテストは3つのキャラクタとのUTF-8の使用を示します。 最後の2つのテストがファンと同じくらい折り重なることによって生産された中間的キーのための弱く主要なfixupsの引き金となるように明確に構成されます。 私たちには、最終的なキーのためにそのようなfixupsを引き起こすテストケースが全くありません。
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 encodings: eszett U+00DF C3 9F s-caron U+0161のC5 A1のc鋭いU+0107C4 87g-音部記号U+1011E Fの0 9D84 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の中間的キー: c11f38688ac86d2f DESキー: cbc22fae235298e3
salt: "WHITEHOUSE.GOVdanny"
5748495445484f5553452e474f5664616e6e79
password: "potatoe" 706f7461746f65
fan-fold result: a028944ee63c0416
intermediate key: a129944fe63d0416
DES key: df3d32a74fd92a01
塩: "WHITEHOUSE.GOVdanny"5748495445484f5553452e474f5664616e6e79パスワード: "potatoe"706f7461746f65扇形褶曲結果: a028944ee63c0416の中間的キー: a129944fe63d0416 DESキー: 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
Raeburn Standards Track [Page 39] RFC 3961 Encryption and Checksum Specifications February 2005
レイバーン標準化過程[39ページ]RFC3961暗号化とチェックサム仕様2005年2月
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
塩: c"ATHENA.MIT.EDUJuri"+s-caron(U+0161)+「i」+鋭い(U+0107)415448454e412e4d49542e4544554a757269c5a169c487パスワード: eszett(U+00DF)c39f扇形褶曲結果: b8f6c40e305afc9eの中間的キー: b9f7c40e315bfd9e DESキー: 62c81a5232b5e69d
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扇形褶曲結果: 1e1e1e1e0e0e0e0eの中間的キー: 1f1f1f1f0e0e0efe DESキー: c4bf6b25adf7a4f8
This trace provided by Simon Josefsson shows the intermediate processing stages of one of the test inputs:
サイモンJosefssonによって提供されたこの跡はテスト入力の1つの中間的処理ステージを見せています:
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)
_キー(des-cbc-md5、ストリング、塩)に_を結んでください。 以下を結んでください。 ;; 'パスワード'(8バイトの長さ)。 70 61 73 73 77 6f72 64。 塩: ;; 'ATHENA.MIT.EDUraeburn'(21バイトの長さ)。 41 54 48 45 4e41 2e 4d49 54 2e45 44 55 72 61。 _キー(ストリング、塩)への65 62 75 72 6e des_ストリング_。 以下を結んでください。 ;; 'パスワード'(8バイトの長さ)。 70 61 73 73 77 6f72 64。 塩: ;; 'ATHENA.MIT.EDUraeburn'(21バイトの長さ)。 41 54 48 45 4e41 2e 4d49 54 2e45 44 55 72 61。 65 62 75 72 6e変な=1。 s=ストリング| 塩。 tempstring=0。 /*56ビット列の*/パッド。 8バイト境界*/へのヌルがある/*。 sはパッド(ストリング| 塩)と等しいです: ;; 'passwordATHENA.MIT.EDUraeburn\x00\x00\x00'。 (32バイトの長さ)
Raeburn Standards Track [Page 40] RFC 3961 Encryption and Checksum Specifications February 2005
レイバーン標準化過程[40ページ]RFC3961暗号化とチェックサム仕様2005年2月
;; 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
;; 70 61 73 73 77 6f72 64 41 54 48 45 4e41 2e 4d。 (sの8byteblock)のための49 54 2e45 44 55 72 61 65 62 75 72 6e00 00 00、; 輪の繰り返し0; 8byteblock: 'パスワード'(8バイトの長さ); 70 61 73 73 77 6f72 64; 01110000 01100001 01110011 01110011 01110111 01101111; 01110010 01100100 56bitstringはremoveMSBits(8byteblock)と等しいです; 56bitstring: 1110000 1100001 1110011 1110011 1110111 1101111; 1110010 1100100は(変な=0)であるなら(56bitstring)を逆にします; 変な=1変な=、変な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
(sの8byteblock)、;、繰り返し1を輪にしてください;、8byteblock:、;、'ATHENA.M'(8バイトの長さ);、41 54 48 45、4e41 2e 4d; 01000001 01010100 01001000 01000101 01001110 01000001; 00101110 01001101 56bitstringはremoveMSBits(8byteblock)と等しいです; 56bitstring; 0101110 1001101は(変な=0)であるなら(56bitstring)を逆にします。;、1000001 1010100 1001000 1000101 1001110 1000001;、; 変な=0逆(56bitstring)(1011001 0111010 1000001 0111001 1010001 0001001);;;56bitstringが後に逆にする 0010101 1000001の変な=! 変な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 2e45 44 55 72 61;、01001001 01010100 00101110 01000101 01000100 01010101
Raeburn Standards Track [Page 41] RFC 3961 Encryption and Checksum Specifications February 2005
レイバーン標準化過程[41ページ]RFC3961暗号化とチェックサム仕様2005年2月
;; 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
;; 01110010 01100001 56bitstringはremoveMSBits(8byteblock)と等しいです。 ;; 56bitstring: ;; 1001001 1010100 0101110 1000101 1000100 1010101 ;; 1110010 1100001は(変な=0)であるなら(56bitstring)を逆にします。 ;; 変な=1変な=! 変な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
(sの8byteblock)、; 輪の繰り返し3; 8byteblock: 'eburn\x00\x00\x00'(8バイトの長さ); 65 62 75 72 6e00 00 00; 01100101 01100010 01110101 01110010 01101110 00000000; 00000000 00000000 56bitstringはremoveMSBits(8byteblock)と等しいです; 56bitstring; 0000000 0000000は(変な=0)であるなら(56bitstring)を逆にします。;、1100101 1100010 1110101 1110010 1101110 0000000;、; 変な=0逆(56bitstring)(0000000 0000000 0000000 0111011 0100111 1010111);;;56bitstringが後に逆にする 0100011 1010011の変な=! 変なtempstringはtempstring XOR 56bitstringと等しいです; tempstring; 1100000 0001111 0011100 0110100 1000101 1100100、0110110 0010111
for (8byteblock in s) {
}
;; for loop terminated
(sの8byteblock)、。 終えられた輪のために
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は主要な_修正と等しいです(_同等_ビット(tempstring)を加えてください)。 ;; tempkey。 '\xc1\x1f8h\x8a\xc8m\x2f'(8バイトの長さ)。 c1 1f38 68 8a c8 6d 2f。 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)
キーは主要な_修正(DES-CBC-チェック(s、tempkey))と等しいです。 ;; キー。 '\xcb\xc2\x2f\xae\x23R\x98\xe3'(8バイトの長さ)
Raeburn Standards Track [Page 42] RFC 3961 Encryption and Checksum Specifications February 2005
レイバーン標準化過程[42ページ]RFC3961暗号化とチェックサム仕様2005年2月
;; cb c2 2f ae 23 52 98 e3
;; 11001011 11000010 00101111 10101110 00100011 01010010
;; 10011000 11100011
;; cb c2 2f ae23 52 98e3。 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
;; _主要なキーに_を結んでください: ;; '\xcb\xc2\x2f\xae\x23R\x98\xe3'(8バイトの長さ)。 cb c2 2f ae23 52 98e3
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.
これらのテストはdes3-hmac-sha1-kdのための派生している無作為の、そして、派生しているキー値の暗号化計画を示しています、機能がセクション6.3.1で定義したDRとDKを使用して。 入力キーは手当たりしだいに発生しました。 用法値はこの仕様から来ています。
key: dce06b1f64c857a11c3db57c51899b2cc1791008ce973b92 usage: 0000000155 DR: 935079d14490a75c3093c4a6e8c3b049c71e6ee705 DK: 925179d04591a79b5d3192c4a7e9c289b049c71f6ee604cd
キー: dce06b1f64c857a11c3db57c51899b2cc1791008ce973b92用法: 0000000155博士: 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博士: 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("kerberos")DR: 2270db565d2a3d64cfbfdc5305d4f778a6de42d9da DK: 2370da575d2a3da864cebfdc5204d56df779a7df43d9da43
key: c1081649ada74362e6a1459d01dfd30d67c2234c940704da usage: 0000000155 DR: 348056ec98fcc517171d2b4d7a9493af482d999175 DK: 348057ec98fdc48016161c2a4c7a943e92ae492c989175f7
キー: c1081649ada74362e6a1459d01dfd30d67c2234c940704da用法: 0000000155博士: 348056ec98fcc517171d2b4d7a9493af482d999175 DK: 348057ec98fdc48016161c2a4c7a943e92ae492c989175f7
key: 5d154af238f46713155719d55e2f1f790dd661f279a7917c usage: 00000001aa DR: a8818bc367dadacbe9a6c84627fb60c294b01215e5
キー: 5d154af238f46713155719d55e2f1f790dd661f279a7917c用法: 00000001aa DR: a8818bc367dadacbe9a6c84627fb60c294b01215e5
Raeburn Standards Track [Page 43] RFC 3961 Encryption and Checksum Specifications February 2005
レイバーン標準化過程[43ページ]RFC3961暗号化とチェックサム仕様2005年2月
DK: a8808ac267dada3dcbe9a7c84626fbc761c294b01315e5c1
DK: a8808ac267dada3dcbe9a7c84626fbc761c294b01315e5c1
key: 798562e049852f57dc8c343ba17f2ca1d97394efc8adc443 usage: 0000000155 DR: c813f88b3be2b2f75424ce9175fbc8483b88c8713a DK: c813f88a3be3b334f75425ce9175fbe3c8493b89c8703b49
キー: 798562e049852f57dc8c343ba17f2ca1d97394efc8adc443用法: 0000000155博士: 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_
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.GOVdanny"passwd: "potatoe"キー: 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
塩: c"ATHENA.MIT.EDUJuri"+s-caron(U+0161)+「i」+先の尖っている(U+0107)passwd: eszett(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
以下に、様々なASCIIと八重奏ストリングのための変更されたCRC32値があります。 印刷可能なASCII文字だけが無評価された八重奏を引きずるCスタイルなしでchecksummedされます。 32ビットはケルベロスで同じくらい中古のバイトが示される出力のCRCと系列を変更しました。 (八重奏値はそれを強調するためにここに切り離されて、それらが八重奏値であるということであり、どんな32ビットもビットとバイトオーダーが使用した数(いくつかの実現における操作のために最も便利なフォームになるもの)ではありません。
Raeburn Standards Track [Page 44] RFC 3961 Encryption and Checksum Specifications February 2005
レイバーン標準化過程[44ページ]RFC3961暗号化とチェックサム仕様2005年2月
internally for such a number is irrelevant; the octet sequence generated is what is important.)
本質的に、そのようなものに関して、数は無関係です。 系列が発生させた八重奏は重要なことです。)
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
20 83b8教育モッズ20 83b8教育モッズモッズ-crc-32("foo")=33bc32 73モッズ-crc-32("test0123456789")=d6 88 3e b8モッズ-crc-32(「技術のMASSACHVSETTS INSTITVTE」)=f7 80 41e3モッズ-crc-32(8000)=4b98 83 3bモッズ-crc-32(0008)=32 88db 0eモッズ-crc-32(0080)=crc-32(80)=crc-32(80000000)は3b b6 59教育モッズ-crc-32(00000001)=96 30 07 77と等しいです。
B. Significant Changes from RFC 1510
B。 RFC1510からの著しい変化
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]とのいくつかのメッセージ定義を初期ベクトルがアプリケーションで指定されることを許可すると読むことができました。 テキストはあいまい過ぎました。 それはこの仕様で明らかに受入れられません。 いくつかの暗号化アルゴリズムが初期化ベクトルを使用しないかもしれないので、セキュリティのために選ばれて、秘密の初期化ベクトルを当てにするのは賢明ではありません。 また、既存のアルゴリズムによるprepended交絡因子もおよそ暗号化されたフォームで明らかにされる1メッセージあたり1つの初期化ベクトルに同等です。 しかしながら、別のものへの1つの暗号化の向かいで状態を運ぶのは不透明な「暗号状態」オブジェクトを通して明らかに受入れられます。
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記述をアップデートしました。
Raeburn Standards Track [Page 45] RFC 3961 Encryption and Checksum Specifications February 2005
レイバーン標準化過程[45ページ]RFC3961暗号化とチェックサム仕様2005年2月
[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)かMessage Integrity Check(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] 一般に、ケルベロスの場合では、暗号化されたオブジェクトはASN.1DER encodingsになるでしょう。(そのDER encodingsはわずかな最初の八重奏における、それらの長さのしるしを含みます)。
[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] この書くことの時現在新しい運転モードは提案されました、同時に暗号化と保全保護を可能にするかもしれないもののいくつか。 これらの提案のいくつかを適切な分析にかけてある後に、それらの1つに基づく新しい簡易型のプロフィールを定式化するかもしれなくたいと思います。
[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、およびSchemeのビル・ゾンマーフェルトによる別のもの)からの2つの独立している実装が[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] 例えば、MITの[Kerb1510]の実装では、アプリケーションデータのrsa-md5 unkeyedチェックサムはサービスのキーで暗号化された固有識別文字に含まれるかもしれません。
[7] Using a variant of the key limits the use of a key to a
particular function, separating the functions of generating a
[7] キーの異形を使用すると、キーの使用は特定の機能に制限されます、aを生成する機能を切り離して
Raeburn Standards Track [Page 46] RFC 3961 Encryption and Checksum Specifications February 2005
レイバーン標準化過程[46ページ]RFC3961暗号化とチェックサム仕様2005年2月
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.
他の暗号化からのチェックサムは、セッションキーを使用することで働きました。 主要な同等を維持するので、一定の0xF0F0F0F0F0F0F0F0は選ばれました。 DESの特性は補数の使用を排除しました。 同じ定数はPrivacy Enhancedメール規格におけるMessage Integrity Checkの同様の目的に使用されます。
[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] 恐らく直接暗号化を実行して、交渉と、そして、選んだaへの直轄が「十分強い」という暗号化アルゴリズム(それが当然のことのアプリケーションの文脈で意味することなら何でも)の、より一般的な理由の1つ。 ケルベロスはアプリケーションクライアントとサーバの間で直接どんなダイレクト施設も暗号化タイプを交渉するのに提供しませんが、同様の目標を達成する他の手段があります(例えば、「強い」セッションキーだけを要求するのが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.
[BCP26]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[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] Bellare、M.、デセイ、A.、Pointcheval、D.、およびP.Rogaway、「公開鍵暗号化体系のためのセキュリティの概念の中の関係。」 拡張要約は中でCryptology-暗号98ProceedingsのAdvances、コンピュータScience Vol.1462(H.Krawcyzk教育)におけるLecture Notesを発行しました。Springer-Verlag、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のような暗号のための、より良い主要なスケジュール」、PRAGOCRYPT1996 96年の議事。
[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.
「ISO情報処理システム--データ通信--ハイレベル・データリンク制御手順--枠組構造」という[CRC]国際標準化機構は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、ワシントン、連邦政府の情報処理規格DC1977。
Raeburn Standards Track [Page 47] RFC 3961 Encryption and Checksum Specifications February 2005
レイバーン標準化過程[47ページ]RFC3961暗号化とチェックサム仕様2005年2月
[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]規格基準局、米国商務省、「NBS Data Encryption Standardを実装して、使用するためのガイドライン」、連邦政府の情報Processing Standards Publication74、ワシントン(DC)1981。
[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、スプリングフィールド(ヴァージニア)12月1980番目
[Dolev91] Dolev, D., Dwork, C., and M. Naor, "Non-malleable
cryptography", Proceedings of the 23rd Annual
Symposium on Theory of Computing, ACM, 1991.
Computing、ACM、1991年のTheoryの上の[Dolev91]DolevとD.とDwork、C.とM.Naor、「非可鍛性の暗号」、第23Annual SymposiumのProceedings。
[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
Keyed-Hashing for Message Authentication", RFC 2104,
February 1997.
[HMAC] Krawczyk、H.、Bellare、M.、およびR.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年2月。
[KRB5-AES] Raeburn, K., "Advanced Encryption Standard (AES)
Encryption for Kerberos 5", RFC 3962, February 2005.
[KRB5-AES]レイバーン(K.)は「2005年2月にケルベロス5インチ、RFC3962のために暗号化の標準の(AES)暗号化を進めました」。
[MD4-92] Rivest, R., "The MD4 Message-Digest Algorithm", RFC
1320, April 1992.
[MD4-92] Rivest、R.、「MD4メッセージダイジェストアルゴリズム」、RFC1320、1992年4月。
[MD5-92] Rivest, R., "The MD5 Message-Digest Algorithm ", RFC
1321, April 1992.
[MD5-92] Rivest、R.、「MD5メッセージダイジェストアルゴリズム」、RFC1321、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.
[SG92] セキュリティとプライバシーにおける研究、オークランド、カリフォルニアにおけるIEEEシンポジウムの議事における「暗号のプロトコルのメッセージの保全」というStubblebine、S.、およびV.D.グリゴルは1992がそうするかもしれません。
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.メリット、1991年冬のUsenixセキュリティコンファレンス(1991年1月)の議事における「ケルベロス認証システムの限界。」
[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.
[効率-DES] 電子フロンティア財団、「分解DES:」 「暗号化研究、盗聴政治、およびチップデザインのシークレット」、オライリー、および仲間Inc.、5月1998日
[ESP-DES] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher
Algorithm With Explicit IV", RFC 2405, November 1998.
[超能力-DES] マドソンとC.とN.Doraswamy、「明白なIVがある超能力DES-CBC暗号アルゴリズム」、RFC2405、1998年11月。
Raeburn Standards Track [Page 48] RFC 3961 Encryption and Checksum Specifications February 2005
レイバーン標準化過程[48ページ]RFC3961暗号化とチェックサム仕様2005年2月
[GSS-KRB5] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
RFC 1964, June 1996.
[GSS-KRB5] リン、J.、「ケルベロスバージョン5GSS-APIメカニズム」、RFC1964、1996年6月。
[HMAC-TEST] Cheng, P. and R. Glenn, "Test Cases for HMAC-MD5 and
HMAC-SHA-1", RFC 2202, September 1997.
[HMAC-テスト] チェンとP.とR.グレンと「HMAC-MD5のためのテストケースとHMAC-SHA-1インチ、RFC2202、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] マドソン、C.、およびR.グレン、「超能力の中のHMAC-SHA-1-96の使用、ああ、」、RFC2404、11月1998日
[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)」、RFC1510 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.Rivest、「RC5、RC5-CBC、RC5- CBC-パッド、およびRC5-CTSアルゴリズム」RFC2040、10月1996日
[RFC1851] Karn, P., Metzger, P., and W. Simpson, "The ESP Triple
DES Transform", RFC 1851, September 1995.
[RFC1851] KarnとP.とメッツガー、P.とW.シンプソン、「超能力の三重のDESは変形する」RFC1851、1995年9月。
[Schneier96] Schneier, B., "Applied Cryptography Second Edition",
John Wiley & Sons, New York, NY, 1996. ISBN 0-471-
12845-7.
[Schneier96]シュナイアー、B.、「適用された暗号第2版」、ジョン・ワイリー、および息子、ニューヨーク(ニューヨーク)1996。 ISBN0-471- 12845-7。
Editor's Address
エディタのアドレス
Kenneth Raeburn Massachusetts Institute of Technology 77 Massachusetts Avenue Cambridge, MA 02139
マサチューセッツ通りケンブリッジ、ケネスレイバーンマサチューセッツ工科大学77MA 02139
EMail: raeburn@mit.edu
メール: raeburn@mit.edu
Raeburn Standards Track [Page 49] RFC 3961 Encryption and Checksum Specifications February 2005
レイバーン標準化過程[49ページ]RFC3961暗号化とチェックサム仕様2005年2月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でIETF Documentsの権利に関するIETFの手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Raeburn Standards Track [Page 50]
レイバーン標準化過程[50ページ]
一覧
スポンサーリンク
