Network Working Group K. Raeburn
Request for Comments: 3961 MIT
Category: Standards Track February 2005
Network Working Group K. Raeburn
Request for Comments: 3961 MIT
Category: Standards Track February 2005
Encryption and Checksum Specifications for Kerberos 5
Kerberos 5的加密和校验和规范
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This document describes a framework for defining encryption and checksum mechanisms for use with the Kerberos protocol, defining an abstraction layer between the Kerberos protocol and related protocols, and the actual mechanisms themselves. The document also defines several mechanisms. Some are taken from RFC 1510, modified in form to fit this new framework and occasionally modified in content when the old specification was incorrect. New mechanisms are presented here as well. This document does NOT indicate which mechanisms may be considered "required to implement".
本文档描述了一个框架，用于定义用于Kerberos协议的加密和校验和机制，定义Kerberos协议和相关协议之间的抽象层，以及实际机制本身。该文件还定义了若干机制。有些来自RFC 1510，在形式上进行了修改以适应新框架，并且在旧规范不正确时偶尔在内容上进行了修改。这里也介绍了新的机制。本文件没有说明哪些机制可能被视为“需要实施”。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Encryption Algorithm Profile . . . . . . . . . . . . . . . . 4
4. Checksum Algorithm Profile . . . . . . . . . . . . . . . . . 9
5. Simplified Profile for CBC Ciphers with Key Derivation . . . 10
5.1. A Key Derivation Function . . . . . . . . . . . . . . . 10
5.2. Simplified Profile Parameters . . . . . . . . . . . . . 12
5.3. Cryptosystem Profile Based on Simplified Profile . . . 13
5.4. Checksum Profiles Based on Simplified Profile . . . . . 16
6. Profiles for Kerberos Encryption and Checksum Algorithms . . 16
6.1. Unkeyed Checksums . . . . . . . . . . . . . . . . . . . 17
6.2. DES-based Encryption and Checksum Types . . . . . . . . 18
6.3. Triple-DES Based Encryption and Checksum Types . . . . 28
7. Use of Kerberos Encryption Outside This Specification . . . . 30
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Encryption Algorithm Profile . . . . . . . . . . . . . . . . 4
4. Checksum Algorithm Profile . . . . . . . . . . . . . . . . . 9
5. Simplified Profile for CBC Ciphers with Key Derivation . . . 10
5.1. A Key Derivation Function . . . . . . . . . . . . . . . 10
5.2. Simplified Profile Parameters . . . . . . . . . . . . . 12
5.3. Cryptosystem Profile Based on Simplified Profile . . . 13
5.4. Checksum Profiles Based on Simplified Profile . . . . . 16
6. Profiles for Kerberos Encryption and Checksum Algorithms . . 16
6.1. Unkeyed Checksums . . . . . . . . . . . . . . . . . . . 17
6.2. DES-based Encryption and Checksum Types . . . . . . . . 18
6.3. Triple-DES Based Encryption and Checksum Types . . . . 28
7. Use of Kerberos Encryption Outside This Specification . . . . 30
8. Assigned Numbers . . . . . . . . . . . . . . . . . . . . . . 31
9. Implementation Notes . . . . . . . . . . . . . . . . . . . . 32
10. Security Considerations . . . . . . . . . . . . . . . . . . . 33
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
12. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 36
A. Test vectors . . . . . . . . . . . . . . . . . . . . . . . . 38
A.1. n-fold . . . . . . . . . . . . . . . . . . . . . . . . 38
A.2. mit_des_string_to_key . . . . . . . . . . . . . . . . . 39
A.3. DES3 DR and DK . . . . . . . . . . . . . . . . . . . . 43
A.4. DES3string_to_key . . . . . . . . . . . . . . . . . . . 44
A.5. Modified CRC-32 . . . . . . . . . . . . . . . . . . . . 44
B. Significant Changes from RFC 1510 . . . . . . . . . . . . . . 45
Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Normative References. . . . . . . . . . . . . . . . . . . . . . . 47
Informative References. . . . . . . . . . . . . . . . . . . . . . 48
Editor's Address. . . . . . . . . . . . . . . . . . . . . . . . . 49
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 50
8. Assigned Numbers . . . . . . . . . . . . . . . . . . . . . . 31
9. Implementation Notes . . . . . . . . . . . . . . . . . . . . 32
10. Security Considerations . . . . . . . . . . . . . . . . . . . 33
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
12. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 36
A. Test vectors . . . . . . . . . . . . . . . . . . . . . . . . 38
A.1. n-fold . . . . . . . . . . . . . . . . . . . . . . . . 38
A.2. mit_des_string_to_key . . . . . . . . . . . . . . . . . 39
A.3. DES3 DR and DK . . . . . . . . . . . . . . . . . . . . 43
A.4. DES3string_to_key . . . . . . . . . . . . . . . . . . . 44
A.5. Modified CRC-32 . . . . . . . . . . . . . . . . . . . . 44
B. Significant Changes from RFC 1510 . . . . . . . . . . . . . . 45
Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Normative References. . . . . . . . . . . . . . . . . . . . . . . 47
Informative References. . . . . . . . . . . . . . . . . . . . . . 48
Editor's Address. . . . . . . . . . . . . . . . . . . . . . . . . 49
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 50
The Kerberos protocols [Kerb] are designed to encrypt messages of arbitrary sizes, using block encryption ciphers or, less commonly, stream encryption ciphers. Encryption is used to prove the identities of the network entities participating in message exchanges. However, nothing in the Kerberos protocol requires that any specific encryption algorithm be used, as long as the algorithm includes certain operations.
Kerberos协议[Kerb]设计用于使用块加密密码或流加密密码（不太常见）对任意大小的消息进行加密。加密用于证明参与消息交换的网络实体的身份。但是，Kerberos协议中的任何内容都不要求使用任何特定的加密算法，只要该算法包含某些操作。
The following sections specify the encryption and checksum mechanisms currently defined for Kerberos, as well as a framework for defining future mechanisms. The encoding, chaining, padding, and other requirements for each are described. Appendix A gives test vectors for several functions.
以下各节指定了当前为Kerberos定义的加密和校验和机制，以及定义未来机制的框架。分别描述了编码、链接、填充和其他要求。附录A给出了几种功能的测试向量。
Both encryption and checksum mechanisms are profiled in later sections. Each profile specifies a collection of operations and attributes that must be defined for a mechanism. A Kerberos encryption or checksum mechanism specification is not complete if it does not define all of these operations and attributes.
加密和校验和机制将在后面的章节中介绍。每个概要文件指定必须为机制定义的操作和属性的集合。如果Kerberos加密或校验和机制规范没有定义所有这些操作和属性，则它是不完整的。
An encryption mechanism must provide for confidentiality and integrity of the original plaintext. (Incorporating a checksum may permit integrity checking, if the encryption mode does not provide an integrity check itself.) It must also provide non-malleability
加密机制必须保证原始明文的机密性和完整性。（如果加密模式本身不提供完整性检查，则合并校验和可能允许完整性检查。）它还必须提供非延展性
[Bellare98] [Dolev91]. Use of a random confounder prepended to the plaintext is recommended. It should not be possible to determine if two ciphertexts correspond to the same plaintext without the key.
[Bellare98][Dolev91]。建议使用明文前的随机混杂因子。如果没有密钥，则不可能确定两个密文是否对应于同一明文。
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]必须提供相关消息完整性的证明，并且必须在消息未以明文形式发送时保持消息的机密性。查找具有相同校验和的两个明文应该是不可行的。不要求窃听者无法确定两个校验和是否用于同一消息，因为消息本身可能对任何此类窃听者可见。
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.
由于密码学的进步，一些密码者认为使用同一密钥用于多个目的是不明智的。由于密钥用于在Kerberos中执行许多不同的功能，因此希望为每一个目的使用不同的密钥，即使我们从单个长期密钥或会话密钥开始。
We do this by enumerating the different uses of keys within Kerberos and by making the "usage number" an input to the encryption or checksum mechanisms; such enumeration is outside the scope of this document. Later sections define simplified profile templates for encryption and checksum mechanisms that use a key derivation function applied to a CBC mode (or similar) cipher and a checksum or hash algorithm.
我们通过列举Kerberos中密钥的不同用法，并将“用法号”作为加密或校验和机制的输入来实现这一点；此类列举不在本文件范围内。后面的章节将定义加密和校验和机制的简化配置文件模板，这些机制使用应用于CBC模式（或类似）密码和校验和或哈希算法的密钥派生函数。
We distinguish the "base key" specified by other documents from the "specific key" for a specific encryption or checksum operation. It is expected but not required that the specific key be one or more separate keys derived from the original protocol key and the key usage number. The specific key should not be explicitly referenced outside of this document. The typical language used in other documents should be something like, "encrypt this octet string using this key and this usage number"; generation of the specific key and cipher state (described in the next section) are implicit. The creation of a new cipher-state object, or the re-use of one from a previous encryption operation, may also be explicit.
我们将其他文档指定的“基本密钥”与特定加密或校验和操作的“特定密钥”区分开来。预期但不要求特定密钥是从原始协议密钥和密钥使用编号派生的一个或多个单独密钥。不应在本文档之外明确引用特定密钥。其他文档中使用的典型语言应该是“使用此密钥和使用编号加密此八位字节字符串”；特定密钥和密码状态（将在下一节中描述）的生成是隐式的。创建新的密码状态对象，或重复使用以前的加密操作中的密码状态对象，也可能是显式的。
New protocols defined in terms of the Kerberos encryption and checksum types should use their own key usage values. Key usages are unsigned 32-bit integers; zero is not permitted.
根据Kerberos加密和校验和类型定义的新协议应该使用它们自己的密钥使用值。密钥用法是无符号32位整数；零是不允许的。
All data is assumed to be in the form of strings of octets or eight-bit bytes. Environments with other byte sizes will have to emulate this behavior in order to get correct results.
假设所有数据都是八位字节字符串或八位字节。具有其他字节大小的环境必须模拟此行为才能获得正确的结果。
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”）或校验和类型编号，以便在Kerberos协议中识别算法。第8节给出了当前类型编号分配的完整列表。
An encryption mechanism profile must define the following attributes and operations. The operations must be defined as functions in the mathematical sense. No additional or implicit inputs (such as Kerberos principal names or message sequence numbers) are permitted.
加密机制配置文件必须定义以下属性和操作。操作必须定义为数学意义上的函数。不允许额外或隐式输入（如Kerberos主体名称或消息序列号）。
protocol key format This describes which octet string values represent valid keys. For encryption mechanisms that don't have perfectly dense key spaces, this will describe the representation used for encoding keys. It need not describe invalid specific values; all key generation routines should avoid such values.
协议密钥格式描述哪些八位字节字符串值表示有效密钥。对于没有完全密集密钥空间的加密机制，这将描述用于编码密钥的表示。它不需要描述无效的特定值；所有密钥生成例程都应避免此类值。
specific key structure This is not a protocol format at all, but a description of the keying material derived from the chosen key and used to encrypt or decrypt data or compute or verify a checksum. It may, for example, be a single key, a set of keys, or a combination of the original key with additional data. The authors recommend using one or more keys derived from the original key via one-way key derivation functions.
特定密钥结构这根本不是协议格式，而是从所选密钥派生的密钥材料的描述，用于加密或解密数据或计算或验证校验和。例如，它可以是单个键、一组键或原始键与附加数据的组合。作者建议通过单向密钥派生函数使用从原始密钥派生的一个或多个密钥。
required checksum mechanism This indicates a checksum mechanism that must be available when this encryption mechanism is used. Since Kerberos has no built in mechanism for negotiating checksum mechanisms, once an encryption mechanism is decided, the corresponding checksum mechanism can be used.
必需的校验和机制这表示使用此加密机制时必须可用的校验和机制。由于Kerberos没有用于协商校验和机制的内置机制，因此一旦确定了加密机制，就可以使用相应的校验和机制。
key-generation seed length, K This is the length of the random bitstring needed to generate a key with the encryption scheme's random-to-key function (described below). This must be a fixed value so that various techniques for producing a random bitstring of a given length may be used with key generation functions.
密钥生成种子长度，K这是使用加密方案的随机到密钥函数（如下所述）生成密钥所需的随机位字符串的长度。这必须是一个固定值，以便用于生成给定长度的随机位字符串的各种技术可以与密钥生成函数一起使用。
key generation functions Keys must be generated in a number of cases, from different types of inputs. All function specifications must indicate how to generate keys in the proper wire format and must avoid generating keys that significantly compromise the confidentiality of encrypted data, if the cryptosystem has such. Entropy from each
密钥生成功能在许多情况下，必须从不同类型的输入生成密钥。所有功能规范必须指明如何以适当的有线格式生成密钥，并且必须避免生成严重危害加密数据机密性的密钥（如果密码系统具有此类密钥）。熵从每个
source should be preserved as much as possible. Many of the inputs, although unknown, may be at least partly predictable (e.g., a password string is likely to be entirely in the ASCII subset and of fairly short length in many environments; a semi-random string may include time stamps). The benefit of such predictability to an attacker must be minimized.
应尽可能多地保留原始资料。许多输入虽然未知，但至少可以部分预测（例如，密码字符串可能完全在ASCII子集中，在许多环境中长度相当短；半随机字符串可能包括时间戳）。这种可预测性对攻击者的好处必须最小化。
string-to-key (UTF-8 string, UTF-8 string, opaque)->(protocol-key) This function generates a key from two UTF-8 strings and an opaque octet string. One of the strings is usually the principal's pass phrase, but generally it is merely a secret string. The other string is a "salt" string intended to produce different keys from the same password for different users or realms. Although the strings provided will use UTF-8 encoding, no specific version of Unicode should be assumed; all valid UTF-8 strings should be allowed. Strings provided in other encodings MUST first be converted to UTF-8 before applying this function.
字符串到密钥（UTF-8字符串，UTF-8字符串，不透明）->（协议密钥）此函数从两个UTF-8字符串和一个不透明八位字节字符串生成密钥。其中一个字符串通常是主体的通行短语，但通常它只是一个秘密字符串。另一个字符串是“salt”字符串，用于为不同的用户或领域从同一密码生成不同的密钥。尽管提供的字符串将使用UTF-8编码，但不应假定Unicode的特定版本；应允许所有有效的UTF-8字符串。在应用此函数之前，必须先将其他编码中提供的字符串转换为UTF-8。
The third argument, the octet string, may be used to pass mechanism-specific parameters into this function. Since doing so implies knowledge of the specific encryption system, generating non-default parameter values should be an uncommon operation, and normal Kerberos applications should be able to treat this parameter block as an opaque object supplied by the Key Distribution Center or defaulted to some mechanism-specific constant value.
第三个参数是八位字节字符串，可用于将特定于机制的参数传递到此函数中。由于这样做意味着了解特定的加密系统，因此生成非默认参数值应该是一种不常见的操作，并且正常的Kerberos应用程序应该能够将此参数块视为密钥分发中心提供的不透明对象，或者默认为某个机制特定的常量值。
The string-to-key function should be a one-way function so that compromising a user's key in one realm does not compromise it in another, even if the same password (but a different salt) is used.
string-to-key函数应该是一个单向函数，这样即使使用相同的密码（但不同的salt），在一个域中泄露用户的密钥也不会在另一个域中泄露用户的密钥。
random-to-key (bitstring[K])->(protocol-key) This function generates a key from a random bitstring of a specific size. All the bits of the input string are assumed to be equally random, even though the entropy present in the random source may be limited.
随机密钥（位字符串[K]）->（协议密钥）此函数从特定大小的随机位字符串生成密钥。假设输入字符串的所有位都是相同的随机位，即使随机源中存在的熵可能是有限的。
key-derivation (protocol-key, integer)->(specific-key) In this function, the integer input is the key usage value, as described above. An attacker is assumed to know the usage values. The specific-key output value was described in section 2.
密钥派生（协议密钥，整数）->（特定密钥）在该函数中，整数输入是密钥使用值，如上所述。假定攻击者知道使用值。第2节描述了具体的键输出值。
string-to-key parameter format This describes the format of the block of data that can be passed to the string-to-key function above to configure additional parameters for that function. Along with the mechanism of encoding parameter values, bounds on the allowed parameters should also be described to avoid allowing a spoofed KDC to compromise
字符串到键参数格式这描述了可以传递到上面的字符串到键函数的数据块的格式，以便为该函数配置其他参数。除了对参数值进行编码的机制外，还应描述允许参数的边界，以避免伪造KDC造成危害
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.
default string to key parameters（八位字节字符串）当应用程序协议（Kerberos或其他）未显式设置参数值时，应使用string to key函数的“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.
密码状态描述任何可以从一个加密或解密操作转移到下一个加密或解密操作的信息，以便与给定的特定密钥一起使用。例如，在CBC模式中使用的分组密码可将一个块的初始向量置于密码状态。其他加密模式可以跟踪nonce或其他数据。
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.
如果密码状态从一个加密转移到下一个加密，则此状态必须为非空，并且必须影响加密，以便消息按加密顺序解密。不需要将无序或丢失的消息与损坏的消息区分开来。如果需要，这可以在更高的级别上完成，包括序列号，而不是在加密操作之间“链接”密码状态。
The cipher state may not be reused in multiple encryption or decryption operations. These operations all generate a new cipher state that may be used for following operations using the same key and operation.
密码状态不能在多次加密或解密操作中重复使用。这些操作都会生成一个新的密码状态，该状态可用于使用相同密钥和操作的后续操作。
The contents of the cipher state must be treated as opaque outside of encryption system specifications.
密码状态的内容必须在加密系统规范之外视为不透明。
initial cipher state (specific-key, direction)->(state) This describes the generation of the initial value for the cipher state if it is not being carried over from a previous encryption or decryption operation.
初始密码状态（特定密钥，方向）->（状态）这描述了如果密码状态不是从以前的加密或解密操作继承过来的，则生成密码状态的初始值。
This describes any initial state setup needed before encrypting arbitrary amounts of data with a given specific key. The specific key and the direction of operations to be performed (encrypt versus decrypt) must be the only input needed for this initialization.
这描述了在使用给定的特定密钥加密任意数量的数据之前所需的任何初始状态设置。特定密钥和要执行的操作方向（加密与解密）必须是此初始化所需的唯一输入。
This state should be treated as opaque in any uses outside of an encryption algorithm definition.
在加密算法定义之外的任何用途中，此状态都应视为不透明。
IMPLEMENTATION NOTE: [Kerb1510] was vague on whether and to what degree an application protocol could exercise control over the initial vector used in DES CBC operations. Some existing implementations permit setting the initial vector. This framework does not provide for application control of the cipher state (beyond "initialize" and "carry over from previous encryption"), as the form and content of the initial cipher state can vary between encryption systems and may not always be a single block of random data.
实施说明：[Kerb1510]对于应用程序协议是否以及在多大程度上可以对DES CBC操作中使用的初始向量进行控制的问题含糊不清。一些现有的实现允许设置初始向量。此框架不提供密码状态的应用程序控制（除了“初始化”和“从以前的加密结转”），因为初始密码状态的形式和内容在不同的加密系统之间可能会有所不同，并且可能并不总是一个随机数据块。
New Kerberos application protocols should not assume control over the initial vector, or that one even exists. However, a general-purpose implementation may wish to provide the capability, in case applications explicitly setting it are encountered.
新的Kerberos应用程序协议不应假定对初始向量的控制，甚至不应假定存在初始向量。但是，通用实现可能希望在遇到显式设置该功能的应用程序时提供该功能。
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或校验和。应包括一些随机因素，如混杂因素，以便观察者无法知道两条消息是否包含相同的明文，即使密码状态和特定密钥相同。无需对明文的确切长度进行编码，但如果不进行编码且需要填充，则必须在字符串的末尾添加填充，以便可以从开头解析解密的版本。
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].
加密函数的规范不仅必须指示输出八位字节字符串的精确内容，还必须指示输出密码状态。应用协议可以将输出密码状态从具有给定特定密钥的一种加密转发到另一种加密；必须定义这种“链接”的效果[2]。
Assuming that values for the specific key and cipher state are correctly-produced, no input octet string may result in an error indication.
假设正确生成了特定密钥和密码状态的值，则没有输入八位字节字符串可能导致错误指示。
decrypt (specific-key, state, octet string)->(state, octet string) This function takes the specific key, cipher state, and ciphertext as inputs and verifies the integrity of the supplied ciphertext. If the ciphertext's integrity is intact, this function produces the plaintext and a new cipher state as outputs; otherwise, an error indication must be returned, and the data discarded.
解密（特定密钥、状态、八位字符串）->（状态、八位字符串）此函数将特定密钥、密码状态和密文作为输入，并验证所提供密文的完整性。如果密文的完整性完好无损，此函数将生成明文和新的密码状态作为输出；否则，必须返回错误指示，并丢弃数据。
The result of the decryption may be longer than the original plaintext, as, for example, when the encryption mode adds padding to reach a multiple of a block size. If this is the case, any extra octets must come after the decoded plaintext. An application protocol that needs to know the exact length of the message must encode a length or recognizable "end of message" marker within the plaintext [3].
解密的结果可能比原始明文长，例如，当加密模式添加填充以达到块大小的倍数时。如果是这种情况，任何额外的八位字节都必须位于解码的明文之后。需要知道消息确切长度的应用程序协议必须在明文中编码长度或可识别的“消息结束”标记[3]。
As with the encryption function, a correct specification for this function must indicate not only the contents of the output octet string, but also the resulting cipher state.
与加密函数一样，此函数的正确规范不仅必须指示输出八位字节字符串的内容，而且还必须指示生成的密码状态。
pseudo-random (protocol-key, octet-string)->(octet-string) This pseudo-random function should generate an octet string of some size that is independent of the octet string input. The PRF output string should be suitable for use in key generation, even if the octet string input is public. It should not reveal the input key, even if the output is made public.
伪随机（协议密钥，八位字节字符串）->（八位字节字符串）此伪随机函数应生成大小与八位字节字符串输入无关的八位字节字符串。PRF输出字符串应适合用于密钥生成，即使八位字节字符串输入是公共的。它不应该显示输入键，即使输出是公开的。
These operations and attributes are all that is required to support Kerberos and various proposed preauthentication schemes.
这些操作和属性是支持Kerberos和各种建议的预身份验证方案所需的全部。
For convenience of certain application protocols that may wish to use the encryption profile, we add the constraint that, for any given plaintext input size, a message size must exist between that given size and that size plus 65,535 such that the length of the decrypted version of the ciphertext will never have extra octets at the end.
为了方便可能希望使用加密配置文件的某些应用程序协议，我们添加了一个约束，即对于任何给定的明文输入大小，消息大小必须在该给定大小和该大小加上65535之间，这样解密版本的密文的长度将永远不会有额外的八位字节。
Expressed mathematically, for every message length L1, there exists a message size L2 such that
用数学方法表示，对于每个消息长度L1，存在一个消息大小L2，以便
L2 >= L1
L2 < L1 + 65,536
for every message M with |M| = L2, decrypt(encrypt(M)) = M
L2 >= L1
L2 < L1 + 65,536
for every message M with |M| = L2, decrypt(encrypt(M)) = M
A document defining a new encryption type should also describe known weaknesses or attacks, so that its security may be fairly assessed, and should include test vectors or other validation procedures for the operations defined. Specific references to information that is readily available elsewhere are sufficient.
定义新加密类型的文档还应描述已知的弱点或攻击，以便公平评估其安全性，并应包括测试向量或定义的操作的其他验证程序。对其他地方可随时获得的信息的具体参考就足够了。
A checksum mechanism profile must define the following attributes and operations:
校验和机制配置文件必须定义以下属性和操作：
associated encryption algorithm(s) This indicates the types of encryption keys this checksum mechanism can be used with.
关联加密算法这表示此校验和机制可用于的加密密钥类型。
A keyed checksum mechanism may have more than one associated encryption algorithm if they share the same wire-key format, string-to-key function, default string-to-key-parameters, and key derivation function. (This combination means that, for example, a checksum type, key usage value, and password are adequate to get the specific key used to compute a checksum.)
如果密钥校验和机制共享相同的有线密钥格式、字符串到密钥函数、默认字符串到密钥参数和密钥派生函数，则它们可能具有多个关联的加密算法。（这种组合意味着，例如，校验和类型、密钥使用值和密码足以获取用于计算校验和的特定密钥。）
An unkeyed checksum mechanism can be used with any encryption type, as the key is ignored, but its use must be limited to cases where the checksum itself is protected, to avoid trivial attacks.
由于密钥被忽略，未加密校验和机制可用于任何加密类型，但其使用必须限于校验和本身受到保护的情况，以避免普通攻击。
get_mic function This function generates a MIC token for a given specific key (see section 3) and message (represented as an octet string) that may be used to verify the integrity of the associated message. This function is not required to return the same deterministic result for each use; it need only generate a token that the verify_mic routine can check.
get_mic function此函数为给定的特定密钥（参见第3节）和消息（表示为八位字节字符串）生成mic令牌，可用于验证相关消息的完整性。对于每次使用，此函数不需要返回相同的确定性结果；它只需要生成验证mic例程可以检查的令牌。
The output of this function will also dictate the size of the checksum. It must be no larger than 65,535 octets.
此函数的输出还将指示校验和的大小。它不能大于65535个八位字节。
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.
验证\u mic功能给定特定密钥、消息和mic令牌，此功能确定消息完整性是否已受损。对于确定性get_mic例程，相应的verify_mic可以简单地生成另一个校验和并比较这两个校验和。
The get_mic and verify_mic operations must allow inputs of arbitrary length; if any padding is needed, the padding scheme must be specified as part of these functions.
“获取麦克风”和“验证麦克风”操作必须允许任意长度的输入；如果需要任何填充，则必须将填充方案指定为这些函数的一部分。
These operations and attributes are all that should be required to support Kerberos and various proposed preauthentication schemes.
这些操作和属性是支持Kerberos和各种建议的预身份验证方案所需的全部。
As with encryption mechanism definition documents, documents defining new checksum mechanisms should indicate validation processes and known weaknesses.
与加密机制定义文档一样，定义新校验和机制的文档应该指出验证过程和已知的弱点。
The profile outlined in sections 3 and 4 describes a large number of operations that must be defined for encryption and checksum algorithms to be used with Kerberos. Here we describe a simpler profile that can generate both encryption and checksum mechanism definitions, filling in uses of key derivation in appropriate places, providing integrity protection, and defining multiple operations for the cryptosystem profile based on a smaller set of operations. Not all of the existing cryptosystems for Kerberos fit into this simplified profile, but we recommend that future cryptosystems use it or something based on it [4].
第3节和第4节中概述的概要文件描述了大量必须定义的操作，以便与Kerberos一起使用加密和校验和算法。这里我们描述了一个更简单的概要文件，它可以生成加密和校验和机制定义，在适当的位置填充密钥派生的使用，提供完整性保护，并基于一组较小的操作为密码系统概要文件定义多个操作。并不是所有现有的Kerberos密码系统都适合这个简化的配置文件，但我们建议未来的密码系统使用它或基于它的东西[4]。
Not all the operations in the complete profiles are defined through this mechanism; several must still be defined for each new algorithm pair.
并非完整概要文件中的所有操作都是通过此机制定义的；对于每个新的算法对，仍必须定义几个。
Rather than define some scheme by which a "protocol key" is composed of a large number of encryption keys, we use keys derived from a base key to perform cryptographic operations. The base key must be used only for generating the derived keys, and this derivation must be non-invertible and entropy preserving. Given these restrictions, compromise of one derived key does not compromise others. Attack of the base key is limited, as it is only used for derivation and is not exposed to any user data.
我们使用从基密钥派生的密钥来执行加密操作，而不是定义由大量加密密钥组成的“协议密钥”的方案。基密钥必须仅用于生成派生密钥，并且该派生必须是不可逆的和熵保持的。鉴于这些限制，一个派生密钥的折衷不会折衷其他密钥。对基密钥的攻击是有限的，因为它只用于派生，不暴露于任何用户数据。
To generate a derived key from a base key, we generate a pseudorandom octet string by using an algorithm DR, described below, and generate a key from that octet string by using a function dependent on the encryption algorithm. The input length needed for that function, which is also dependent on the encryption algorithm, dictates the length of the string to be generated by the DR algorithm (the value "k" below). These procedures are based on the key derivation in [Blumenthal96].
为了从基本密钥生成派生密钥，我们使用下面描述的算法DR生成伪随机八位字节字符串，并使用依赖于加密算法的函数从该八位字节字符串生成密钥。该函数所需的输入长度（也取决于加密算法）决定了由DR算法生成的字符串的长度（下面的值“k”）。这些程序基于[Blumenthal96]中的密钥推导。
Derived Key = DK(Base Key, Well-Known Constant)
派生键=DK（基键，已知常数）
DK(Key, Constant) = random-to-key(DR(Key, Constant))
DK(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
这里DR是下面描述的随机八位组生成函数，DK是由此生成的关键派生函数。在这种结构中，E（密钥、明文、密文状态）是一种密码，常数是一个众所周知的常数，它是由该密码的具体用法决定的
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.
函数，k-truncate通过获取前k位来截断其参数。这里，k是加密系统所需的密钥生成种子长度。
The output of the DR function is a string of bits; the actual key is produced by applying the cryptosystem's random-to-key operation on this bitstring.
DR函数的输出是一串位；实际密钥是通过在此位字符串上应用密码系统的随机密钥操作生成的。
If the Constant is smaller than the cipher block size of E, then it must be expanded with n-fold() so it can be encrypted. If the output of E is shorter than k bits, it is fed back into the encryption as many times as necessary. The construct is as follows (where | indicates concatentation):
如果该常数小于密码块大小E，则必须使用n-fold（）对其进行扩展，以便对其进行加密。如果E的输出短于k位，则根据需要多次反馈到加密中。构造如下（其中|表示凹面）：
K1 = E(Key, n-fold(Constant), initial-cipher-state) K2 = E(Key, K1, initial-cipher-state) K3 = E(Key, K2, initial-cipher-state) K4 = ...
K1=E（密钥，n倍（常数），初始密码状态）K2=E（密钥，K1，初始密码状态）K3=E（密钥，K2，初始密码状态）K4=。。。
DR(Key, Constant) = k-truncate(K1 | K2 | K3 | K4 ...)
DR（键，常数）=k-截断（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是一种算法，它采用m个输入位并“拉伸”它们以形成n个输出位，每个输入位对输出的贡献相等，如[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.
我们首先定义一个称为n-折叠的原语，它接受一个可变长度的输入块并生成一个固定长度的输出序列。目的是在确定每个输出位的值时，为每个输入位提供近似相等的权重。请注意，每当我们需要将一串八位字节视为一个数字时，假定的表示形式是Big-Endian——首先是最高有效字节。
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].
附录A[5]中提供了n倍的测试向量。
In this section, n-fold is always used to produce c bits of output, where c is the cipher block size of E.
在本节中，n-fold始终用于生成输出的c位，其中c是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.
常数的大小不能大于c，因为通过n折叠减少常数的长度可能会导致碰撞。
If the size of the Constant is smaller than c, then the Constant must be n-folded to length c. This string is used as input to E. If the block size of E is less than the random-to-key input size, then the output from E is taken as input to a second invocation of E. This process is repeated until the number of bits accumulated is greater than or equal to the random-to-key input size. When enough bits have been computed, the first k are taken as the random data used to create the key with the algorithm-dependent random-to-key function.
如果常数的大小小于c，则常数必须n折到长度c。该字符串用作E的输入。如果E的块大小小于随机键输入大小，则将E的输出作为E第二次调用的输入。重复此过程，直到累积的位数大于或等于随机键输入大小。当计算了足够的位时，第一个k被取为用于创建密钥的随机数据，该密钥具有与算法相关的random to key函数。
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.
由于派生密钥是基本密钥中一个或多个加密的结果，因此从派生密钥派生基本密钥相当于从极少量的明文/密文对中确定密钥。因此，这种构造与密码系统本身一样强大。
These are the operations and attributes that must be defined:
这些是必须定义的操作和属性：
protocol key format string-to-key function default string-to-key parameters key-generation seed length, k random-to-key function As above for the normal encryption mechanism profile.
协议密钥格式字符串到密钥函数默认字符串到密钥参数密钥生成种子长度，k随机到密钥函数如上所述，用于正常加密机制配置文件。
unkeyed hash algorithm, H This should be a collision-resistant hash algorithm with fixed-size output, suitable for use in an HMAC [HMAC]. It must support inputs of arbitrary length. Its output must be at least the message block size (below).
这应该是一个具有固定大小输出的抗冲突哈希算法，适合在HMAC[HMAC]中使用。它必须支持任意长度的输入。其输出必须至少为消息块大小（如下）。
HMAC output size, h This indicates the size of the leading substring output by the HMAC function that should be used in transmitted messages. It should be at least half the output size of the hash function H, and at least 80 bits; it need not match the output size.
HMAC output size，h这表示HMAC函数输出的前导子字符串的大小，应在传输的消息中使用。它应该至少是散列函数H的输出大小的一半，并且至少是80位；它不需要与输出大小匹配。
message block size, m This is the size of the smallest units the cipher can handle in the mode in which it is being used. Messages will be padded to a multiple of this size. If a block cipher is used in a mode that
消息块大小，m这是密码在使用模式下可以处理的最小单位的大小。消息将被填充到该大小的倍数。如果在以下模式中使用分组密码：
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.
可以处理不是密码块大小倍数的消息，例如CBC模式下的密文窃取（CTS，请参见[RC5]），此值将为一个八位字节。对于带填充的传统CBC模式，它将是底层密码的块大小。
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.
加密/解密函数E和D这些是用于大小为消息块大小的倍数的消息的基本加密和解密函数。此处不应包括完整性检查或混淆。对于输入，这些函数获取IV或类似数据、协议格式密钥和八位字节字符串，并返回新的IV和八位字节字符串。
The encryption function is not required to use CBC mode but is assumed to be using something with similar properties. In particular, prepending a cipher block-size confounder to the plaintext should alter the entire ciphertext (comparable to choosing and including a random initial vector for CBC mode).
加密函数不需要使用CBC模式，但假定使用具有类似属性的内容。特别是，将密码块大小混淆因子预先添加到明文应该会改变整个密文（相当于为CBC模式选择并包括随机初始向量）。
The result of encrypting one cipher block (of size c, above) must be deterministic for the random octet generation function DR in the previous section to work. For best security, it should also be no larger than c.
加密一个密码块（上面的大小为c）的结果必须是确定的，才能使上一节中的随机八位组生成函数DR起作用。为了获得最佳安全性，它也不应大于c。
cipher block size, c This is the block size of the block cipher underlying the encryption and decryption functions indicated above, used for key derivation and for the size of the message confounder and initial vector. (If a block cipher is not in use, some comparable parameter should be determined.) It must be at least 5 octets.
cipher block size，c这是上述加密和解密函数基础上的分组密码的块大小，用于密钥推导以及消息混淆因子和初始向量的大小。（如果未使用分组密码，则应确定一些可比较的参数。）它必须至少为5个八位字节。
This is not actually an independent parameter; rather, it is a property of the functions E and D. It is listed here to clarify the distinction between it and the message block size, m.
这实际上不是一个独立的参数；相反，它是函数E和D的一个属性。这里列出它是为了澄清它与消息块大小m之间的区别。
Although there are still a number of properties to specify, they are fewer and simpler than in the full profile.
尽管仍有许多属性需要指定，但它们比完整配置文件中的属性更少、更简单。
The above key derivation function is used to produce three intermediate keys. One is used for computing checksums of unencrypted data. The other two are used for encrypting and checksumming plaintext to be sent encrypted.
上述密钥派生函数用于生成三个中间密钥。一个用于计算未加密数据的校验和。另外两个用于加密和校验要加密发送的明文。
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.
如果使用HMAC函数的基本哈希值和指定的明文值，则可以将其与HMAC函数的基本哈希值进行级联，从而将其作为密码输出。当计算HMAC时，密钥以协议密钥形式使用。
Decryption is performed by removing the (partial) HMAC, decrypting the remainder, and verifying the HMAC. The cipher state is an initial vector, initialized to zero.
解密通过移除（部分）HMAC、解密剩余部分并验证HMAC来执行。密码状态是初始化为零的初始向量。
The substring notation "[1..h]" in the following table should be read as using 1-based indexing; leading substrings are used.
下表中的子字符串符号“[1..h]”应理解为使用基于1的索引；使用前导子字符串。
Cryptosystem from Simplified Profile
------------------------------------------------------------------------
protocol key format As given.
Cryptosystem from Simplified Profile
------------------------------------------------------------------------
protocol key format As given.
specific key structure Three protocol-format keys: { Kc, Ke, Ki }.
特定密钥结构三种协议格式密钥：{Kc，Ke，Ki}。
key-generation seed As given. length
密钥生成种子。长
required checksum As defined below in section 5.4. mechanism
第5.4节中定义的所需校验和。机械装置
cipher state Initial vector (usually of length c)
密码状态初始向量（通常长度为c）
initial cipher state All bits zero
初始密码状态所有位为零
encryption function conf = Random string of length c pad = Shortest string to bring confounder and plaintext to a length that's a multiple of m. (C1, newIV) = E(Ke, conf | plaintext | pad, oldstate.ivec) H1 = HMAC(Ki, conf | plaintext | pad) ciphertext = C1 | H1[1..h] newstate.ivec = newIV
加密函数conf=长度为c的随机字符串pad=最短字符串，将混淆和明文的长度设置为m的倍数。（C1，newIV）=E（Ke，conf |明文| pad，oldstate.ivec）H1=HMAC（Ki，conf |明文| 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
默认字符串设置为给定的键。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".
PRF操作中使用的“prfconstant”是三个八位组字符串“PRF”。
Cryptosystem from Simplified Profile
------------------------------------------------------------------------
key generation functions:
Cryptosystem from Simplified Profile
------------------------------------------------------------------------
key generation functions:
string-to-key function As given.
字符串到给定的键函数。
random-to-key function As given.
随机键到给定的键函数。
key-derivation function The "well-known constant" used for the DK function is the key usage number, expressed as four octets in big-endian order, followed by one octet indicated below.
密钥派生函数用于DK函数的“已知常数”是密钥使用数，表示为四个八位字节（按大端顺序），后跟一个八位字节，如下所示。
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);
When an encryption system is defined with the simplified profile given in section 5.2, a checksum algorithm may be defined for it as follows:
当使用第5.2节中给出的简化配置文件定义加密系统时，可为其定义校验和算法，如下所示：
Checksum Mechanism from Simplified Profile
--------------------------------------------------
associated cryptosystem As defined above.
Checksum Mechanism from Simplified Profile
--------------------------------------------------
associated cryptosystem As defined above.
get_mic HMAC(Kc, message)[1..h]
获取麦克风HMAC（Kc，消息）[1..h]
verify_mic get_mic and compare
验证\u麦克风获取\u麦克风并进行比较
The HMAC function and key Kc are as described in section 5.3.
HMAC功能和关键Kc如第5.3节所述。
These profiles describe the encryption and checksum systems defined for Kerberos. The astute reader will notice that some of them do not fulfill all the requirements outlined in previous sections. These systems are defined for backward compatibility; newer implementations should (whenever possible) attempt to utilize encryption systems that satisfy all the profile requirements.
这些概要文件描述了为Kerberos定义的加密和校验和系统。精明的读者会注意到，其中一些并没有满足前面章节中概述的所有要求。这些系统定义为向后兼容性；较新的实现应该（只要可能）尝试使用满足所有概要文件要求的加密系统。
The full list of current encryption and checksum type number assignments, including values currently reserved but not defined in this document, is given in section 8.
第8节给出了当前加密和校验和类型编号分配的完整列表，包括本文档中当前保留但未定义的值。
These checksum types use no encryption keys and thus can be used in combination with any encryption type, but they may only be used with caution, in limited circumstances where the lack of a key does not provide a window for an attack, preferably as part of an encrypted message [6]. Keyed checksum algorithms are recommended.
这些校验和类型不使用加密密钥，因此可以与任何加密类型结合使用，但只能在缺少密钥不会提供攻击窗口的有限情况下谨慎使用，最好作为加密消息的一部分[6]。建议使用键控校验和算法。
The RSA-MD5 checksum calculates a checksum by using the RSA MD5 algorithm [MD5-92]. The algorithm takes as input an input message of arbitrary length and produces as output a 128-bit (sixteen octet) checksum.
RSA-MD5校验和使用RSA MD5算法[MD5-92]计算校验和。该算法将任意长度的输入消息作为输入，并生成128位（16个八位字节）校验和作为输出。
rsa-md5
----------------------------------------------
associated cryptosystem any
rsa-md5
----------------------------------------------
associated cryptosystem any
get_mic rsa-md5(msg)
获取麦克风rsa-md5（msg）
verify_mic get_mic and compare
验证\u麦克风获取\u麦克风并进行比较
The rsa-md5 checksum algorithm is assigned a checksum type number of seven (7).
rsa-md5校验和算法的校验和类型编号为七（7）。
The RSA-MD4 checksum calculates a checksum using the RSA MD4 algorithm [MD4-92]. The algorithm takes as input an input message of arbitrary length and produces as output a 128-bit (sixteen octet) checksum.
RSA-MD4校验和使用RSA MD4算法[MD4-92]计算校验和。该算法将任意长度的输入消息作为输入，并生成128位（16个八位字节）校验和作为输出。
rsa-md4
----------------------------------------------
associated cryptosystem any
rsa-md4
----------------------------------------------
associated cryptosystem any
get_mic md4(msg)
获取麦克风md4（msg）
verify_mic get_mic and compare
验证\u麦克风获取\u麦克风并进行比较
The rsa-md4 checksum algorithm is assigned a checksum type number of two (2).
rsa-md4校验和算法的校验和类型编号为2。
This CRC-32 checksum calculates a checksum based on a cyclic redundancy check as described in ISO 3309 [CRC] but modified as described below. The resulting checksum is four (4) octets in length. The CRC-32 is neither keyed nor collision-proof; thus, the use of this checksum is not recommended. An attacker using a probabilistic chosen-plaintext attack as described in [SG92] might be able to generate an alternative message that satisfies the checksum.
该CRC-32校验和基于循环冗余校验计算校验和，如ISO 3309[CRC]所述，但修改如下所述。得到的校验和长度为四（4）个八位字节。CRC-32既不是键控的，也不是防碰撞的；因此，不建议使用此校验和。使用[SG92]中所述的概率选择明文攻击的攻击者可能能够生成满足校验和的替代消息。
The CRC-32 checksum used in the des-cbc-crc encryption mode is identical to the 32-bit FCS described in ISO 3309 with two exceptions: The sum with the all-ones polynomial times x**k is omitted, and the final remainder is not ones-complemented. ISO 3309 describes the FCS in terms of bits, whereas this document describes the Kerberos protocol in terms of octets. To clarify the ISO 3309 definition for the purpose of computing the CRC-32 in the des-cbc-crc encryption mode, the ordering of bits in each octet shall be assumed to be LSB first. Given this assumed ordering of bits within an octet, the mapping of bits to polynomial coefficients shall be identical to that specified in ISO 3309.
des cbc CRC加密模式中使用的CRC-32校验和与ISO 3309中描述的32位FCS相同，但有两个例外：省略所有1多项式乘以x**k的和，并且最后的余数不是补1。ISO 3309以位为单位描述了FCS，而本文档以八位字节为单位描述了Kerberos协议。为了澄清ISO 3309定义，以便在des cbc CRC加密模式下计算CRC-32，应首先假定每个八位字节中的位顺序为LSB。假定八位字节内的位顺序，位到多项式系数的映射应与ISO 3309中规定的相同。
Test values for this modified CRC function are included in appendix A.5.
附录A中包含了修改后的CRC测试值。
crc32
----------------------------------------------
associated cryptosystem any
crc32
----------------------------------------------
associated cryptosystem any
get_mic crc32(msg)
获取麦克风crc32（msg）
verify_mic get_mic and compare
验证\u麦克风获取\u麦克风并进行比较
The crc32 checksum algorithm is assigned a checksum type number of one (1).
crc32校验和算法的校验和类型编号为一（1）。
These encryption systems encrypt information under the Data Encryption Standard [DES77] by using the cipher block chaining mode [DESM80]. A checksum is computed as described below and placed in the cksum field. DES blocks are eight bytes. As a result, the data to be encrypted (the concatenation of confounder, checksum, and message) must be padded to an eight byte boundary before encryption. The values of the padding bytes are unspecified.
这些加密系统使用密码块链接模式[DESM80]对数据加密标准[DES77]下的信息进行加密。校验和按如下所述计算，并放在校验和字段中。DES块是八个字节。因此，要加密的数据（混淆、校验和和和消息的串联）必须在加密之前填充到8字节边界。未指定填充字节的值。
Plaintext and DES ciphertext are encoded as blocks of eight octets, which are concatenated to make the 64-bit inputs for the DES algorithms. The first octet supplies the eight most significant bits (with the octet's MSB used as the DES input block's MSB, etc.), the second octet the next eight bits, and so on. The eighth octet supplies the 8 least significant bits.
明文和DES密文被编码为八个八位字节的块，这些八位字节被连接起来为DES算法提供64位输入。第一个八位字节提供八个最高有效位（八位字节的MSB用作DES输入块的MSB等），第二个八位字节提供下八位，依此类推。第八个八位字节提供8个最低有效位。
Encryption under DES using cipher block chaining requires an additional input in the form of an initialization vector; this vector is specified below for each encryption system.
使用密码块链接的DES下的加密需要以初始化向量形式的额外输入；下面为每个加密系统指定了该向量。
The DES specifications [DESI81] identify four 'weak' and twelve 'semi-weak' keys; these keys SHALL NOT be used for encrypting messages for use in Kerberos. The "variant keys" generated for the RSA-MD5-DES, RSA-MD4-DES, and DES-MAC checksum types by an eXclusive-OR of a DES key with a constant are not checked for this property.
DES规范[DESI81]确定了四个“弱”键和十二个“半弱”键；这些密钥不得用于加密Kerberos中使用的消息。对于此属性，不检查由具有常量的DES密钥的异或为RSA-MD5-DES、RSA-MD4-DES和DES-MAC校验和类型生成的“变体密钥”。
A DES key is eight octets of data. This consists of 56 bits of actual key data, and eight parity bits, one per octet. The key is encoded as a series of eight octets written in MSB-first order. The bits within the key are also encoded in MSB order. For example, if the encryption key is (B1,B2,...,B7,P1,B8,...,B14,P2,B15,...,B49,P7,B50,...,B56,P8), where B1,B2,...,B56 are the key bits in MSB order, and P1,P2,...,P8 are the parity bits, the first octet of the key would be B1,B2,...,B7,P1 (with B1 as the most significant bit). See the [DESM80] introduction for reference.
DES密钥是八个八位字节的数据。这包括56位实际密钥数据和8位奇偶校验位，每个八位字节一位。密钥被编码为以MSB一阶写入的八个八位字节的序列。密钥中的位也按MSB顺序编码。例如，如果加密密钥是（B1、B2、…、B7、P1、B8、…、B14、P2、B15、…、B49、P7、B50、…、B56、P8），其中B1、B2、…、B56是按MSB顺序排列的密钥位，P1、P2、…、P8是奇偶校验位，则密钥的第一个八位组将是B1、B2、…、B7、P1（其中B1是最高有效位）。参考请参见[DESM80]简介。
Encryption Data Format
加密数据格式
The format for the data to be encrypted includes a one-block confounder, a checksum, the encoded plaintext, and any necessary padding, as described in the following diagram. The msg-seq field contains the part of the protocol message to be encrypted.
待加密数据的格式包括一块混淆、校验和、编码的明文和任何必要的填充，如下图所述。msg seq字段包含要加密的协议消息部分。
+-----------+----------+---------+-----+
|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.
一个生成一个块的随机混淆，将其置于“混淆”中；将“校验和”字段归零（长度适合精确保存要计算的校验和）；添加必要的填充；计算整个序列的适当校验和，将结果放入“校验和”中；然后使用指定的加密类型和适当的密钥进行加密。
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.
为了从两个UTF-8文本字符串（password和salt）生成DES密钥，将两个字符串串联在一起，首先是password，然后用零值八位字节将结果填充为八位字节的倍数。
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.
丢弃每个八位字节的顶部位（如果密码是纯ASCII码，则始终为零，正如编写原始规范时所假定的那样），每个八位字节的剩余七位形成一个位字符串。然后将其扇形折叠并与自身进行异或运算，以生成56位字符串。由该字符串形成一个八位字节键，每个八位字节使用位字符串中的七位，保留未分配的最低有效位。然后，通过更正密钥上的奇偶校验来“更正”该密钥，如果该密钥与DES规范中描述的“弱”或“半弱”密钥匹配，则该密钥与常量0x00000000000000F0进行异或运算。然后使用该键在附加salt的初始字符串上生成DES CBC校验和。然后，CBC校验和的结果被如上所述“更正”以形成结果，该结果作为密钥返回。
For purposes of the string-to-key function, the DES CBC checksum is calculated by CBC encrypting a string using the key as IV and the final eight byte block as the checksum.
对于字符串到密钥函数，DES CBC校验和是通过CBC使用密钥作为IV和最后的8字节块作为校验和对字符串进行加密来计算的。
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 */
}
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");
}
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).
一个常见的扩展是支持“AFS字符串到键”算法，如果上面的类型值为一（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:
为了从随机位字符串生成密钥，我们从56位字符串开始，并像上面的字符串到密钥操作一样，插入奇偶校验位。如果结果是弱密钥或半弱密钥，我们将使用常量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));
}
The des-cbc-md5 encryption mode encrypts information under DES in CBC mode with an all-zero initial vector and with an MD5 checksum (described in [MD5-92]) computed and placed in the checksum field.
des-cbc-md5加密模式在cbc模式下加密des下的信息，初始向量为全零，md5校验和（如[md5-92]中所述）计算并放置在校验和字段中。
The encryption system parameters for des-cbc-md5 are as follows:
des-cbc-md5的加密系统参数如下：
des-cbc-md5
--------------------------------------------------------------------
protocol key format 8 bytes, parity in low bit of each
des-cbc-md5
--------------------------------------------------------------------
protocol key format 8 bytes, parity in low bit of each
specific key structure copy of original key
原始密钥的特定密钥结构副本
required checksum rsa-md5-des mechanism
所需校验和rsa-md5-des机制
key-generation seed 8 bytes length
密钥生成种子8字节长度
cipher state 8 bytes (CBC initial vector)
密码状态8字节（CBC初始向量）
initial cipher state all-zero
初始密码状态全部为零
encryption function des-cbc(confounder | checksum | msg | pad, ivec=oldstate) where checksum = md5(confounder | 0000... | msg | pad)
加密函数des cbc（Confour | checksum | msg | pad，ivec=oldstate），其中checksum=md5（Confour | 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
解密函数解密加密文本并验证校验和
newstate = last block of ciphertext
newstate = last block of ciphertext
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:
密钥生成功能：
string-to-key des_string_to_key
字符串到键des_字符串到键
random-to-key des_random_to_key
随机到键des_随机到键
key-derivation identity
密钥派生标识
The des-cbc-md5 encryption type is assigned the etype value three (3).
des-cbc-md5加密类型分配了三（3）个etype值。
The des-cbc-md4 encryption mode also encrypts information under DES in CBC mode, with an all-zero initial vector. An MD4 checksum (described in [MD4-92]) is computed and placed in the checksum field.
des-cbc-md4加密模式还以全零初始向量在cbc模式下加密des下的信息。计算MD4校验和（如[MD4-92]所述），并将其放入校验和字段中。
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
原始密钥的特定密钥结构副本
required checksum rsa-md4-des mechanism
所需校验和rsa-md4-des机制
key-generation seed 8 bytes length
密钥生成种子8字节长度
cipher state 8 bytes (CBC initial vector)
密码状态8字节（CBC初始向量）
initial cipher state all-zero
初始密码状态全部为零
encryption function des-cbc(confounder | checksum | msg | pad, ivec=oldstate) where checksum = md4(confounder | 0000... | msg | pad)
加密函数des cbc（Confour | checksum | msg | pad，ivec=oldstate），其中checksum=md4（Confour | 0000…| msg | pad）
newstate = last block of des-cbc output
newstate = last block of des-cbc output
des-cbc-md4
--------------------------------------------------------------------
des-cbc-md4
--------------------------------------------------------------------
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
默认字符串为空字符串参数设置键
pseudo-random function des-cbc(md5(input-string), ivec=0)
pseudo-random function des-cbc(md5(input-string), ivec=0)
key generation functions:
密钥生成功能：
string-to-key des_string_to_key
字符串到键des_字符串到键
random-to-key copy input, then fix parity bits
随机键复制输入，然后修复奇偶校验位
key-derivation identity
密钥派生标识
Note that des-cbc-md4 uses md5, not md4, in the PRF definition.
请注意，des-cbc-md4在PRF定义中使用md5，而不是md4。
The des-cbc-md4 encryption algorithm is assigned the etype value two (2).
des-cbc-md4加密算法被分配etype值二（2）。
The des-cbc-crc encryption type uses DES in CBC mode with the key used as the initialization vector, with a four-octet CRC-based checksum computed as described in section 6.1.3. Note that this is not a standard CRC-32 checksum, but a slightly modified one.
des cbc crc加密类型在cbc模式下使用des，密钥用作初始化向量，并根据第6.1.3节中的说明计算基于四个八位组crc的校验和。注意，这不是一个标准的CRC-32校验和，而是一个稍加修改的校验和。
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
原始密钥的特定密钥结构副本
required checksum rsa-md5-des mechanism
所需校验和rsa-md5-des机制
key-generation seed 8 bytes length
密钥生成种子8字节长度
cipher state 8 bytes (CBC initial vector)
密码状态8字节（CBC初始向量）
des-cbc-crc
--------------------------------------------------------------------
initial cipher state copy of original key
des-cbc-crc
--------------------------------------------------------------------
initial cipher state copy of original key
encryption function des-cbc(confounder | checksum | msg | pad, ivec=oldstate) where checksum = crc(confounder | 00000000 | msg | pad)
加密函数des cbc（Confour | checksum | msg | pad，ivec=oldstate），其中checksum=crc（Confour | 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
解密函数解密加密文本并验证校验和
newstate = last block of ciphertext
newstate = last block of ciphertext
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:
密钥生成功能：
string-to-key des_string_to_key
字符串到键des_字符串到键
random-to-key copy input, then fix parity bits
随机键复制输入，然后修复奇偶校验位
key-derivation identity
密钥派生标识
The des-cbc-crc encryption algorithm is assigned the etype value one (1).
des cbc crc加密算法被分配etype值一（1）。
The RSA-MD5-DES checksum calculates a keyed collision-proof checksum by prepending an eight octet confounder before the text, applying the RSA MD5 checksum algorithm, and encrypting the confounder and the checksum by using DES in cipher-block-chaining (CBC) mode with a variant of the key, where the variant is computed by eXclusive-ORing the key with the hexadecimal constant 0xF0F0F0F0F0F0F0F0. The initialization vector should be zero. The resulting checksum is 24 octets long.
RSA-MD5-DES校验和通过在文本前预加一个八位字节的混淆，应用RSA MD5校验和算法，并通过在密码块链接（CBC）模式下使用DES和密钥变量对混淆和校验和进行加密，来计算密钥防冲突校验和，其中，通过使用十六进制常量0xF0对键进行异或运算来计算变量。初始化向量应为零。结果校验和为24个八位字节长。
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))
获取mic des cbc（键XOR 0xF0，conf | rsa-md5（conf | msg））
verify_mic decrypt and verify rsa-md5 checksum
验证\u mic解密并验证rsa-md5校验和
The rsa-md5-des checksum algorithm is assigned a checksum type number of eight (8).
rsa-md5-des校验和算法的校验和类型编号为八（8）。
The RSA-MD4-DES checksum calculates a keyed collision-proof checksum by prepending an eight octet confounder before the text, applying the RSA MD4 checksum algorithm [MD4-92], and encrypting the confounder and the checksum using DES in cipher-block-chaining (CBC) mode with a variant of the key, where the variant is computed by eXclusive-ORing the key with the constant 0xF0F0F0F0F0F0F0F0 [7]. The initialization vector should be zero. The resulting checksum is 24 octets long.
RSA-MD4-DES校验和通过在文本前预加一个八位字节的混淆，应用RSA MD4校验和算法[MD4-92]，并在密码块链接（CBC）模式下使用DES加密该混淆和校验和，并使用密钥的变体来计算密钥防冲突校验和，其中，通过使用常量0xF0[7]对键进行异或运算来计算变量。初始化向量应为零。结果校验和为24个八位字节长。
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)
获取mic des cbc（键XOR 0xF0，conf | rsa-md4（conf | msg），ivec=0）
verify_mic decrypt and verify rsa-md4 checksum
验证\u mic解密并验证rsa-md4校验和
The rsa-md4-des checksum algorithm is assigned a checksum type number of three (3).
rsa-md4-des校验和算法的校验和类型编号为三（3）。
The RSA-MD4-DES-K checksum calculates a keyed collision-proof checksum by applying the RSA MD4 checksum algorithm and encrypting the results by using DES in cipher block chaining (CBC) mode with a DES key as both key and initialization vector. The resulting checksum is 16 octets long. This checksum is tamper-proof and believed to be collision-proof. Note that this checksum type is the old method for encoding the RSA-MD4-DES checksum; it is no longer recommended.
RSA-MD4-DES-K校验和通过应用RSA MD4校验和算法并在密码块链接（CBC）模式下使用DES加密结果（DES密钥同时作为密钥和初始化向量），计算密钥防冲突校验和。结果校验和为16个八位字节长。该校验和是防篡改的，并且被认为是防碰撞的。请注意，此校验和类型是用于编码RSA-MD4-DES校验和的旧方法；不再建议使用此选项。
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
验证\u mic解密、计算校验和并比较
The rsa-md4-des-k checksum algorithm is assigned a checksum type number of six (6).
rsa-md4-des-k校验和算法的校验和类型编号为六（6）。
The DES-MAC checksum is computed by prepending an eight octet confounder to the plaintext, padding with zero-valued octets if necessary to bring the length to a multiple of eight octets, performing a DES CBC-mode encryption on the result by using the key and an initialization vector of zero, taking the last block of the ciphertext, prepending the same confounder, and encrypting the pair by using DES in cipher-block-chaining (CBC) mode with a variant of the key, where the variant is computed by eXclusive-ORing the key with the constant 0xF0F0F0F0F0F0F0F0. The initialization vector should be zero. The resulting checksum is 128 bits (sixteen octets) long, 64 bits of which are redundant. This checksum is tamper-proof and collision-proof.
DES-MAC校验和的计算方法是：在明文前加一个八位字节混淆因子，必要时用零值八位字节填充，使长度达到八位字节的倍数，使用密钥和零的初始化向量对结果执行DES CBC模式加密，取密文的最后一个块，在密码块链接（CBC）模式下使用DES对同一混淆因子进行预编码，并使用密钥变量对该对进行加密，其中变量是通过使用常量0xF0对密钥进行异或运算来计算的。初始化向量应为零。得到的校验和长度为128位（16个八位字节），其中64位是冗余的。此校验和是防篡改和防碰撞的。
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)
获取cbc话筒（XOR键0xF0F0，密码mac（键，密码msg，键盘，ivec=0），ivec=0）
verify_mic decrypt, compute DES MAC using confounder, compare
验证\u mic解密，使用混淆因子计算DES MAC，比较
The des-mac checksum algorithm is assigned a checksum type number of four (4).
des mac校验和算法的校验和类型编号为四（4）。
The DES-MAC-K checksum is computed by performing a DES CBC-mode encryption of the plaintext, with zero-valued padding bytes if necessary to bring the length to a multiple of eight octets, and by using the last block of the ciphertext as the checksum value. It is keyed with an encryption key that is also used as the initialization vector. The resulting checksum is 64 bits (eight octets) long. This
DES-MAC-K校验和是通过对明文执行DES-CBC模式加密来计算的，如有必要，使用零值填充字节将长度增加到八个八位字节的倍数，并使用密文的最后一个块作为校验和值。它由一个加密密钥加密，该密钥也用作初始化向量。结果校验和为64位（八个八位字节）长。这
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.
校验和是防篡改和防碰撞的。请注意，此校验和类型是用于编码DESMAC校验和的旧方法；不再建议使用此选项。
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)
获取mac的麦克风（按键，消息板，ivec=按键）
verify_mic compute MAC and compare
验证\u mic compute MAC并比较
The des-mac-k checksum algorithm is assigned a checksum type number of five (5).
des-mac-k校验和算法的校验和类型编号为五（5）。
This encryption and checksum type pair is based on the Triple DES cryptosystem in Outer-CBC mode and on the HMAC-SHA1 message authentication algorithm.
此加密和校验和类型对基于外部CBC模式下的三重DES密码系统和HMAC-SHA1消息认证算法。
A Triple DES key is the concatenation of three DES keys as described above for des-cbc-md5. A Triple DES key is generated from random data by creating three DES keys from separate sequences of random data.
三重DES密钥是上述DES-cbc-md5的三个DES密钥的串联。通过从单独的随机数据序列创建三个DES密钥，从随机数据生成三个DES密钥。
Encrypted data using this type must be generated as described in section 5.3. If the length of the input data is not a multiple of the block size, zero-valued octets must be used to pad the plaintext to the next eight-octet boundary. The confounder must be eight random octets (one block).
必须按照第5.3节所述生成使用此类型的加密数据。如果输入数据的长度不是块大小的倍数，则必须使用零值八位字节将明文填充到下一个八位字节边界。混杂因子必须是八个随机八位组（一个块）。
The simplified profile for Triple DES, with key derivation as defined in section 5, is as follows:
第5节中，三重键的推导定义如下：
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
密钥生成种子21字节长度
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输出大小160位
message block size 8 bytes
消息块大小为8字节
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)
加密和三重DES加密和解密函数在外部CBC模式下解密（密码块大小为8个八位字节）
key generation functions:
密钥生成功能：
random-to-key DES3random-to-key (see below)
随机至键des3随机至键（见下文）
string-to-key DES3string-to-key (see below)
字符串到键des3字符串到键（见下文）
The des3-cbc-hmac-sha1-kd encryption type is assigned the value sixteen (16). The hmac-sha1-des3-kd checksum algorithm is assigned a checksum type number of twelve (12).
des3-cbc-hmac-sha1-kd加密类型的值为十六（16）。hmac-sha1-des3-kd校验和算法的校验和类型编号为十二（12）。
The 168 bits of random key data are converted to a protocol key value as follows. First, the 168 bits are divided into three groups of 56 bits, which are expanded individually into 64 bits as follows:
168位随机密钥数据被转换为协议密钥值，如下所示。首先，168位分为三组56位，分别扩展为64位，如下所示：
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
DES3随机键：1234567p9101112131414141415p1718223p252627272829301p33433536373839p4142444447p495051525455p56484024168p
The "p" bits are parity bits computed over the data bits. The output of the three expansions, each corrected to avoid "weak" and "semi-weak" keys as in section 6.2, are concatenated to form the protocol key value.
“p”位是在数据位上计算的奇偶校验位。三个扩展的输出（每个扩展都经过了纠正以避免第6.2节中的“弱”和“半弱”密钥）被连接起来，形成协议密钥值。
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.
字符串到密钥函数用于将UTF-8密码转换为DES3密钥。DES3字符串到键函数依赖于第5节中描述的“N-fold”算法和DK函数。
The n-fold algorithm is applied to the password string concatenated with a salt value. For 3-key triple DES, the operation will involve a 168-fold of the input password string, to generate an intermediate key, from which the user's long-term key will be derived with the DK function. The DES3 string-to-key function is shown here in pseudocode:
n-fold算法应用于与salt值连接的密码字符串。对于三密钥三重DES，操作将涉及168倍的输入密码字符串，以生成一个中间密钥，用户的长期密钥将通过DK函数从中派生。DES3字符串到键函数在此处以伪代码显示：
DES3string-to-key(passwordString, salt, params)
if (params != emptyString)
error("invalid params");
s = passwordString + salt
tmpKey = random-to-key(168-fold(s))
key = DK (tmpKey, KerberosConstant)
DES3string-to-key(passwordString, salt, params)
if (params != emptyString)
error("invalid params");
s = passwordString + salt
tmpKey = random-to-key(168-fold(s))
key = DK (tmpKey, KerberosConstant)
Weak key checking is performed in the random-to-key and DK operations. The KerberosConstant value is the byte string {0x6b 0x65 0x72 0x62 0x65 0x72 0x6f 0x73}. These values correspond to the ASCII encoding for the string "kerberos".
弱密钥检查在随机到密钥和DK操作中执行。KerberosConstant值是字节字符串{0x6b 0x65 0x72 0x62 0x65 0x72 0x6f 0x73}。这些值对应于字符串“kerberos”的ASCII编码。
Several Kerberos-based application protocols and preauthentication systems have been designed and deployed that perform encryption and message integrity checks in various ways. Although in some cases there may be good reason for specifying these protocols in terms of specific encryption or checksum algorithms, we anticipate that in many cases this will not be true, and more generic approaches independent of particular algorithms will be desirable. Rather than have each protocol designer reinvent schemes for protecting data, using multiple keys, etc., we have attempted to present in this section a general framework that should be sufficient not only for the Kerberos protocol itself but also for many preauthentication systems and application protocols, while trying to avoid some of the assumptions that can work their way into such protocol designs.
已经设计并部署了几种基于Kerberos的应用程序协议和预验证系统，它们以各种方式执行加密和消息完整性检查。虽然在某些情况下，可能有充分的理由根据特定的加密或校验和算法指定这些协议，但我们预计，在许多情况下，情况并非如此，需要独立于特定算法的更通用的方法。我们没有让每个协议设计者重新设计保护数据、使用多个密钥等方案，而是试图在本节中介绍一个通用框架，该框架不仅适用于Kerberos协议本身，而且适用于许多预验证系统和应用程序协议，同时尽量避免一些可能会影响协议设计的假设。
Some problematic assumptions we've seen (and sometimes made) include the following: a random bitstring is always valid as a key (not true for DES keys with parity); the basic block encryption chaining mode provides no integrity checking, or can easily be separated from such checking (not true for many modes in development that do both simultaneously); a checksum for a message always results in the same value (not true if a confounder is incorporated); an initial vector is used (may not be true if a block cipher in CBC mode is not in use).
我们所看到的（有时所做的）一些有问题的假设包括以下内容：随机位字符串始终作为密钥有效（对于具有奇偶校验的DES密钥不正确）；基本块加密链接模式不提供完整性检查，或者可以很容易地与此类检查分离（对于同时进行这两种检查的开发中的许多模式而言，情况并非如此）；消息的校验和总是得到相同的值（如果合并了混杂因素，则不为真）；使用初始向量（如果未使用CBC模式下的分组密码，则可能不是真的）。
Although such assumptions the may hold for any given set of encryption and checksum algorithms, they may not be true of the next algorithms to be defined, leaving the application protocol unable to make use of those algorithms without updates to its specification.
尽管这些假设可能适用于任何给定的加密和校验和算法集，但它们可能不适用于下一个要定义的算法，这使得应用协议无法在不更新其规范的情况下使用这些算法。
The Kerberos protocol uses only the attributes and operations described in sections 3 and 4. Preauthentication systems and application protocols making use of Kerberos are encouraged to use them as well. The specific key and string-to-key parameters should generally be treated as opaque. Although the string-to-key parameters are manipulated as an octet string, the representation for the specific key structure is implementation defined; it may not even be a single object.
Kerberos协议仅使用第3节和第4节中描述的属性和操作。鼓励使用Kerberos的预认证系统和应用程序协议也使用它们。特定键和字符串到键参数通常应视为不透明。虽然字符串到键的参数作为八位字节字符串进行操作，但特定键结构的表示是实现定义的；它甚至可能不是单个对象。
We don't recommend doing so, but some application protocols will undoubtedly continue to use the key data directly, even if only in some of the currently existing protocol specifications. An implementation intended to support general Kerberos applications may therefore need to make the key data available, as well as the attributes and operations described in sections 3 and 4 [8].
我们不建议这样做，但是一些应用程序协议无疑将继续直接使用密钥数据，即使只是在一些现有的协议规范中。因此，旨在支持通用Kerberos应用程序的实现可能需要提供密钥数据，以及第3节和第4节[8]中描述的属性和操作。
The following encryption-type numbers are already assigned or reserved for use in Kerberos and related protocols.
以下加密类型编号已分配或保留，以在Kerberos和相关协议中使用。
encryption type etype section or comment
-----------------------------------------------------------------
des-cbc-crc 1 6.2.3
des-cbc-md4 2 6.2.2
des-cbc-md5 3 6.2.1
[reserved] 4
des3-cbc-md5 5
[reserved] 6
des3-cbc-sha1 7
dsaWithSHA1-CmsOID 9 (pkinit)
md5WithRSAEncryption-CmsOID 10 (pkinit)
sha1WithRSAEncryption-CmsOID 11 (pkinit)
rc2CBC-EnvOID 12 (pkinit)
rsaEncryption-EnvOID 13 (pkinit from PKCS#1 v1.5)
rsaES-OAEP-ENV-OID 14 (pkinit from PKCS#1 v2.0)
des-ede3-cbc-Env-OID 15 (pkinit)
des3-cbc-sha1-kd 16 6.3
aes128-cts-hmac-sha1-96 17 [KRB5-AES]
aes256-cts-hmac-sha1-96 18 [KRB5-AES]
rc4-hmac 23 (Microsoft)
rc4-hmac-exp 24 (Microsoft)
subkey-keymaterial 65 (opaque; PacketCable)
encryption type etype section or comment
-----------------------------------------------------------------
des-cbc-crc 1 6.2.3
des-cbc-md4 2 6.2.2
des-cbc-md5 3 6.2.1
[reserved] 4
des3-cbc-md5 5
[reserved] 6
des3-cbc-sha1 7
dsaWithSHA1-CmsOID 9 (pkinit)
md5WithRSAEncryption-CmsOID 10 (pkinit)
sha1WithRSAEncryption-CmsOID 11 (pkinit)
rc2CBC-EnvOID 12 (pkinit)
rsaEncryption-EnvOID 13 (pkinit from PKCS#1 v1.5)
rsaES-OAEP-ENV-OID 14 (pkinit from PKCS#1 v2.0)
des-ede3-cbc-Env-OID 15 (pkinit)
des3-cbc-sha1-kd 16 6.3
aes128-cts-hmac-sha1-96 17 [KRB5-AES]
aes256-cts-hmac-sha1-96 18 [KRB5-AES]
rc4-hmac 23 (Microsoft)
rc4-hmac-exp 24 (Microsoft)
subkey-keymaterial 65 (opaque; PacketCable)
(The "des3-cbc-sha1" assignment is a deprecated version using no key derivation. It should not be confused with des3-cbc-sha1-kd.)
（des3-cbc-sha1分配是不推荐使用的版本，不使用密钥派生。不应将其与des3-cbc-sha1-kd混淆。）
Several numbers have been reserved for use in encryption systems not defined here. Encryption-type numbers have unfortunately been overloaded on occasion in Kerberos-related protocols, so some of the reserved numbers do not and will not correspond to encryption systems fitting the profile presented here.
已经保留了几个数字，以便在此处未定义的加密系统中使用。不幸的是，在Kerberos相关协议中，加密类型编号有时会过载，因此一些保留编号不会也不会对应于符合此处提供的配置文件的加密系统。
The following checksum-type numbers are assigned or reserved. As with encryption-type numbers, some overloading of checksum numbers has occurred.
分配或保留以下校验和类型编号。与加密类型的数字一样，校验和数字出现了一些过载。
Checksum type sumtype checksum section or
value size reference
---------------------------------------------------------------------
CRC32 1 4 6.1.3
rsa-md4 2 16 6.1.2
rsa-md4-des 3 24 6.2.5
des-mac 4 16 6.2.7
des-mac-k 5 8 6.2.8
rsa-md4-des-k 6 16 6.2.6
rsa-md5 7 16 6.1.1
rsa-md5-des 8 24 6.2.4
rsa-md5-des3 9 24 ??
sha1 (unkeyed) 10 20 ??
hmac-sha1-des3-kd 12 20 6.3
hmac-sha1-des3 13 20 ??
sha1 (unkeyed) 14 20 ??
hmac-sha1-96-aes128 15 20 [KRB5-AES]
hmac-sha1-96-aes256 16 20 [KRB5-AES]
[reserved] 0x8003 ? [GSS-KRB5]
Checksum type sumtype checksum section or
value size reference
---------------------------------------------------------------------
CRC32 1 4 6.1.3
rsa-md4 2 16 6.1.2
rsa-md4-des 3 24 6.2.5
des-mac 4 16 6.2.7
des-mac-k 5 8 6.2.8
rsa-md4-des-k 6 16 6.2.6
rsa-md5 7 16 6.1.1
rsa-md5-des 8 24 6.2.4
rsa-md5-des3 9 24 ??
sha1 (unkeyed) 10 20 ??
hmac-sha1-des3-kd 12 20 6.3
hmac-sha1-des3 13 20 ??
sha1 (unkeyed) 14 20 ??
hmac-sha1-96-aes128 15 20 [KRB5-AES]
hmac-sha1-96-aes256 16 20 [KRB5-AES]
[reserved] 0x8003 ? [GSS-KRB5]
Encryption and checksum-type numbers are signed 32-bit values. Zero is invalid, and negative numbers are reserved for local use. All standardized values must be positive.
加密和校验和类型的数字是有符号的32位值。零无效，负数保留供本地使用。所有标准化值必须为正值。
The "interface" described here is the minimal information that must be defined to make a cryptosystem useful within Kerberos in an interoperable fashion. The use of functional notation used in some places is not an attempt to define an API for cryptographic functionality within Kerberos. Actual implementations providing clean APIs will probably make additional information available, that could be derived from a specification written to the framework given here. For example, an application designer may wish to determine the largest number of bytes that can be encrypted without overflowing a
这里描述的“接口”是必须定义的最小信息，以使加密系统以可互操作的方式在Kerberos中有用。在某些地方使用函数表示法并不是试图为Kerberos中的加密功能定义API。提供干净API的实际实现可能会提供额外的信息，这些信息可以从编写到这里给出的框架的规范中派生出来。例如，应用程序设计人员可能希望确定在不溢出数据的情况下可以加密的最大字节数
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.)
特定大小的输出缓冲区，或者相反，通过解密给定大小的密文消息可以获得的最大字节数。（事实上，GSS-API Kerberos机制[GSS-KRB5]的实现将需要其中一些机制。）
The presence of a mechanism in this document should not be taken to indicate that it must be implemented for compliance with any specification; required mechanisms will be specified elsewhere. Indeed, some of the mechanisms described here for backward compatibility are now considered rather weak for protecting critical data.
本文件中存在的机制不应被视为表明必须实施该机制以符合任何规范；所需机制将在其他地方指定。事实上，这里描述的一些向后兼容性机制现在被认为在保护关键数据方面相当薄弱。
Recent years have brought so many advancements in large-scale attacks capability against DES that it is no longer considered a strong encryption mechanism. Triple-DES is generally preferred in its place, despite its poorer performance. See [ESP-DES] for a summary of some of the potential attacks and [EFF-DES] for a detailed discussion of the implementation of particular attacks. However, most Kerberos implementations still have DES as their primary interoperable encryption type.
近年来，针对DES的大规模攻击能力有了很大的提高，因此不再认为DES是一种强大的加密机制。尽管三重DES的性能较差，但它通常是首选的替代品。请参阅[ESP-DES]了解一些潜在攻击的摘要，并参阅[EFF-DES]了解特定攻击实施的详细讨论。但是，大多数Kerberos实现仍然将DES作为其主要的可互操作加密类型。
DES has four 'weak' keys and twelve 'semi-weak' keys, and the use of single-DES here avoids them. However, DES also has 48 'possibly-weak' keys [Schneier96] (note that the tables in many editions of the reference contains errors) that are not avoided.
DES有四个“弱”键和十二个“半弱”键，在这里使用单个DES可以避免它们。然而，DES也有48个“可能较弱”的键[Schneier96]（注意，参考文献的许多版本中的表都包含错误），这是无法避免的。
DES weak keys have the property that E1(E1(P)) = P (where E1 denotes encryption of a single block with key 1). DES semi-weak keys, or "dual" keys, are pairs of keys with the property that E1(P) = D2(P), and thus E2(E1(P)) = P. Because of the use of CBC mode and the leading random confounder, however, these properties are unlikely to present a security problem.
DES弱密钥具有E1（E1（P））=P的特性（其中E1表示使用密钥1对单个块进行加密）。DES半弱密钥或“双”密钥是具有E1（P）=D2（P）属性的密钥对，因此E2（E1（P））=P。但是，由于使用CBC模式和领先的随机混杂因素，这些属性不太可能出现安全问题。
Many of the choices concerning when to perform weak-key corrections relate more to compatibility with existing implementations than to any risk analysis.
关于何时执行弱键更正的许多选择更多地涉及与现有实现的兼容性，而不是任何风险分析。
Although checks are also done for the component DES keys in a triple-DES key, the nature of the weak keys make it extremely unlikely that they will weaken the triple-DES encryption. It is only slightly more likely than having the middle of the three sub-keys match one of the other two, which effectively converts the encryption to single-DES - a case we make no effort to avoid.
虽然也对三重DES密钥中的组件DES密钥进行了检查，但弱密钥的性质使得它们极不可能削弱三重DES加密。这只比让三个子密钥的中间部分与另外两个子密钥中的一个子密钥相匹配的可能性稍高一点，这将有效地将加密转换为单个DES——我们不会尽力避免这种情况。
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]。当然，对于此类攻击构成重大威胁的环境，建议使用防碰撞校验和。在为Kerberos实现CRC-32时引入的“简化”（read:bug）会导致有效地忽略前导零，因此仅前导零位不同的消息将具有相同的校验和。
[HMAC] and [IPSEC-HMAC] discuss weaknesses of the HMAC algorithm. Unlike [IPSEC-HMAC], the triple-DES specification here does not use the suggested truncation of the HMAC output. As pointed out in [IPSEC-HMAC], SHA-1 was not developed for use as a keyed hash function, which is a criterion of HMAC. [HMAC-TEST] contains test vectors for HMAC-SHA-1.
[HMAC]和[IPSEC-HMAC]讨论HMAC算法的弱点。与[IPSEC-HMAC]不同，此处的三重DES规范不使用建议的HMAC输出截断。正如[IPSEC-HMAC]中所指出的，SHA-1不是为用作键控哈希函数而开发的，这是HMAC的标准。[HMAC-TEST]包含HMAC-SHA-1的测试向量。
The mit_des_string_to_key function was originally constructed with the assumption that all input would be ASCII; it ignores the top bit of each input byte. Folding with XOR is also not an especially good mixing mechanism for preserving randomness.
mit_des_string_to_key函数最初构造时假设所有输入都是ASCII码；它忽略每个输入字节的顶部位。用异或折叠也不是一种特别好的保持随机性的混合机制。
The n-fold function used in the string-to-key operation for des3- cbc-hmac-sha1-kd was designed to cause each bit of input to contribute equally to the output. It was not designed to maximize or equally distribute randomness in the input, and conceivably randomness may be lost in cases of partially structured input. This should only be an issue for highly structured passwords, however.
des3-cbc-hmac-sha1-kd的字符串到键操作中使用的n倍函数旨在使输入的每一位对输出的贡献相等。它不是为了最大化或平均分配输入中的随机性而设计的，可以想象，在部分结构化输入的情况下，随机性可能会丢失。但是，这应该只是高度结构化密码的问题。
[RFC1851] discusses the relative strength of triple-DES encryption. The relatively slow speed of triple-DES encryption may also be an issue for some applications.
[RFC1851]讨论了三重DES加密的相对强度。对于某些应用来说，三重DES加密的速度相对较慢也可能是一个问题。
[Bellovin91] suggests that analyses of encryption schemes include a model of an attacker capable of submitting known plaintexts to be encrypted with an unknown key, as well as be able to perform many types of operations on known protocol messages. Recent experiences with the chosen-plaintext attacks on Kerberos version 4 bear out the value of this suggestion.
[Bellovin91]指出，对加密方案的分析包括攻击者能够提交已知明文以使用未知密钥进行加密的模型，以及能够对已知协议消息执行多种类型的操作的模型。最近在Kerberos版本4上选择明文攻击的经验证明了这一建议的价值。
The use of unkeyed encrypted checksums, such as those used in the single-DES cryptosystems specified in [Kerb1510], allows for cut-and-paste attacks, especially if a confounder is not used. In addition, unkeyed encrypted checksums are vulnerable to chosen-plaintext attacks: An attacker with access to an encryption oracle can easily encrypt the required unkeyed checksum along with the
未加密校验和的使用，如[Kerb1510]中规定的单DES密码系统中使用的校验和，允许剪切和粘贴攻击，尤其是在未使用混淆的情况下。此外，未加密的校验和容易受到选择的明文攻击：访问加密oracle的攻击者可以轻松加密所需的未加密校验和以及
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.
使用随机混淆是防止攻击者有效利用协议交换作为加密工具的重要手段。在Kerberos版本4中，将常量明文加密为常量密文可为攻击者提供有效的加密oracle。在[Kerb1510]中使用随机混杂因素会挫败这种选择的明文攻击。
Using the same key for multiple purposes can enable or increase the scope of chosen-plaintext attacks. Some software that implements both versions 4 and 5 of the Kerberos protocol uses the same keys for both versions. This enables the encryption oracle of version 4 to be used to attack version 5. Vulnerabilities to attacks such as this cross-protocol attack make it unwise to use a key for multiple purposes.
将同一密钥用于多种目的可以启用或增加所选明文攻击的范围。一些同时实现Kerberos协议版本4和版本5的软件对这两个版本使用相同的密钥。这使4版的加密oracle能够用于攻击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.
与Kerberos协议一样，本文档并未将密钥可用于的数据量限制为基于算法健壮性或密钥大小的数量。假设任何定义的算法和密钥大小都足以支持非常大的数据量，或者一旦知道重大的攻击，它们就会被弃用。
This document also places no bounds on the amount of data that can be handled in various operations. To avoid denial of service attacks, implementations will probably seek to restrict message sizes at some higher level.
本文档还对各种操作中可以处理的数据量没有限制。为了避免拒绝服务攻击，实现可能会在更高级别上限制消息大小。
Two registries for numeric values have been created: Kerberos Encryption Type Numbers and Kerberos Checksum Type Numbers. These are signed values ranging from -2147483648 to 2147483647. Positive values should be assigned only for algorithms specified in accordance with this specification for use with Kerberos or related protocols. Negative values are for private use; local and experimental algorithms should use these values. Zero is reserved and may not be assigned.
已经为数值创建了两个注册表：Kerberos加密类型编号和Kerberos校验和类型编号。这些是介于-2147483648到2147483647之间的有符号值。应仅为根据本规范指定的用于Kerberos或相关协议的算法分配正值。负值仅供私人使用；本地和实验算法应使用这些值。零是保留的，不能分配。
Positive encryption- and checksum-type numbers may be assigned following either of two policies described in [BCP26].
可以按照[BCP26]中描述的两种策略之一分配正加密和校验和类型编号。
Standards-track specifications may be assigned values under the Standards Action policy.
标准跟踪规范可根据标准行动政策分配值。
Specifications in non-standards track RFCs may be assigned values after Expert Review. A non-IETF specification may be assigned values by publishing an Informational or standards-track RFC referencing the external specification; that specification must be public and published in some permanent record, much like the IETF RFCs. It is highly desirable, though not required, that the full specification be published as an IETF RFC.
非标准轨道RFC中的规范可在专家审查后指定值。非IETF规范可通过发布参考外部规范的信息性或标准跟踪RFC来赋值；该规范必须公开并以某种永久性记录的形式发布，就像IETF RFC一样。尽管不是必需的，但非常希望将完整规范作为IETF RFC发布。
Smaller encryption type values should be used for IETF standards-track mechanisms, and much higher values (16777216 and above) for other mechanisms. (Rationale: In the Kerberos ASN.1 encoding, smaller numbers encode to smaller octet sequences, so this favors standards-track mechanisms with slightly smaller messages.) Aside from that guideline, IANA may choose numbers as it sees fit.
IETF标准跟踪机制应使用较小的加密类型值，其他机制应使用更高的值（16777216及以上）。（理由：在Kerberos 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.
Internet草案规范不应包括加密和校验和类型的数字值。相反，他们应该指出，当文件被批准为RFC时，IANA将分配值。对于开发和互操作性测试，可以使用专用范围内的值（负值），但不应包含在规范草案中。
Each registered value should have an associated unique reference name. The lists given in section 8 were used to create the initial registry; they include reservations for specifications in progress in parallel with this document, and certain other values believed to already be in use.
每个注册值都应该有一个关联的唯一引用名称。第8节中给出的列表用于创建初始注册表；它们包括对与本文件同时进行的规范的保留，以及据信已在使用的某些其他值。
This document is an extension of the encryption specification included in [Kerb1510] by B. Clifford Neuman and John Kohl, and much of the text of the background, concepts, and DES specifications is drawn directly from that document.
本文件是B.Clifford Neuman和John Kohl在[Kerb1510]中包含的加密规范的扩展，背景、概念和DES规范的大部分文本直接取自该文件。
The abstract framework presented in this document was put together by Jeff Altman, Sam Hartman, Jeff Hutzelman, Cliff Neuman, Ken Raeburn, and Tom Yu, and the details were refined several times based on comments from John Brezak and others.
本文中提出的抽象框架由杰夫·奥特曼、萨姆·哈特曼、杰夫·哈泽尔曼、克里夫·纽曼、肯·雷伯恩和汤姆·余共同构建，并根据约翰·布雷扎克和其他人的评论对细节进行了多次细化。
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.
Marc Horowitz在一对互联网草案（以draft Horowitz key derivation和draft Horowitz kerb key derivation的名义）中编写了三重DES和密钥派生的原始规范，这些草案后来被合并为[Kerb1510]的修订草案，本文件后来从中分离出来。
Tom Yu provided the text describing the modifications to the standard CRC algorithm as Kerberos implementations actually use it, and some of the text in the Security Considerations section.
Tom Yu提供了描述在Kerberos实现实际使用时对标准CRC算法所做修改的文本，以及安全注意事项部分的一些文本。
Miroslav Jurisic provided information for one of the UTF-8 test cases for the string-to-key functions.
Miroslav Justic为字符串到键函数的UTF-8测试用例之一提供了信息。
Marcus Watts noticed some errors in earlier versions and pointed out that the simplified profile could easily be modified to support cipher text stealing modes.
Marcus Watts注意到早期版本中的一些错误，并指出简化的配置文件可以很容易地修改以支持密文窃取模式。
Simon Josefsson contributed some clarifications to the DES "CBC checksum" and string-to-key and weak key descriptions, and some test vectors.
Simon Josefsson对DES“CBC校验和”和字符串对键和弱键的描述以及一些测试向量做了一些澄清。
Simon Josefsson, Louis LeVay, and others also caught some errors in earlier versions of this document.
Simon Josefsson、Louis LeVay和其他人也发现了本文档早期版本中的一些错误。
A. Test Vectors
A.测试向量
This section provides test vectors for various functions defined or described in this document. For convenience, most inputs are ASCII strings, though some UTF-8 samples are provided for string-to-key functions. Keys and other binary data are specified as hexadecimal strings.
本节提供了本文档中定义或描述的各种功能的测试向量。为了方便起见，大多数输入都是ASCII字符串，尽管有些UTF-8示例是为字符串到键函数提供的。键和其他二进制数据被指定为十六进制字符串。
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:
第5.1节定义了n倍函数。如上所述，定义算法的原始文件中的样本向量似乎不正确。以下是Marc Horowitz和Simon Josefsson提供的一些测试用例：
64-fold("012345") =
64-fold(303132333435) = be072631276b1955
64-fold("012345") =
64-fold(303132333435) = be072631276b1955
56-fold("password") =
56-fold(70617373776f7264) = 78a07b6caf85fa
56-fold("password") =
56-fold(70617373776f7264) = 78a07b6caf85fa
64-fold("Rough Consensus, and Running Code") = 64-fold(526f75676820436f6e73656e7375732c20616e642052756e 6e696e6720436f6465) = bb6ed30870b7f0e0
64倍（“大致共识和运行代码”）=64倍（526F7568620436F6E73656E7375732C20616E642052756E 6E696E67204436F6465）=bb6ed30870b7f0e0
168-fold("password") =
168-fold(70617373776f7264) =
59e4a8ca7c0385c3c37b3f6d2000247cb6e6bd5b3e
168-fold("password") =
168-fold(70617373776f7264) =
59e4a8ca7c0385c3c37b3f6d2000247cb6e6bd5b3e
192-fold("MASSACHVSETTS INSTITVTE OF TECHNOLOGY")
192-fold(4d41535341434856534554545320494e5354495456544520
4f4620544543484e4f4c4f4759) =
db3b0d8f0b061e603282b308a50841229ad798fab9540c1b
192-fold("MASSACHVSETTS INSTITVTE OF TECHNOLOGY")
192-fold(4d41535341434856534554545320494e5354495456544520
4f4620544543484e4f4c4f4759) =
db3b0d8f0b061e603282b308a50841229ad798fab9540c1b
168-fold("Q") = 168-fold(51) = 518a54a2 15a8452a 518a54a2 15a8452a 518a54a2 15
168倍（“Q”）=168倍（51）=518a54a2 15a8452a 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节）。
64-fold("kerberos") = 6b657262 65726f73 128-fold("kerberos") = 6b657262 65726f73 7b9b5b2b 93132b93 168-fold("kerberos") = 8372c236 344e5f15 50cd0747 e15d62ca 7a5a3bce a4 256-fold("kerberos") = 6b657262 65726f73 7b9b5b2b 93132b93 5c9bdcda d95c9899 c4cae4de e6d6cae4
64倍（“kerberos”）=6b657262 65726f73 128倍（“kerberos”）=6b657262 65726f73 7b9b5b2b 93132b93 168倍（“kerberos”）=8372c236 344e5f15 50cd0747 e15d62ca 7a5a3bce a4 256倍（“kerberos”）=6b657262 65726f73 7b9b5b2b 93132b93 5c9bdcda d95c9899 C4CAE6D6CAE4
Note that the initial octets exactly match the input string when the output length is a multiple of the input length.
请注意，当输出长度是输入长度的倍数时，初始八位字节与输入字符串完全匹配。
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.
第6.2节定义了mit_des_string_to_key函数。我们在这里给出了几个测试值，以及一些中间结果。第四个测试演示了三个字符的UTF-8的使用。最后两个测试是专门构造的，以触发扇形折叠产生的中间键的弱键修复；我们没有导致对最终密钥进行此类修复的测试用例。
UTF-8 encodings used in test vector:
eszett U+00DF C3 9F s-caron U+0161 C5 A1
c-acute U+0107 C4 87 g-clef U+1011E F0 9D 84 9E
UTF-8 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
Test vector:
测试向量：
salt: "ATHENA.MIT.EDUraeburn" 415448454e412e4d49542e4544557261656275726e password: "password" 70617373776f7264 fan-fold result: c01e38688ac86c2e intermediate key: c11f38688ac86d2f DES key: cbc22fae235298e3
salt：“ATHENA.MIT.EDUraeburn”415448454E412E4D49544557261656275726E密码：“密码”70617373776f7264扇形折叠结果：c01e38688ac86c2e中间密钥：C11F3868AC86D2F DES密钥：cbc22fae235298e3
salt: "WHITEHOUSE.GOVdanny" 5748495445484f5553452e474f5664616e6e79 password: "potatoe" 706f7461746f65 fan-fold result: a028944ee63c0416 intermediate key: a129944fe63d0416 DES key: df3d32a74fd92a01
salt：“WHITEHOUSE.govdnny”5748495445484F553452E474F56646116E6E79密码：“potatoe”706F746746F65风扇折叠结果：a028944ee63c0416中间键：a129944fe63d0416 DES键：df3d32a74fd92a01
salt: "EXAMPLE.COMpianist" 4558414D504C452E434F4D7069616E697374 password: g-clef (U+1011E) f09d849e fan-fold result: 3c4a262c18fab090 intermediate key: 3d4a262c19fbb091
salt:“EXAMPLE.COMpianist”4558414D504C452E434F4D7069616E697374密码：g-clef（U+1011E）f09d849e扇形折叠结果：3c4a262c18fab090中间键：3d4a262c19fbb091
DES key: 4ffb26bab0cd9413
DES键：4ffb26bab0cd9413
salt: "ATHENA.MIT.EDUJuri" + s-caron(U+0161) + "i" + c-acute(U+0107)
415448454e412e4d49542e4544554a757269c5a169c487
password: eszett(U+00DF)
c39f
fan-fold result:b8f6c40e305afc9e
intermediate key: b9f7c40e315bfd9e
DES key: 62c81a5232b5e69d
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
salt: "AAAAAAAA" 4141414141414141 password: "11119999" 3131313139393939 fan-fold result: e0e0e0e0f0f0f0f0 intermediate key: e0e0e0e0f1f1f101 DES key: 984054d0f1a73e31
salt:“AAAAAAAA”414141密码：“11119999”3131393939风扇折叠结果：E0E0E0F0中间键：E0E0E0F1F1F101 DES键：984054d0f1a73e31
salt: "FFFFAAAA" 4646464641414141 password: "NNNN6666" 4e4e4e4e36363636 fan-fold result: 1e1e1e1e0e0e0e0e intermediate key: 1f1f1f1f0e0e0efe DES key: c4bf6b25adf7a4f8
salt:“FFFFAAAA”46464141密码：“NNNN6666”4E4636363636扇形折叠结果：1E1E0E0E0E中间键：1F1F0E0EFE DES键：c4bf6b25adf7a4f8
This trace provided by Simon Josefsson shows the intermediate processing stages of one of the test inputs:
Simon Josefsson提供的跟踪显示了其中一个测试输入的中间处理阶段：
string_to_key (des-cbc-md5, string, salt)
;; string:
;; `password' (length 8 bytes)
;; 70 61 73 73 77 6f 72 64
;; salt:
;; `ATHENA.MIT.EDUraeburn' (length 21 bytes)
;; 41 54 48 45 4e 41 2e 4d 49 54 2e 45 44 55 72 61
;; 65 62 75 72 6e
des_string_to_key (string, salt)
;; String:
;; `password' (length 8 bytes)
;; 70 61 73 73 77 6f 72 64
;; Salt:
;; `ATHENA.MIT.EDUraeburn' (length 21 bytes)
;; 41 54 48 45 4e 41 2e 4d 49 54 2e 45 44 55 72 61
;; 65 62 75 72 6e
odd = 1;
s = string | salt;
tempstring = 0; /* 56-bit string */
pad(s); /* with nulls to 8 byte boundary */
;; s = pad(string|salt):
;; `passwordATHENA.MIT.EDUraeburn\x00\x00\x00'
;; (length 32 bytes)
string_to_key (des-cbc-md5, string, salt)
;; string:
;; `password' (length 8 bytes)
;; 70 61 73 73 77 6f 72 64
;; salt:
;; `ATHENA.MIT.EDUraeburn' (length 21 bytes)
;; 41 54 48 45 4e 41 2e 4d 49 54 2e 45 44 55 72 61
;; 65 62 75 72 6e
des_string_to_key (string, salt)
;; String:
;; `password' (length 8 bytes)
;; 70 61 73 73 77 6f 72 64
;; Salt:
;; `ATHENA.MIT.EDUraeburn' (length 21 bytes)
;; 41 54 48 45 4e 41 2e 4d 49 54 2e 45 44 55 72 61
;; 65 62 75 72 6e
odd = 1;
s = string | salt;
tempstring = 0; /* 56-bit string */
pad(s); /* with nulls to 8 byte boundary */
;; s = pad(string|salt):
;; `passwordATHENA.MIT.EDUraeburn\x00\x00\x00'
;; (length 32 bytes)
;; 70 61 73 73 77 6f 72 64 41 54 48 45 4e 41 2e 4d
;; 49 54 2e 45 44 55 72 61 65 62 75 72 6e 00 00 00
for (8byteblock in s) {
;; loop iteration 0
;; 8byteblock:
;; `password' (length 8 bytes)
;; 70 61 73 73 77 6f 72 64
;; 01110000 01100001 01110011 01110011 01110111 01101111
;; 01110010 01100100
56bitstring = removeMSBits(8byteblock);
;; 56bitstring:
;; 1110000 1100001 1110011 1110011 1110111 1101111
;; 1110010 1100100
if (odd == 0) reverse(56bitstring); ;; odd=1
odd = ! odd
tempstring = tempstring XOR 56bitstring;
;; tempstring
;; 1110000 1100001 1110011 1110011 1110111 1101111
;; 1110010 1100100
;; 70 61 73 73 77 6f 72 64 41 54 48 45 4e 41 2e 4d
;; 49 54 2e 45 44 55 72 61 65 62 75 72 6e 00 00 00
for (8byteblock in s) {
;; loop iteration 0
;; 8byteblock:
;; `password' (length 8 bytes)
;; 70 61 73 73 77 6f 72 64
;; 01110000 01100001 01110011 01110011 01110111 01101111
;; 01110010 01100100
56bitstring = removeMSBits(8byteblock);
;; 56bitstring:
;; 1110000 1100001 1110011 1110011 1110111 1101111
;; 1110010 1100100
if (odd == 0) reverse(56bitstring); ;; odd=1
odd = ! odd
tempstring = tempstring XOR 56bitstring;
;; tempstring
;; 1110000 1100001 1110011 1110011 1110111 1101111
;; 1110010 1100100
for (8byteblock in s) {
;; loop iteration 1
;; 8byteblock:
;; `ATHENA.M' (length 8 bytes)
;; 41 54 48 45 4e 41 2e 4d
;; 01000001 01010100 01001000 01000101 01001110 01000001
;; 00101110 01001101
56bitstring = removeMSBits(8byteblock);
;; 56bitstring:
;; 1000001 1010100 1001000 1000101 1001110 1000001
;; 0101110 1001101
if (odd == 0) reverse(56bitstring); ;; odd=0
reverse(56bitstring)
;; 56bitstring after reverse
;; 1011001 0111010 1000001 0111001 1010001 0001001
;; 0010101 1000001
odd = ! odd
tempstring = tempstring XOR 56bitstring;
;; tempstring
;; 0101001 1011011 0110010 1001010 0100110 1100110
;; 1100111 0100101
for (8byteblock in s) {
;; loop iteration 1
;; 8byteblock:
;; `ATHENA.M' (length 8 bytes)
;; 41 54 48 45 4e 41 2e 4d
;; 01000001 01010100 01001000 01000101 01001110 01000001
;; 00101110 01001101
56bitstring = removeMSBits(8byteblock);
;; 56bitstring:
;; 1000001 1010100 1001000 1000101 1001110 1000001
;; 0101110 1001101
if (odd == 0) reverse(56bitstring); ;; odd=0
reverse(56bitstring)
;; 56bitstring after reverse
;; 1011001 0111010 1000001 0111001 1010001 0001001
;; 0010101 1000001
odd = ! odd
tempstring = tempstring XOR 56bitstring;
;; tempstring
;; 0101001 1011011 0110010 1001010 0100110 1100110
;; 1100111 0100101
for (8byteblock in s) {
;; loop iteration 2
;; 8byteblock:
;; `IT.EDUra' (length 8 bytes)
;; 49 54 2e 45 44 55 72 61
;; 01001001 01010100 00101110 01000101 01000100 01010101
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
;; 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
if (odd == 0) reverse(56bitstring); ;; odd=1
odd = ! odd
tempstring = tempstring XOR 56bitstring;
;; tempstring
;; 1100000 0001111 0011100 0001111 1100010 0110011
;; 0010101 1000100
for (8byteblock in s) {
;; loop iteration 3
;; 8byteblock:
;; `eburn\x00\x00\x00' (length 8 bytes)
;; 65 62 75 72 6e 00 00 00
;; 01100101 01100010 01110101 01110010 01101110 00000000
;; 00000000 00000000
56bitstring = removeMSBits(8byteblock);
;; 56bitstring:
;; 1100101 1100010 1110101 1110010 1101110 0000000
;; 0000000 0000000
if (odd == 0) reverse(56bitstring); ;; odd=0
reverse(56bitstring)
;; 56bitstring after reverse
;; 0000000 0000000 0000000 0111011 0100111 1010111
;; 0100011 1010011
odd = ! odd
tempstring = tempstring XOR 56bitstring;
;; tempstring
;; 1100000 0001111 0011100 0110100 1000101 1100100
;; 0110110 0010111
for (8byteblock in s) {
;; loop iteration 3
;; 8byteblock:
;; `eburn\x00\x00\x00' (length 8 bytes)
;; 65 62 75 72 6e 00 00 00
;; 01100101 01100010 01110101 01110010 01101110 00000000
;; 00000000 00000000
56bitstring = removeMSBits(8byteblock);
;; 56bitstring:
;; 1100101 1100010 1110101 1110010 1101110 0000000
;; 0000000 0000000
if (odd == 0) reverse(56bitstring); ;; odd=0
reverse(56bitstring)
;; 56bitstring after reverse
;; 0000000 0000000 0000000 0111011 0100111 1010111
;; 0100011 1010011
odd = ! odd
tempstring = tempstring XOR 56bitstring;
;; tempstring
;; 1100000 0001111 0011100 0110100 1000101 1100100
;; 0110110 0010111
for (8byteblock in s) {
}
;; for loop terminated
for (8byteblock in s) {
}
;; for loop terminated
tempkey = key_correction(add_parity_bits(tempstring));
;; tempkey
;; `\xc1\x1f8h\x8a\xc8m\x2f' (length 8 bytes)
;; c1 1f 38 68 8a c8 6d 2f
;; 11000001 00011111 00111000 01101000 10001010 11001000
;; 01101101 00101111
tempkey = key_correction(add_parity_bits(tempstring));
;; tempkey
;; `\xc1\x1f8h\x8a\xc8m\x2f' (length 8 bytes)
;; c1 1f 38 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)
key = key_correction(DES-CBC-check(s,tempkey));
;; key
;; `\xcb\xc2\x2f\xae\x23R\x98\xe3' (length 8 bytes)
;; cb c2 2f ae 23 52 98 e3
;; 11001011 11000010 00101111 10101110 00100011 01010010
;; 10011000 11100011
;; cb c2 2f ae 23 52 98 e3
;; 11001011 11000010 00101111 10101110 00100011 01010010
;; 10011000 11100011
;; string_to_key key:
;; `\xcb\xc2\x2f\xae\x23R\x98\xe3' (length 8 bytes)
;; cb c2 2f ae 23 52 98 e3
;; string_to_key key:
;; `\xcb\xc2\x2f\xae\x23R\x98\xe3' (length 8 bytes)
;; cb c2 2f ae 23 52 98 e3
These tests show the derived-random and derived-key values for the des3-hmac-sha1-kd encryption scheme, using the DR and DK functions defined in section 6.3.1. The input keys were randomly generated; the usage values are from this specification.
这些测试使用第6.3.1节中定义的DR和DK函数显示des3-hmac-sha1-kd加密方案的衍生随机和衍生密钥值。随机生成输入键；使用值来自此规范。
key: dce06b1f64c857a11c3db57c51899b2cc1791008ce973b92
usage: 0000000155
DR: 935079d14490a75c3093c4a6e8c3b049c71e6ee705
DK: 925179d04591a79b5d3192c4a7e9c289b049c71f6ee604cd
key: dce06b1f64c857a11c3db57c51899b2cc1791008ce973b92
usage: 0000000155
DR: 935079d14490a75c3093c4a6e8c3b049c71e6ee705
DK: 925179d04591a79b5d3192c4a7e9c289b049c71f6ee604cd
key: 5e13d31c70ef765746578531cb51c15bf11ca82c97cee9f2
usage: 00000001aa
DR: 9f58e5a047d894101c469845d67ae3c5249ed812f2
DK: 9e58e5a146d9942a101c469845d67a20e3c4259ed913f207
key: 5e13d31c70ef765746578531cb51c15bf11ca82c97cee9f2
usage: 00000001aa
DR: 9f58e5a047d894101c469845d67ae3c5249ed812f2
DK: 9e58e5a146d9942a101c469845d67a20e3c4259ed913f207
key: 98e6fd8a04a4b6859b75a176540b9752bad3ecd610a252bc
usage: 0000000155
DR: 12fff90c773f956d13fc2ca0d0840349dbd39908eb
DK: 13fef80d763e94ec6d13fd2ca1d085070249dad39808eabf
key: 98e6fd8a04a4b6859b75a176540b9752bad3ecd610a252bc
usage: 0000000155
DR: 12fff90c773f956d13fc2ca0d0840349dbd39908eb
DK: 13fef80d763e94ec6d13fd2ca1d085070249dad39808eabf
key: 622aec25a2fe2cad7094680b7c64940280084c1a7cec92b5
usage: 00000001aa
DR: f8debf05b097e7dc0603686aca35d91fd9a5516a70
DK: f8dfbf04b097e6d9dc0702686bcb3489d91fd9a4516b703e
key: 622aec25a2fe2cad7094680b7c64940280084c1a7cec92b5
usage: 00000001aa
DR: f8debf05b097e7dc0603686aca35d91fd9a5516a70
DK: f8dfbf04b097e6d9dc0702686bcb3489d91fd9a4516b703e
key: d3f8298ccb166438dcb9b93ee5a7629286a491f838f802fb
usage: 6b65726265726f73 ("kerberos")
DR: 2270db565d2a3d64cfbfdc5305d4f778a6de42d9da
DK: 2370da575d2a3da864cebfdc5204d56df779a7df43d9da43
key: d3f8298ccb166438dcb9b93ee5a7629286a491f838f802fb
usage: 6b65726265726f73 ("kerberos")
DR: 2270db565d2a3d64cfbfdc5305d4f778a6de42d9da
DK: 2370da575d2a3da864cebfdc5204d56df779a7df43d9da43
key: c1081649ada74362e6a1459d01dfd30d67c2234c940704da
usage: 0000000155
DR: 348056ec98fcc517171d2b4d7a9493af482d999175
DK: 348057ec98fdc48016161c2a4c7a943e92ae492c989175f7
key: c1081649ada74362e6a1459d01dfd30d67c2234c940704da
usage: 0000000155
DR: 348056ec98fcc517171d2b4d7a9493af482d999175
DK: 348057ec98fdc48016161c2a4c7a943e92ae492c989175f7
key: 5d154af238f46713155719d55e2f1f790dd661f279a7917c
usage: 00000001aa
DR: a8818bc367dadacbe9a6c84627fb60c294b01215e5
key: 5d154af238f46713155719d55e2f1f790dd661f279a7917c
usage: 00000001aa
DR: a8818bc367dadacbe9a6c84627fb60c294b01215e5
DK: a8808ac267dada3dcbe9a7c84626fbc761c294b01315e5c1
DK: a8808ac267dada3dcbe9a7c84626fbc761c294b01315e5c1
key: 798562e049852f57dc8c343ba17f2ca1d97394efc8adc443
usage: 0000000155
DR: c813f88b3be2b2f75424ce9175fbc8483b88c8713a
DK: c813f88a3be3b334f75425ce9175fbe3c8493b89c8703b49
key: 798562e049852f57dc8c343ba17f2ca1d97394efc8adc443
usage: 0000000155
DR: c813f88b3be2b2f75424ce9175fbc8483b88c8713a
DK: c813f88a3be3b334f75425ce9175fbe3c8493b89c8703b49
key: 26dce334b545292f2feab9a8701a89a4b99eb9942cecd016
usage: 00000001aa
DR: f58efc6f83f93e55e695fd252cf8fe59f7d5ba37ec
DK: f48ffd6e83f83e7354e694fd252cf83bfe58f7d5ba37ec5d
key: 26dce334b545292f2feab9a8701a89a4b99eb9942cecd016
usage: 00000001aa
DR: f58efc6f83f93e55e695fd252cf8fe59f7d5ba37ec
DK: f48ffd6e83f83e7354e694fd252cf83bfe58f7d5ba37ec5d
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.
这些是为上述三重DES输入字符串生成的键，其键派生如第6.3.1节所定义。
salt: "ATHENA.MIT.EDUraeburn"
passwd: "password"
key: 850bb51358548cd05e86768c313e3bfef7511937dcf72c3e
salt: "ATHENA.MIT.EDUraeburn"
passwd: "password"
key: 850bb51358548cd05e86768c313e3bfef7511937dcf72c3e
salt: "WHITEHOUSE.GOVdanny"
passwd: "potatoe"
key: dfcd233dd0a43204ea6dc437fb15e061b02979c1f74f377a
salt: "WHITEHOUSE.GOVdanny"
passwd: "potatoe"
key: dfcd233dd0a43204ea6dc437fb15e061b02979c1f74f377a
salt: "EXAMPLE.COMbuckaroo"
passwd: "penny"
key: 6d2fcdf2d6fbbc3ddcadb5da5710a23489b0d3b69d5d9d4a
salt: "EXAMPLE.COMbuckaroo"
passwd: "penny"
key: 6d2fcdf2d6fbbc3ddcadb5da5710a23489b0d3b69d5d9d4a
salt: "ATHENA.MIT.EDUJuri" + s-caron(U+0161) + "i"
+ c-acute(U+0107)
passwd: eszett(U+00DF)
key: 16d5a40e1ce3bacb61b9dce00470324c831973a7b952feb0
salt: "ATHENA.MIT.EDUJuri" + s-caron(U+0161) + "i"
+ c-acute(U+0107)
passwd: eszett(U+00DF)
key: 16d5a40e1ce3bacb61b9dce00470324c831973a7b952feb0
salt: "EXAMPLE.COMpianist"
passwd: g-clef(U+1011E)
key: 85763726585dbc1cce6ec43e1f751f07f1c4cbb098f40b19
salt: "EXAMPLE.COMpianist"
passwd: g-clef(U+1011E)
key: 85763726585dbc1cce6ec43e1f751f07f1c4cbb098f40b19
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和八位字节字符串的modified-CRC32值。只有可打印的ASCII字符进行校验和，没有C样式的尾随零值八位字节。下面显示了Kerberos中使用的32位修改CRC和输出字节序列。（此处分隔八位字节值是为了强调它们是八位字节值，而不是32位数字，这在某些实现中是最方便的操作形式。使用的位和字节顺序
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
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
B. Significant Changes from RFC 1510
B.与RFC 1510相比的重大变化
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]中的一些消息定义可以理解为允许应用程序指定初始向量；文本太模糊了。本规范中明确不允许这样做。某些加密算法可能不使用初始化向量，因此依靠选定的、秘密的初始化向量进行安全保护是不明智的。此外，现有算法中预先设置的混淆大致相当于以加密形式显示的每消息初始化向量。但是，通过不透明的“cipher state”对象明确允许将状态从一种加密传输到另一种加密。
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 string to key和crc描述已更新，以使其与现有实现保持一致。
[Kerb1510] did not indicate what character set or encoding might be used for pass phrases and salts.
[Kerb1510]未指明pass短语和SALT可能使用的字符集或编码。
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]中，密钥类型、加密算法和校验和算法只是松散地关联在一起，这种关联没有得到很好的描述。在本规范中，密钥类型和加密算法具有一对一的对应关系，并且描述了加密和校验和算法之间的关联，以便可以在给定协商密钥的情况下计算校验和，而无需进一步协商校验和类型。
Notes
笔记
[1] Although Message Authentication Code (MAC) or Message Integrity Check (MIC) would be more appropriate terms for many of the uses in this document, we continue to use the term checksum for historical reasons.
[1] 虽然消息身份验证码（MAC）或消息完整性检查（MIC）对于本文档中的许多用途来说更合适，但出于历史原因，我们继续使用校验和这一术语。
[2] Extending CBC mode across messages would be one obvious example of this chaining. Another might be the use of counter mode, with a counter randomly initialized and attached to the ciphertext; a second message could continue incrementing the counter when chaining the cipher state, thus avoiding having to transmit another counter value. However, this chaining is only useful for uninterrupted, ordered sequences of messages.
[2] 跨消息扩展CBC模式将是这种链接的一个明显例子。另一种可能是使用计数器模式，计数器随机初始化并连接到密文；第二条消息可以在链接密码状态时继续递增计数器，从而避免必须传输另一个计数器值。但是，这种链接仅对不间断、有序的消息序列有用。
[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] 在Kerberos的情况下，加密对象通常是ASN.1 DER编码，它在前几个八位字节中包含长度指示。
[4] As of the time of this writing, new modes of operation have been proposed, some of which may permit encryption and integrity protection simultaneously. After some of these proposals have been subjected to adequate analysis, we may wish to formulate a new simplified profile based on one of them.
[4] 截至撰写本文时，已经提出了新的操作模式，其中一些模式可能允许同时进行加密和完整性保护。在对其中一些建议进行充分分析之后，我们不妨在其中一项建议的基础上制定一个新的简化概况。
[5] It should be noted that the sample vector in appendix B.2 of the original paper appears to be incorrect. Two independent implementations from the specification (one in C by Marc Horowitz, and another in Scheme by Bill Sommerfeld) agree on a value different from that in [Blumenthal96].
[5] 应注意，原始文件附录B.2中的样本向量似乎不正确。规范中的两个独立实现（一个是Marc Horowitz在C中的实现，另一个是Bill Sommerfeld在Scheme中的实现）同意了与[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无眼校验和可以包括在服务密钥中加密的验证器中。
[7] Using a variant of the key limits the use of a key to a particular function, separating the functions of generating a
[7] 使用键的变体将键的使用限制为特定功能，从而将生成
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.
使用会话密钥执行的其他加密的校验和。选择常量0xF0是因为它保持键奇偶校验。DES的性质排除了补语的使用。在隐私增强邮件标准中的邮件完整性检查中，相同的常量用于类似目的。
[8] Perhaps one of the more common reasons for directly performing encryption is direct control over the negotiation and to select a "sufficiently strong" encryption algorithm (whatever that means in the context of a given application). Although Kerberos directly provides no direct facility for negotiating encryption types between the application client and server, there are other means to accomplish similar goals (for example, requesting only "strong" session key types from the KDC, and assuming that the type actually returned by the KDC will be understood and supported by the application server).
[8] 直接执行加密的一个更常见的原因可能是直接控制协商并选择“足够强”的加密算法（无论在给定应用程序的上下文中这意味着什么）。尽管Kerberos没有直接提供用于在应用程序客户端和服务器之间协商加密类型的工具，但是还有其他方法可以实现类似的目标（例如，仅请求“强”来自KDC的会话密钥类型，并假设KDC实际返回的类型将被应用程序服务器理解和支持）。
Normative References
规范性引用文件
[BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[BCP26]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，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.，Desai，A.，Pointcheval，D.，和P.Rogaway，“公钥加密方案安全概念之间的关系”。扩展摘要发表于《密码学进展》Crypto 98会议录，《计算机科学课堂讲稿》第1462卷，H.Krawcyzk ed.，Springer Verlag，1998年。
[Blumenthal96] Blumenthal, U. and S. Bellovin, "A Better Key Schedule for DES-Like Ciphers", Proceedings of PRAGOCRYPT '96, 1996.
[Blumenthal96]Blumenthal，U.和S.Bellovin，“类似DES密码的更好密钥调度”，PRAGOCRYPT'961996年论文集。
[CRC] International Organization for Standardization, "ISO Information Processing Systems - Data Communication - High-Level Data Link Control Procedure - Frame Structure," IS 3309, 3rd Edition, October 1984.
[CRC]国际标准化组织，“ISO信息处理系统-数据通信-高级数据链路控制程序-帧结构”，IS 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，华盛顿特区，1977年。
[DESI81] National Bureau of Standards, U.S. Department of Commerce, "Guidelines for implementing and using NBS Data Encryption Standard," Federal Information Processing Standards Publication 74, Washington, DC, 1981.
[DESI81]美国商务部国家标准局，“实施和使用NBS数据加密标准的指南”，联邦信息处理标准出版物74，华盛顿特区，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，弗吉尼亚州斯普林菲尔德，1980年12月。
[Dolev91] Dolev, D., Dwork, C., and M. Naor, "Non-malleable cryptography", Proceedings of the 23rd Annual Symposium on Theory of Computing, ACM, 1991.
[Dolev91]Dolev，D.，Dwork，C.，和M.Naor，“不可延展的密码学”，第23届计算理论年度研讨会论文集，ACM，1991年。
[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[HMAC]Krawczyk，H.，Bellare，M.，和R.Canetti，“HMAC：用于消息身份验证的键控哈希”，RFC 2104，1997年2月。
[KRB5-AES] Raeburn, K., "Advanced Encryption Standard (AES) Encryption for Kerberos 5", RFC 3962, February 2005.
[KRB5-AES]Raeburn，K.，“Kerberos 5的高级加密标准（AES）加密”，RFC 3962，2005年2月。
[MD4-92] Rivest, R., "The MD4 Message-Digest Algorithm", RFC 1320, April 1992.
[MD4-92]Rivest，R.，“MD4消息摘要算法”，RFC 1320，1992年4月。
[MD5-92] Rivest, R., "The MD5 Message-Digest Algorithm ", RFC 1321, April 1992.
[MD5-92]Rivest，R.，“MD5消息摘要算法”，RFC 13211992年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]Stubblebine，S.和V.D.Gligor，“密码协议中的消息完整性”，发表于1992年5月在加利福尼亚州奥克兰举行的IEEE安全和隐私研究研讨会论文集。
Informative References
资料性引用
[Bellovin91] Bellovin, S. M. and M. Merrit, "Limitations of the Kerberos Authentication System", in Proceedings of the Winter 1991 Usenix Security Conference, January, 1991.
[Bellovin91]Bellovin，S.M.和M.Merrit，“Kerberos身份验证系统的局限性”，1991年1月，1991年冬季Usenix安全会议记录。
[Bellovin99] Bellovin, S. M. and D. Atkins, private communications, 1999.
[Bellovin99]Bellovin，S.M.和D.Atkins，私人通信，1999年。
[EFF-DES] Electronic Frontier Foundation, "Cracking DES: Secrets of Encryption Research, Wiretap Politics, and Chip Design", O'Reilly & Associates, Inc., May 1998.
[Eff-DE]电子前沿基金会，“破解DES：加密研究的秘密，窃听政治和芯片设计”，O'ReLy＆Associates，Inc.，1998年5月。
[ESP-DES] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm With Explicit IV", RFC 2405, November 1998.
[ESP-DES]Madson，C.和N.Doraswamy，“带显式IV的ESP-DES-CBC密码算法”，RFC 2405，1998年11月。
[GSS-KRB5] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, June 1996.
[GSS-KRB5]Linn，J.，“Kerberos版本5 GSS-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-TEST]Cheng，P.和R.Glenn，“HMAC-MD5和HMAC-SHA-1的测试案例”，RFC 2202，1997年9月。
[IPSEC-HMAC] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.
[IPSEC-HMAC]Madson，C.和R.Glenn，“在ESP和AH中使用HMAC-SHA-1-96”，RFC 2404，1998年11月。
[Kerb] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", Work in Progress, September 2004.
[Kerb]Neuman，C.，Yu，T.，Hartman，S.，和K.Raeburn，“Kerberos网络身份验证服务（V5）”，正在进行的工作，2004年9月。
[Kerb1510] Kohl, J. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993.
[Kerb1510]Kohl，J.和C.Neuman，“Kerberos网络身份验证服务（V5）”，RFC15101993年9月。
[RC5] Baldwin, R. and R. Rivest, "The RC5, RC5-CBC, RC5- CBC-Pad, and RC5-CTS Algorithms", RFC 2040, October 1996.
[RC5]Baldwin，R.和R.Rivest，“RC5、RC5-CBC、RC5-CBC Pad和RC5-CTS算法”，RFC 2040，1996年10月。
[RFC1851] Karn, P., Metzger, P., and W. Simpson, "The ESP Triple DES Transform", RFC 1851, September 1995.
[RFC1851]Karn，P.，Metzger，P.，和W.Simpson，“ESP三重DES变换”，RFC 18511995年9月。
[Schneier96] Schneier, B., "Applied Cryptography Second Edition", John Wiley & Sons, New York, NY, 1996. ISBN 0-471- 12845-7.
[Schneier96]Schneier，B.，“应用密码学第二版”，John Wiley&Sons，纽约，1996年。ISBN 0-471-12845-7。
Editor's Address
编辑地址
Kenneth Raeburn Massachusetts Institute of Technology 77 Massachusetts Avenue Cambridge, MA 02139
肯尼斯·雷伯恩麻省理工学院马萨诸塞大道77号马萨诸塞州剑桥，邮编02139
EMail: raeburn@mit.edu
EMail: raeburn@mit.edu
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关IETF文件中权利的IETF程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。