Internet Engineering Task Force (IETF) H. Krawczyk
Request for Comments: 5869 IBM Research
Category: Informational P. Eronen
ISSN: 2070-1721 Nokia
May 2010
Internet Engineering Task Force (IETF) H. Krawczyk
Request for Comments: 5869 IBM Research
Category: Informational P. Eronen
ISSN: 2070-1721 Nokia
May 2010
HMAC-based Extract-and-Expand Key Derivation Function (HKDF)
基于HMAC的提取和扩展密钥派生函数（HKDF）
Abstract
摘要
This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions.
本文档指定了一个基于简单哈希消息身份验证码（HMAC）的密钥派生函数（HKDF），该函数可以用作各种协议和应用程序中的构建块。密钥派生函数（KDF）旨在支持广泛的应用和需求，并且在使用加密哈希函数时是保守的。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5869.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5869.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
A key derivation function (KDF) is a basic and essential component of cryptographic systems. Its goal is to take some source of initial keying material and derive from it one or more cryptographically strong secret keys.
密钥派生函数（KDF）是密码系统的基本组成部分。它的目标是获取初始密钥材料的某些来源，并从中派生出一个或多个加密强密钥。
This document specifies a simple HMAC-based [HMAC] KDF, named HKDF, which can be used as a building block in various protocols and applications, and is already used in several IETF protocols, including [IKEv2], [PANA], and [EAP-AKA]. The purpose is to document this KDF in a general way to facilitate adoption in future protocols and applications, and to discourage the proliferation of multiple KDF mechanisms. It is not intended as a call to change existing protocols and does not change or update existing specifications using this KDF.
本文件规定了一个简单的基于HMAC的[HMAC]KDF，名为HKDF，可在各种协议和应用中用作构建块，并已在多个IETF协议中使用，包括[IKEv2]、[PANA]和[EAP-AKA]。目的是以一种通用的方式记录此KDF，以便于在未来的协议和应用程序中采用，并阻止多种KDF机制的扩散。它不打算作为更改现有协议的调用，也不使用此KDF更改或更新现有规范。
HKDF follows the "extract-then-expand" paradigm, where the KDF logically consists of two modules. The first stage takes the input keying material and "extracts" from it a fixed-length pseudorandom key K. The second stage "expands" the key K into several additional pseudorandom keys (the output of the KDF).
HKDF遵循“先提取后扩展”的模式，KDF在逻辑上由两个模块组成。第一阶段获取输入的键控材料并从中“提取”固定长度的伪随机密钥K。第二阶段将密钥K“扩展”为几个额外的伪随机密钥（KDF的输出）。
In many applications, the input keying material is not necessarily distributed uniformly, and the attacker may have some partial knowledge about it (for example, a Diffie-Hellman value computed by a key exchange protocol) or even partial control of it (as in some entropy-gathering applications). Thus, the goal of the "extract" stage is to "concentrate" the possibly dispersed entropy of the input keying material into a short, but cryptographically strong, pseudorandom key. In some applications, the input may already be a good pseudorandom key; in these cases, the "extract" stage is not necessary, and the "expand" part can be used alone.
在许多应用中，输入密钥材料不一定均匀分布，攻击者可能对其有部分了解（例如，通过密钥交换协议计算的Diffie-Hellman值），甚至对其有部分控制（如在一些熵收集应用中）。因此，“提取”阶段的目标是将输入密钥材料可能分散的熵“集中”到一个短的、但加密性强的伪随机密钥中。在一些应用中，输入可能已经是一个好的伪随机密钥；在这些情况下，不需要“提取”阶段，“扩展”部分可以单独使用。
The second stage "expands" the pseudorandom key to the desired length; the number and lengths of the output keys depend on the specific cryptographic algorithms for which the keys are needed.
第二阶段将伪随机密钥“扩展”到所需长度；输出密钥的数量和长度取决于需要密钥的特定加密算法。
Note that some existing KDF specifications, such as NIST Special Publication 800-56A [800-56A], NIST Special Publication 800-108 [800-108] and IEEE Standard 1363a-2004 [1363a], either only consider the second stage (expanding a pseudorandom key), or do not explicitly differentiate between the "extract" and "expand" stages, often resulting in design shortcomings. The goal of this specification is to accommodate a wide range of KDF requirements while minimizing the assumptions about the underlying hash function. The "extract-then-expand" paradigm supports well this goal (see [HKDF-paper] for more information about the design rationale).
请注意，一些现有的KDF规范，如NIST特别出版物800—56A[800—56A]、NIST特别出版物800—108 [800—108]和IEEE标准1363A—2004 [1363A]，只考虑第二阶段（扩展伪随机密钥），或者没有明确区分“提取”和“扩展”阶段，经常导致设计缺陷。本规范的目标是适应广泛的KDF需求，同时最小化关于底层哈希函数的假设。“先提取后扩展”范式很好地支持了这一目标（有关设计原理的更多信息，请参见[HKDF论文”）。
HMAC-Hash denotes the HMAC function [HMAC] instantiated with hash function 'Hash'. HMAC always has two arguments: the first is a key and the second an input (or message). (Note that in the extract step, 'IKM' is used as the HMAC input, not as the HMAC key.)
HMAC哈希表示用哈希函数“Hash”实例化的HMAC函数[HMAC]。HMAC总是有两个参数：第一个是键，第二个是输入（或消息）。（请注意，在提取步骤中，“IKM”用作HMAC输入，而不是HMAC键。）
When the message is composed of several elements we use concatenation (denoted |) in the second argument; for example, HMAC(K, elem1 | elem2 | elem3).
当消息由几个元素组成时，我们在第二个参数中使用串联（表示为|）；例如，HMAC（K，elem1 | elem2 | elem3）。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[关键词]中所述进行解释。
HKDF-Extract(salt, IKM) -> PRK
HKDF-Extract(salt, IKM) -> PRK
Options: Hash a hash function; HashLen denotes the length of the hash function output in octets
选项：散列一个散列函数；HashLen表示哈希函数输出的长度（以八位字节为单位）
Inputs: salt optional salt value (a non-secret random value); if not provided, it is set to a string of HashLen zeros. IKM input keying material
输入：salt可选salt值（非秘密随机值）；如果未提供，则将其设置为HashLen零字符串。输入键控材料
Output: PRK a pseudorandom key (of HashLen octets)
输出：PRK伪随机密钥（HashLen八位字节）
The output PRK is calculated as follows:
输出PRK的计算如下：
PRK = HMAC-Hash(salt, IKM)
PRK=HMAC散列（盐，IKM）
HKDF-Expand(PRK, info, L) -> OKM
HKDF-Expand(PRK, info, L) -> OKM
Options: Hash a hash function; HashLen denotes the length of the hash function output in octets
选项：散列一个散列函数；HashLen表示哈希函数输出的长度（以八位字节为单位）
Inputs: PRK a pseudorandom key of at least HashLen octets (usually, the output from the extract step) info optional context and application specific information (can be a zero-length string) L length of output keying material in octets (<= 255*HashLen)
输入：PRK至少包含HashLen八位字节的伪随机密钥（通常是提取步骤的输出）信息可选上下文和应用程序特定信息（可以是零长度字符串）L长度的输出键控材料（八位字节）（<=255*HashLen）
Output: OKM output keying material (of L octets)
输出：OKM输出键控材料（共L个八位字节）
The output OKM is calculated as follows:
输出OKM的计算如下：
N = ceil(L/HashLen)
T = T(1) | T(2) | T(3) | ... | T(N)
OKM = first L octets of T
N = ceil(L/HashLen)
T = T(1) | T(2) | T(3) | ... | T(N)
OKM = first L octets of T
where: T(0) = empty string (zero length) T(1) = HMAC-Hash(PRK, T(0) | info | 0x01) T(2) = HMAC-Hash(PRK, T(1) | info | 0x02) T(3) = HMAC-Hash(PRK, T(2) | info | 0x03) ...
其中：T（0）=空字符串（零长度）T（1）=HMAC哈希（PRK，T（0）|信息| 0x01）T（2）=HMAC哈希（PRK，T（1）|信息| 0x02）T（3）=HMAC哈希（PRK，T（2）|信息| 0x03）。。。
(where the constant concatenated to the end of each T(n) is a single octet.)
（其中连接到每个T（n）末尾的常数是一个八位字节。）
This section contains a set of guiding principles regarding the use of HKDF. A much more extensive account of such principles and design rationale can be found in [HKDF-paper].
本节包含一套有关使用HKDF的指导原则。[HKDF文件]中对这些原则和设计原理有更广泛的说明。
HKDF is defined to operate with and without random salt. This is done to accommodate applications where a salt value is not available. We stress, however, that the use of salt adds significantly to the strength of HKDF, ensuring independence between different uses of the hash function, supporting "source-independent" extraction, and strengthening the analytical results that back the HKDF design.
HKDF被定义为在有无随机盐的情况下运行。这样做是为了适应盐值不可用的应用。然而，我们强调，salt的使用大大增强了HKDF的强度，确保了散列函数不同用途之间的独立性，支持“源独立”提取，并加强了支持HKDF设计的分析结果。
Random salt differs fundamentally from the initial keying material in two ways: it is non-secret and can be re-used. As such, salt values are available to many applications. For example, a pseudorandom number generator (PRNG) that continuously produces outputs by applying HKDF to renewable pools of entropy (e.g., sampled system events) can fix a salt value and use it for multiple applications of
随机salt在两个方面与初始键控材质有根本区别：它是非机密的，可以重复使用。因此，盐值可用于许多应用。例如，通过将HKDF应用于可更新的熵池（例如，采样系统事件），连续产生输出的伪随机数生成器（PRNG）可以修复salt值，并将其用于多个应用
HKDF without having to protect the secrecy of the salt. In a different application domain, a key agreement protocol deriving cryptographic keys from a Diffie-Hellman exchange can derive a salt value from public nonces exchanged and authenticated between communicating parties as part of the key agreement (this is the approach taken in [IKEv2]).
HKDF无需保护盐的机密性。在不同的应用领域中，从Diffie-Hellman交换中导出加密密钥的密钥协商协议可以从作为密钥协商的一部分在通信各方之间交换和认证的公共时值中导出salt值（这是[IKEv2]中采用的方法）。
Ideally, the salt value is a random (or pseudorandom) string of the length HashLen. Yet, even a salt value of less quality (shorter in size or with limited entropy) may still make a significant contribution to the security of the output keying material; designers of applications are therefore encouraged to provide salt values to HKDF if such values can be obtained by the application.
理想情况下，salt值是长度为HashLen的随机（或伪随机）字符串。然而，即使质量较低（尺寸较短或熵有限）的盐值也可能对输出键控材料的安全性做出重大贡献；因此，如果应用程序可以获得盐值，则鼓励应用程序设计人员向HKDF提供盐值。
It is worth noting that, while not the typical case, some applications may even have a secret salt value available for use; in such a case, HKDF provides an even stronger security guarantee. An example of such application is IKEv1 in its "public-key encryption mode", where the "salt" to the extractor is computed from nonces that are secret; similarly, the pre-shared mode of IKEv1 uses a secret salt derived from the pre-shared key.
值得注意的是，虽然不是典型情况，但某些应用程序甚至可能具有可供使用的秘密盐值；在这种情况下，香港国防军提供了更强有力的安全保障。此类应用的一个示例是处于其“公钥加密模式”的IKEv1，其中对提取器的“salt”是从秘密的nonce计算的；类似地，IKEv1的预共享模式使用从预共享密钥派生的秘密salt。
While the 'info' value is optional in the definition of HKDF, it is often of great importance in applications. Its main objective is to bind the derived key material to application- and context-specific information. For example, 'info' may contain a protocol number, algorithm identifiers, user identities, etc. In particular, it may prevent the derivation of the same keying material for different contexts (when the same input key material (IKM) is used in such different contexts). It may also accommodate additional inputs to the key expansion part, if so desired (e.g., an application may want to bind the key material to its length L, thus making L part of the 'info' field). There is one technical requirement from 'info': it should be independent of the input key material value IKM.
虽然“info”值在HKDF的定义中是可选的，但它在应用程序中通常非常重要。它的主要目标是将派生的关键材料与应用程序和上下文特定的信息绑定在一起。例如，“info”可包含协议编号、算法标识符、用户身份等。具体而言，它可防止为不同上下文派生相同的密钥材料（当相同的输入密钥材料（IKM）在此类不同上下文中使用时）。如果需要，它还可以容纳密钥扩展部分的额外输入（例如，应用程序可能希望将密钥材料绑定到其长度L，从而使L成为“信息”字段的一部分）。“信息”中有一个技术要求：它应该独立于输入的关键材料值IKM。
In some applications, the input key material IKM may already be present as a cryptographically strong key (for example, the premaster secret in TLS RSA cipher suites would be a pseudorandom string, except for the first two octets). In this case, one can skip the extract part and use IKM directly to key HMAC in the expand step. On the other hand, applications may still use the extract part for the sake of compatibility with the general case. In particular, if IKM is random (or pseudorandom) but longer than an HMAC key, the extract step can serve to output a suitable HMAC key (in the case of HMAC
在一些应用中，输入密钥材料IKM可能已经作为加密强密钥存在（例如，TLS RSA密码套件中的premaster秘密将是伪随机字符串，前两个八位字节除外）。在这种情况下，可以跳过提取部分，在展开步骤中直接使用IKM键HMAC。另一方面，为了与一般情况兼容，应用程序仍然可以使用提取部分。特别地，如果IKM是随机（或伪随机）但长于HMAC密钥，则提取步骤可用于输出合适的HMAC密钥（在HMAC的情况下）
this shortening via the extractor is not strictly necessary since HMAC is defined to work with long keys too). Note, however, that if the IKM is a Diffie-Hellman value, as in the case of TLS with Diffie-Hellman, then the extract part SHOULD NOT be skipped. Doing so would result in using the Diffie-Hellman value g^{xy} itself (which is NOT a uniformly random or pseudorandom string) as the key PRK for HMAC. Instead, HKDF should apply the extract step to g^{xy} (preferably with a salt value) and use the resultant PRK as a key to HMAC in the expansion part.
由于HMAC也被定义为与长键一起工作，因此通过提取器进行缩短并非绝对必要）。但是，请注意，如果IKM是Diffie-Hellman值，如使用Diffie-Hellman的TLS，则不应跳过提取部分。这样做将导致使用Diffie-Hellman值g^{xy}本身（它不是一致随机或伪随机字符串）作为HMAC的密钥PRK。相反，HKDF应将提取步骤应用于g^{xy}（最好具有盐值），并将生成的PRK用作扩展部分中HMAC的键。
In the case where the amount of required key bits, L, is no more than HashLen, one could use PRK directly as the OKM. This, however, is NOT RECOMMENDED, especially because it would omit the use of 'info' as part of the derivation process (and adding 'info' as an input to the extract step is not advisable -- see [HKDF-paper]).
在所需密钥比特量L不超过HashLen的情况下，可以直接使用PRK作为OKM。但是，不建议这样做，特别是因为这样做会在派生过程中省略“info”的使用（并且不建议在提取步骤中添加“info”作为输入，请参见[HKDF论文]）。
The analysis of key derivation functions assumes that the input keying material (IKM) comes from some source modeled as a probability distribution over bit streams of a certain length (e.g., streams produced by an entropy pool, values derived from Diffie-Hellman exponents chosen at random, etc.); each instance of IKM is a sample from that distribution. A major goal of key derivation functions is to ensure that, when applying the KDF to any two values IKM and IKM' sampled from the (same) source distribution, the resultant keys OKM and OKM' are essentially independent of each other (in a statistical or computational sense). To achieve this goal, it is important that inputs to KDF are selected from appropriate input distributions and also that inputs are chosen independently of each other (technically, it is necessary that each sample will have sufficient entropy, even when conditioned on other inputs to KDF).
密钥推导函数的分析假设输入密钥材料（IKM）来自某个源，该源被建模为特定长度比特流上的概率分布（例如，熵池产生的流、随机选择的Diffie-Hellman指数得出的值等）；IKM的每个实例都是该分布的一个样本。密钥推导函数的主要目标是确保当将KDF应用于从（相同）源分布中采样的任意两个值IKM和IKM'时，生成的密钥OKM和OKM'基本上彼此独立（在统计或计算意义上）。为了实现这一目标，重要的是从适当的输入分布中选择KDF的输入，并且输入是相互独立选择的（从技术上讲，每个样本都必须有足够的熵，即使在以KDF的其他输入为条件时也是如此）。
Independence is also an important aspect of the salt value provided to a KDF. While there is no need to keep the salt secret, and the same salt value can be used with multiple IKM values, it is assumed that salt values are independent of the input keying material. In particular, an application needs to make sure that salt values are not chosen or manipulated by an attacker. As an example, consider the case (as in IKE) where the salt is derived from nonces supplied by the parties in a key exchange protocol. Before the protocol can use such salt to derive keys, it needs to make sure that these nonces are authenticated as coming from the legitimate parties rather than selected by the attacker (in IKE, for example this authentication is an integral part of the authenticated Diffie-Hellman exchange).
独立性也是提供给KDF的盐值的一个重要方面。虽然不需要对salt保密，并且相同的salt值可以与多个IKM值一起使用，但假定salt值独立于输入键控材质。特别是，应用程序需要确保salt值未被攻击者选择或操纵。作为一个例子，考虑的情况下（如在IKE）中，盐是从在密钥交换协议中由各方提供的NOCES派生的。在协议可以使用这种salt来派生密钥之前，它需要确保这些nonce被认证为来自合法方，而不是被攻击者选择（例如，在IKE中，这种认证是经过认证的Diffie-Hellman交换的一个组成部分）。
HKDF is intended for use in a wide variety of KDF applications. These include the building of pseudorandom generators from imperfect sources of randomness (such as a physical random number generator (RNG)); the generation of pseudorandomness out of weak sources of randomness, such as entropy collected from system events, user's keystrokes, etc.; the derivation of cryptographic keys from a shared Diffie-Hellman value in a key-agreement protocol; derivation of symmetric keys from a hybrid public-key encryption scheme; key derivation for key-wrapping mechanisms; and more. All of these applications can benefit from the simplicity and multi-purpose nature of HKDF, as well as from its analytical foundation.
HKDF适用于各种KDF应用。这些包括从不完善的随机性源（如物理随机数发生器（RNG））构建伪随机发生器；从微弱的随机性来源产生伪随机性，如从系统事件、用户击键等收集的熵。；在密钥协商协议中，从共享Diffie-Hellman值派生加密密钥；从混合公钥加密方案导出对称密钥；密钥封装机制的密钥推导；还有更多。所有这些应用都可以受益于HKDF的简单性和多用途性质，以及从它的分析基础。
On the other hand, it is anticipated that some applications will not be able to use HKDF "as-is" due to specific operational requirements, or will be able to use it but without the full benefits of the scheme. One significant example is the derivation of cryptographic keys from a source of low entropy, such as a user's password. The extract step in HKDF can concentrate existing entropy but cannot amplify entropy. In the case of password-based KDFs, a main goal is to slow down dictionary attacks using two ingredients: a salt value, and the intentional slowing of the key derivation computation. HKDF naturally accommodates the use of salt; however, a slowing down mechanism is not part of this specification. Applications interested in a password-based KDF should consider whether, for example, [PKCS5] meets their needs better than HKDF.
另一方面，由于特定的操作要求，预计一些应用程序将无法“按原样”使用HKDF，或者将能够使用HKDF，但没有该计划的全部好处。一个重要的例子是从低熵源（如用户密码）派生加密密钥。HKDF中的提取步骤可以集中现有的熵，但不能放大熵。在基于密码的KDF中，主要目标是使用两种成分来减缓字典攻击：salt值和故意减缓密钥派生计算。香港发展基金自然适应盐的使用；但是，减速机构不是本规范的一部分。对基于密码的KDF感兴趣的应用程序应该考虑，例如，[PKCS5]是否比HKDF更好地满足他们的需求。
In spite of the simplicity of HKDF, there are many security considerations that have been taken into account in the design and analysis of this construction. An exposition of all of these aspects is beyond the scope of this document. Please refer to [HKDF-paper] for detailed information, including rationale for the design and for the guidelines presented in Section 3.
尽管HKDF结构简单，但在设计和分析该结构时考虑了许多安全因素。对所有这些方面的阐述超出了本文件的范围。有关详细信息，包括设计原理和第3节所述指南，请参考[HKDF文件]。
A major effort has been made in the above paper [HKDF-paper] to provide a cryptographic analysis of HKDF as a multi-purpose KDF that exercises much care in the way it utilizes cryptographic hash functions. This is particularly important due to the limited confidence we have in the strength of current hash functions. This analysis, however, does not imply the absolute security of any scheme, and it depends heavily on the strength of the underlying hash function and on modeling choices. Yet, it serves as a strong indication of the correct structure of the HKDF design and its advantages over other common KDF schemes.
在上述文件[HKDF文件]中，已作出重大努力，以提供HKDF作为多用途KDF的密码分析，该KDF在使用密码散列函数的方式上非常谨慎。这一点尤其重要，因为我们对当前哈希函数的强度信心有限。然而，这种分析并不意味着任何方案都是绝对安全的，它在很大程度上取决于底层哈希函数的强度和建模选择。然而，它有力地表明了HKDF设计的正确结构及其相对于其他常见KDF方案的优势。
The authors would like to thank members of the CFRG (Crypto Forum Research Group) list for their useful comments, and to Dan Harkins for providing test vectors.
作者要感谢CFRG（加密论坛研究小组）列表中的成员提供的有用意见，并感谢Dan Harkins提供的测试载体。
[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月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[SHS] National Institute of Standards and Technology, "Secure Hash Standard", FIPS PUB 180-3, October 2008.
[SHS]国家标准与技术研究所，“安全哈希标准”，FIPS PUB 180-3，2008年10月。
[1363a] Institute of Electrical and Electronics Engineers, "IEEE Standard Specifications for Public-Key Cryptography - Amendment 1: Additional Techniques", IEEE Std 1363a-2004, 2004.
[1363a]电气和电子工程师协会，“IEEE公钥加密标准规范-修改件1：附加技术”，IEEE标准1363a-2004，2004年。
[800-108] National Institute of Standards and Technology, "Recommendation for Key Derivation Using Pseudorandom Functions", NIST Special Publication 800-108, November 2008.
[800-108]国家标准与技术研究所，“使用伪随机函数进行密钥推导的建议”，NIST特别出版物800-108，2008年11月。
[800-56A] National Institute of Standards and Technology, "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography (Revised)", NIST Special Publication 800-56A, March 2007.
[800-56A]美国国家标准与技术研究所，“使用离散对数加密技术的成对密钥建立方案的建议（修订版）”，NIST特别出版物800-56A，2007年3月。
[EAP-AKA] Arkko, J., Lehtovirta, V., and P. Eronen, "Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA')", RFC 5448, May 2009.
[EAP-AKA]Arkko，J.，Lehtovirta，V.，和P.Erenen，“第三代认证和密钥协议（EAP-AKA'）的改进可扩展认证协议方法”，RFC 5448，2009年5月。
[HKDF-paper] Krawczyk, H., "Cryptographic Extraction and Key Derivation: The HKDF Scheme", Proceedings of CRYPTO 2010 (to appear), 2010, <http://eprint.iacr.org/2010/264>.
[HKDF论文]Krawczyk，H.，“密码提取和密钥推导：HKDF方案”，《加密学报2010》（即将出版），2010年<http://eprint.iacr.org/2010/264>.
[IKEv2] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[IKEv2]考夫曼，C.，编辑，“因特网密钥交换（IKEv2）协议”，RFC4306，2005年12月。
[PANA] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA)", RFC 5191, May 2008.
[PANA]Forsberg，D.，Ohba，Y.，Ed.，Patil，B.，Tschofenig，H.，和A.Yegin，“网络接入承载认证协议（PANA）”，RFC 51912008年5月。
[PKCS5] Kaliski, B., "PKCS #5: Password-Based Cryptography Specification Version 2.0", RFC 2898, September 2000.
[PKCS5]Kaliski，B.，“PKCS#5：基于密码的加密规范2.0版”，RFC 28982000年9月。
This appendix provides test vectors for SHA-256 and SHA-1 hash functions [SHS].
本附录提供了SHA-256和SHA-1哈希函数[SHS]的测试向量。
Basic test case with SHA-256
使用SHA-256的基本测试用例
Hash = SHA-256 IKM = 0x0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b (22 octets) salt = 0x000102030405060708090a0b0c (13 octets) info = 0xf0f1f2f3f4f5f6f7f8f9 (10 octets) L = 42
Hash=SHA-256 IKM=0x0B0B0B0B0B0B0B0B0B0B0B0B0B0B0B0B0B（22个八位字节）salt=0x000102030405060708090a0b0c（13个八位字节）info=0xf0f1f2f3f4f5f6f7f8f9（10个八位字节）L=42
PRK = 0x077709362c2e32df0ddc3f0dc47bba63 90b6c73bb50f9c3122ec844ad7c2b3e5 (32 octets) OKM = 0x3cb25f25faacd57a90434f64d0362f2a 2d2d0a90cf1a5a4c5db02d56ecc4c5bf 34007208d5b887185865 (42 octets)
PRK=0x077709362c2e32df0ddc3f0dc47bba63 90b6c73bb50f9c3122ec844ad7c2b3e5（32个八位字节）OKM=0x3cb25f25faacd57a90434f64d0362f2a 2D2D00A90CF1A5A4C5DB02D56ECC4BF 34007208d5b887185865（42个八位字节）
Test with SHA-256 and longer inputs/outputs
使用SHA-256和更长的输入/输出进行测试
Hash = SHA-256 IKM = 0x000102030405060708090a0b0c0d0e0f 101112131415161718191a1b1c1d1e1f 202122232425262728292a2b2c2d2e2f 303132333435363738393a3b3c3d3e3f 404142434445464748494a4b4c4d4e4f (80 octets) salt = 0x606162636465666768696a6b6c6d6e6f 707172737475767778797a7b7c7d7e7f 808182838485868788898a8b8c8d8e8f 909192939495969798999a9b9c9d9e9f a0a1a2a3a4a5a6a7a8a9aaabacadaeaf (80 octets) info = 0xb0b1b2b3b4b5b6b7b8b9babbbcbdbebf c0c1c2c3c4c5c6c7c8c9cacbcccdcecf d0d1d2d3d4d5d6d7d8d9dadbdcdddedf e0e1e2e3e4e5e6e7e8e9eaebecedeeef f0f1f2f3f4f5f6f7f8f9fafbfcfdfeff (80 octets) L = 82
Hash=SHA-256 IKM=0x000102030405060708090a0b0c0d0e0f 1011121314151617191A1B1C1D1E1F 202122232425262728292a2b2c2d2e2f 30313233343533738393B3C3D3F 4041424344454647494A4B4C4D4E4F（80位字节）salt=0x6061626364656668696A6B6C6D6F 707172737475767778797a7b7c7d7e7f 808182838485868788898A8C8D8E8F 9091929394959697999B9C9E9F A0A1A2A3A4A5A6A8A9A9AABACADAEAF（80个八位组）info=0xB0B1B2B3B4B5B6B7B8B9BABBCBEBF C0C1C2C3C4C5C6C7C8C9CACBCCDCECF D0D1D2D3D5D6D7D8D9DADBCDDDEDF E0E1E2E3E4E5E6E7E9E9EAEBECEDEEEF f0f1f2f3f4f5f6f7f8f9fafbfcfdfeff（80个八位字节）L=82
PRK = 0x06a6b88c5853361a06104c9ceb35b45c ef760014904671014a193f40c15fc244 (32 octets) OKM = 0xb11e398dc80327a1c8e7f78c596a4934 4f012eda2d4efad8a050cc4c19afa97c 59045a99cac7827271cb41c65e590e09 da3275600c2f09b8367793a9aca3db71 cc30c58179ec3e87c14c01d5c1f3434f 1d87 (82 octets)
PRK=0x06A6B88C58533610A06104C9CEB35B45C ef760014904671014a193f40c15fc244（32个八位字节）OKM=0xB11E398DC80327A1C8E7F789C596A4934 4f012eda2d4efad8a050cc4c19afa97c 59045a99cac7827271cb41c65e590e09 DA3275600C2F09B8367793ACA3AB71 CC30C58179EC3E87C14C015C334F 1d87（82个八位字节）
Test with SHA-256 and zero-length salt/info
使用SHA-256和零长度salt/info进行测试
Hash = SHA-256
IKM = 0x0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b (22 octets)
salt = (0 octets)
info = (0 octets)
L = 42
Hash = SHA-256
IKM = 0x0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b (22 octets)
salt = (0 octets)
info = (0 octets)
L = 42
PRK = 0x19ef24a32c717b167f33a91d6f648bdf 96596776afdb6377ac434c1c293ccb04 (32 octets) OKM = 0x8da4e775a563c18f715f802a063c5a31 b8a11f5c5ee1879ec3454e5f3c738d2d 9d201395faa4b61a96c8 (42 octets)
PRK=0x19ef24a32c717b167f33a91d6f648bdf 96596776afdb6377ac434c1c293ccb04（32个八位字节）OKM=0x8da4e775a563c18f715f802a063c5a31 B8A11F5C55EE1879EC3454E5F3C738D201395FA4B61A96C8（42个八位字节）
Basic test case with SHA-1
使用SHA-1的基本测试用例
Hash = SHA-1 IKM = 0x0b0b0b0b0b0b0b0b0b0b0b (11 octets) salt = 0x000102030405060708090a0b0c (13 octets) info = 0xf0f1f2f3f4f5f6f7f8f9 (10 octets) L = 42
Hash=SHA-1 IKM=0x0B0B0B0B0B0B0B0B（11个八位字节）salt=0x000102030405060708090a0b0c（13个八位字节）info=0xf0f1f2f3f4f6f7f8f9（10个八位字节）L=42
PRK = 0x9b6c18c432a7bf8f0e71c8eb88f4b30baa2ba243 (20 octets) OKM = 0x085a01ea1b10f36933068b56efa5ad81 a4f14b822f5b091568a9cdd4f155fda2 c22e422478d305f3f896 (42 octets)
PRK=0x9B6C18C432A7BF8F0E71C8EB88F4B30BAA243（20个八位字节）OKM=0x085A01EA1B10F36933068B56EFA55AD81 a4f14b822f5b091568a9cdd4f155fda2 C22E422478D305F396（42个八位字节）
Test with SHA-1 and longer inputs/outputs
使用SHA-1和更长的输入/输出进行测试
Hash = SHA-1 IKM = 0x000102030405060708090a0b0c0d0e0f 101112131415161718191a1b1c1d1e1f 202122232425262728292a2b2c2d2e2f 303132333435363738393a3b3c3d3e3f 404142434445464748494a4b4c4d4e4f (80 octets) salt = 0x606162636465666768696a6b6c6d6e6f 707172737475767778797a7b7c7d7e7f 808182838485868788898a8b8c8d8e8f 909192939495969798999a9b9c9d9e9f a0a1a2a3a4a5a6a7a8a9aaabacadaeaf (80 octets) info = 0xb0b1b2b3b4b5b6b7b8b9babbbcbdbebf c0c1c2c3c4c5c6c7c8c9cacbcccdcecf d0d1d2d3d4d5d6d7d8d9dadbdcdddedf e0e1e2e3e4e5e6e7e8e9eaebecedeeef f0f1f2f3f4f5f6f7f8f9fafbfcfdfeff (80 octets) L = 82
Hash=SHA-1 IKM=0x000102030405060708090a0b0c0d0e0f 1011121314151617191A1B1C1D1E1F 202122232425262728292a2b2c2d2e2f 30313233343533738393B3C3D3F 4041424344454647494A4B4C4D4E4F（80位字节）salt=0x6061626364656668696A6B6C6D6F 707172737475767778797a7b7c7d7e7f 808182838485868788898A8C8D8E8F 9091929394959697999B9C9E9F A0A1A2A3A4A5A6A8A9A9AABACADAEAF（80个八位组）info=0xB0B1B2B3B4B5B6B7B8B9BABBCBEBF C0C1C2C3C4C5C6C7C8C9CACBCCDCECF D0D1D2D3D5D6D7D8D9DADBCDDDEDF E0E1E2E3E4E5E6E7E9E9EAEBECEDEEEF f0f1f2f3f4f5f6f7f8f9fafbfcfdfeff（80个八位字节）L=82
PRK = 0x8adae09a2a307059478d309b26c4115a224cfaf6 (20 octets) OKM = 0x0bd770a74d1160f7c9f12cd5912a06eb ff6adcae899d92191fe4305673ba2ffe 8fa3f1a4e5ad79f3f334b3b202b2173c 486ea37ce3d397ed034c7f9dfeb15c5e 927336d0441f4c4300e2cff0d0900b52 d3b4 (82 octets)
PRK=0x8adae09a2a307059478d309b26c4115a224cfaf6（20个八位字节）OKM=0x0bd770a74d1160f7c9f12cd5912a06eb ff6adcae899d92191fe4305673ba2ffe 8FA3F1A4E5AD79F334B3B202B2173C 486ea37ce3d397ed034c7f9dfeb15c5e 927336D0441FC4300E2CFD0900B52 d3b4（82个八位字节）
Test with SHA-1 and zero-length salt/info
使用SHA-1和零长度盐/信息进行测试
Hash = SHA-1
IKM = 0x0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b (22 octets)
salt = (0 octets)
info = (0 octets)
L = 42
Hash = SHA-1
IKM = 0x0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b (22 octets)
salt = (0 octets)
info = (0 octets)
L = 42
PRK = 0xda8c8a73c7fa77288ec6f5e7c297786aa0d32d01 (20 octets) OKM = 0x0ac1af7002b3d761d1e55298da9d0506 b9ae52057220a306e07b6b87e8df21d0 ea00033de03984d34918 (42 octets)
PRK=0xDA8C8A73C7FA77288EC6F5E7C297786A0D32D01（20个八位字节）OKM=0x0AC1AF7002B3D761D155298DA9D0506 b9ae52057220a306e07b6b87e8df21d0 EA00033DE03984D3918（42个八位字节）
Test with SHA-1, salt not provided (defaults to HashLen zero octets), zero-length info
使用SHA-1测试，未提供salt（默认为HashLen零八位字节），零长度信息
Hash = SHA-1
IKM = 0x0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c (22 octets)
salt = not provided (defaults to HashLen zero octets)
info = (0 octets)
L = 42
Hash = SHA-1
IKM = 0x0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c (22 octets)
salt = not provided (defaults to HashLen zero octets)
info = (0 octets)
L = 42
PRK = 0x2adccada18779e7c2077ad2eb19d3f3e731385dd (20 octets) OKM = 0x2c91117204d745f3500d636a62f64f0a b3bae548aa53d423b0d1f27ebba6f5e5 673a081d70cce7acfc48 (42 octets)
PRK=0x2adccada18779e7c2077ad2eb19d3f3e731385dd（20个八位字节）OKM=0x2c91117204d745f3500d636a62f64f0a b3bae548aa53d423b0d1f27ebba6f5e5 673a081d70cce7acfc48（42个八位字节）
Authors' Addresses
作者地址
Hugo Krawczyk IBM Research 19 Skyline Drive Hawthorne, NY 10532 USA
Hugo Krawczyk IBM Research 19美国纽约州霍桑市天际大道10532号
EMail: hugokraw@us.ibm.com
EMail: hugokraw@us.ibm.com
Pasi Eronen Nokia Research Center P.O. Box 407 FI-00045 Nokia Group Finland
芬兰诺基亚集团Pasi Eronen诺基亚研究中心邮政信箱407 FI-00045
EMail: pasi.eronen@nokia.com
EMail: pasi.eronen@nokia.com