[要約] RFC 5869は、HMAC-based Extract-and-Expand Key Derivation Function (HKDF)に関する文書で、任意の長さの初期鍵材料から安全な鍵を導出するためのシンプルで効率的な方法を定義しています。この手法は、2段階のプロセス（抽出と展開）を使用して、強力な暗号鍵を生成します。主に、TLSやIPsecなどのセキュリティプロトコルや、様々な暗号化アプリケーションでの鍵管理に利用されます。関連するRFCとしては、RFC 2104 (HMAC)や、HKDFを使用する具体的なプロトコルを定義するRFCがありますが、HKDF自体の直接的な拡張を説明するRFCは特にありません。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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）は、暗号システムの基本的かつ必須コンポーネントです。その目標は、最初のキーイング材料のソースを取り、1つ以上の暗号化的に強力な秘密の鍵から派生することです。
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.
このドキュメントは、さまざまなプロトコルおよびアプリケーションでビルディングブロックとして使用できるHKDFという名前の単純なHMACベースの[HMAC] KDFを指定し、[IKEV2]、[PANA]、[[PANA]、[]を含むいくつかのIETFプロトコルで既に使用されています。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は2つのモジュールで構成されています。最初の段階では、入力キーイング材料を取り、そこから固定長さの擬似ランダムキーKに「抽出」します。2番目のステージは、キーKを「KDFの出力）のいくつかの追加の擬似ランダムキー（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.
第2段階は、擬似ランダムキーを「拡張」し、目的の長さになります。出力キーの数と長さは、キーが必要な特定の暗号化アルゴリズムに依存します。
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).
NIST Special Publication 800-56A [800-56A]、NIST Special Publication 800-108 [800-108]、IEEE Standard 1363A-2004 [1363a]など、Nist Special Publication 800-56a [800-56a]、Nist Special Publication 800-108 [800-108]などの既存のKDF仕様の一部は、第2段階のみを考慮していることに注意してください。擬似ランダムキー）、または「抽出」と「展開」ステージを明示的に区別しないでください。この仕様の目標は、基礎となるハッシュ関数に関する仮定を最小限に抑えながら、幅広いKDF要件に対応することです。「Extract-Then-Expand」パラダイムは、この目標をよくサポートしています（[HKDF-Paper]を参照して、設計の理論的根拠の詳細については参照）。
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には常に2つの引数があります。1つ目はキー、2番目は入力（またはメッセージ）です。（抽出ステップでは、「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).
メッセージがいくつかの要素で構成されている場合、2番目の引数で連結（|を示します）を使用します。たとえば、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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[キーワード]で説明されているように解釈されます。
HKDF-Extract(salt, IKM) -> PRK
Options: Hash a hash function; HashLen denotes the length of the hash function output in octets
オプション：ハッシュハッシュ関数。ハッシュレンは、オクテットのハッシュ関数出力の長さを示します
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
入力：塩オプションの塩値（非秘密のランダム値）;提供されていない場合は、ハッシュレンゼロの文字列に設定されます。IKM入力キーイング素材
Output: PRK a pseudorandom key (of HashLen octets)
出力：prk擬似ランダムキー（ハシュレンオクテットの）
The output PRK is calculated as follows:
出力PRKは次のように計算されます。
PRK = HMAC-Hash(salt, IKM)
prk = hmac-hash（塩、ikm）
HKDF-Expand(PRK, info, L) -> OKM
Options: Hash a hash function; HashLen denotes the length of the hash function output in octets
オプション：ハッシュハッシュ関数。ハッシュレンは、オクテットのハッシュ関数出力の長さを示します
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少なくともハッシュレンオクテットの擬似ランダムキー（通常、抽出ステップからの出力）情報オプションのコンテキストとアプリケーション固有の情報（ゼロ長文字列になることがあります）ハッシュレン）
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
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)
...
(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-Paper]にあります。
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は、ランダム塩の有無にかかわらず動作するように定義されています。これは、塩の値が利用できないアプリケーションに対応するために行われます。しかし、塩の使用は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 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]).
ランダム塩は、2つの方法で初期キーイング材料と根本的に異なります。それは非秘密であり、再利用することができます。そのため、多くのアプリケーションで塩値を利用できます。たとえば、HKDFをエントロピーの再生可能プールに適用することにより出力を継続的に生成する擬似ランダム数ジェネレーター（PRNG）は、塩値を修正し、HKDFの複数のアプリケーションに塩値を修正し、それを使用することで、それを使用できます。塩。別のアプリケーションドメインでは、Diffie-Hellman Exchangeから暗号化キーを導き出す主要な契約プロトコルは、主要な合意の一部として通信当事者との間で交換および認証された公共の非源から塩値を導き出すことができます（これは[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.
理想的には、塩値は長さのハッシュレンのランダムな（または擬似ランダム）ストリングです。しかし、品質が低い（サイズが短い、またはエントロピーが限られている）塩値でさえ、出力キーイング材料のセキュリティに大きく貢献する可能性があります。したがって、アプリケーションによってそのような値を取得できる場合、アプリケーションの設計者は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.
典型的なケースではありませんが、一部のアプリケーションには使用可能な秘密の塩値があることさえあります。そのような場合、HKDFはさらに強力なセキュリティ保証を提供します。このようなアプリケーションの例は、「パブリックキー暗号化モード」のIKEV1です。ここで、抽出器への「塩」は秘密のノンースから計算されます。同様に、IKEV1の事前共有モードは、恥ずかしさキーから派生した秘密の塩を使用します。
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.
「情報」値はHKDFの定義ではオプションですが、アプリケーションでは非常に重要なことがよくあります。その主な目的は、派生した重要な資料をアプリケーションおよびコンテキスト固有の情報に結合することです。たとえば、「情報」には、プロトコル番号、アルゴリズム識別子、ユーザーのアイデンティティなどが含まれる場合があります。特に、異なるコンテキストの同じキーキー材料の導出を防ぐ場合があります（同じ入力キーマテリアル（IKM）がそのように使用される場合異なるコンテキスト）。また、必要に応じて、主要な拡張部品への追加の入力に対応することもできます（たとえば、アプリケーションは、キーマテリアルをその長さLにバインドするため、Lを「情報」フィールドの一部にすることができます）。「情報」には1つの技術的要件があります。入力キーマテリアル値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 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.
一部のアプリケーションでは、入力キーマテリアルIKMはすでに暗号化的に強力なキーとして存在する場合があります（たとえば、TLS RSA暗号スイートのPrepreaster Secretは、最初の2つのオクテットを除き、擬似ランダムストリングになります）。この場合、抽出部品をスキップし、拡張ステップでキーHMACにIKMを直接使用できます。一方、アプリケーションは、一般的なケースとの互換性のために、引き続き抽出部品を使用する場合があります。特に、IKMがランダム（または擬似ランダム）であるがHMACキーよりも長い場合、抽出ステップは適切なHMACキーを出力するのに役立ちます（HMACを介したこの短縮は、HMACが作業に定義されるため、厳密に必要ではありません。長いキーもあります）。ただし、IKMがDiffie-HellmanのTLSの場合のように、IKMがDiffie-Hellman値である場合、抽出部をスキップしないでください。そうすることで、diffie-hellman値g^{xy}自体（均一にランダムまたは擬似ランダム文字列ではありません）をHMACのキーPRKとして使用することになります。代わりに、HKDFは抽出ステップをg^{xy}に適用し（できれば塩値）、拡張部分のHMACの鍵として得られたPRKを使用する必要があります。
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として直接使用できます。ただし、これは推奨されません。特に、派生プロセスの一部として「情報」の使用を省略するため（および抽出ステップへの入力として「情報」を追加することはお勧めできません。[HKDF-Paper]を参照）。
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の各インスタンスは、その分布のサンプルです。重要な導出関数の主要な目標は、（同じ）ソース分布からサンプリングされた2つの値IKMとIKM 'の任意の2つの値にKDFを適用するとき、結果のキー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に提供される塩値の重要な側面でもあります。塩を秘密に保つ必要はなく、同じ塩値を複数のIKM値で使用できますが、塩値は入力キーイング材料に依存しないと想定されています。特に、アプリケーションは、塩の値が攻撃者によって選択または操作されないことを確認する必要があります。例として、塩が主要な交換プロトコルで当事者によって供給されたノンセスに由来するケース（IKEのように）を考慮してください。プロトコルがそのような塩を使用してキーを導出する前に、攻撃者によって選択されるのではなく、これらの非能力が正当な関係者から来ると認証されることを確認する必要があります（たとえば、この認証は認証されたdiffie-の不可欠な部分です - Hellman Exchange）。
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「AS-IS」を使用できないか、スキームの完全な利点がないが使用できると予想されています。重要な例の1つは、ユーザーのパスワードなど、低エントロピーのソースからの暗号化キーの導出です。HKDFの抽出ステップは、既存のエントロピーを集中させることができますが、エントロピーを増幅することはできません。パスワードベースのKDFSの場合、主な目標は、2つの成分を使用して辞書攻撃を遅くすることです。塩値と、キー導出計算の意図的な遅延です。HKDFは自然に塩の使用に対応します。ただし、遅延メカニズムはこの仕様の一部ではありません。パスワードベースの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の単純さにもかかわらず、この構造の設計と分析で考慮されている多くのセキュリティ上の考慮事項があります。これらすべての側面の説明は、このドキュメントの範囲を超えています。[HKDF-PAPER]を参照してください。詳細については、設計の理論的根拠やセクション3に示されているガイドラインを含みます。
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-PAPER]には、暗号化ハッシュ関数を利用する方法で多くの注意を払う多目的KDFとしてHKDFの暗号化分析を提供するための主要な取り組みがなされています。これは、現在のハッシュ関数の強度に対する自信が限られているため、特に重要です。ただし、この分析は、スキームの絶対的なセキュリティを意味するものではなく、基礎となるハッシュ関数の強度とモデリングの選択に大きく依存します。しかし、それは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（Crypto Forum Research Group）リストのメンバーに有用なコメントについて、またテストベクターを提供してくれた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]国立標準技術研究所、「Secure Hash Standard」、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 STD 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 Special Publication 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 Special Publication 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. Eronen、「第3世代認証と主要な合意（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-PAPER] KRAWCZYK、H。、「暗号化抽出とキー導出：HKDFスキーム」、Crypto 2010（表示）、2010年、<http://eprint.iacr.org/2010/264>。
[IKEv2] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[IKEV2] Kaufman、C.、ed。、「Internet Key Exchange（IKEV2）Protocol」、RFC 4306、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 5191、2008年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 2898、2000年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 = 0X0B0B0B0B0B0B0B0B0B0B0B0B0B0B0B0B0B0B0B0B0B0B（22オクテット）SALT = 0x000104040405060708090A0B0C（13オクターテ）
PRK = 0x077709362c2e32df0ddc3f0dc47bba63 90b6c73bb50f9c3122ec844ad7c2b3e5 (32 octets) OKM = 0x3cb25f25faacd57a90434f64d0362f2a 2d2d0a90cf1a5a4c5db02d56ecc4c5bf 34007208d5b887185865 (42 octets)
PRK = 0x077709362c2e32df0ddc3f0dc47bba63 90b6c73bb50f9c3122ec844ad7c2b3e5 (32 octets) OKM = 0x3cb25f25faacd57a90434f64d0362f2a 2d2d0a90cf1a5a4c5db02d56ecc4c5bf 34007208d5b887185865 (42 octets)
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 101112131415161718191a1b1c1d1e1f 202122232425262728292a2b2c2d2e2f 303132333435363738393a3b3c3d3e3f 404142434445464748494a4b4c4d4e4f (80 octets) salt = 0x606162636465666768696a6b6c6d6e6f 707172737475767778797a7b7c7d7e7f 808182838485868788898a8b8c8d8e8f 909192939495969798999a9b9c9d9e9f a0a1a2a3a4a5a6a7a8a9aaabacadaeaf (80 octets) info = 0xb0b1b2b3b4b5b6b7b8b9babbbcbdbebf c0c1c2c3c4c5c6c7c8c9cacbcccdcecf d0d1d2d3d4d5d6d7d8d9dadbdcdddedf e0e1e2e3e4e5e6e7e8e9eaebecedeeef f0f1f2f3f4f5f6f7f8f9fafbfcfdfeff (80 octets) L = 82
PRK = 0x06a6b88c5853361a06104c9ceb35b45c ef760014904671014a193f40c15fc244 (32 octets) OKM = 0xb11e398dc80327a1c8e7f78c596a4934 4f012eda2d4efad8a050cc4c19afa97c 59045a99cac7827271cb41c65e590e09 da3275600c2f09b8367793a9aca3db71 cc30c58179ec3e87c14c01d5c1f3434f 1d87 (82 octets)
PRK = 0x06a6b88c5853361a06104c9ceb35b45c ef760014904671014a193f40c15fc244 (32 octets) OKM = 0xb11e398dc80327a1c8e7f78c596a4934 4f012eda2d4efad8a050cc4c19afa97c 59045a99cac7827271cb41c65e590e09 da3275600c2f09b8367793a9aca3db71 cc30c58179ec3e87c14c01d5c1f3434f 1d87 (82 octets)
Test with SHA-256 and zero-length salt/info
SHA-256およびゼロの長さの塩/情報でテストします
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 octets) OKM = 0x8da4e775a563c18f715f802a063c5a31 b8a11f5c5ee1879ec3454e5f3c738d2d 9d201395faa4b61a96c8 (42 octets)
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 = 0x0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b060708090a0b0c（13オクテット）情報= 0xf0f1f2ff3f3f4f5f5f6f7f8f9（10オクター）l = 42
PRK = 0x9b6c18c432a7bf8f0e71c8eb88f4b30baa2ba243 (20 octets) OKM = 0x085a01ea1b10f36933068b56efa5ad81 a4f14b822f5b091568a9cdd4f155fda2 c22e422478d305f3f896 (42 octets)
PRK = 0x9B6C18C432A7BF8F0E71C8EB88F4B30BAA2BA243（20オクテット）OKM = 0x085A01EA1B10F36933068B556EFA5AD81 A4F14B8222FF5B091568ACDD4D4PD4FD4FD4FD4FD4D4D4D4D4D4D4D4D4D482565681818A
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 101112131415161718191a1b1c1d1e1f 202122232425262728292a2b2c2d2e2f 303132333435363738393a3b3c3d3e3f 404142434445464748494a4b4c4d4e4f (80 octets) salt = 0x606162636465666768696a6b6c6d6e6f 707172737475767778797a7b7c7d7e7f 808182838485868788898a8b8c8d8e8f 909192939495969798999a9b9c9d9e9f a0a1a2a3a4a5a6a7a8a9aaabacadaeaf (80 octets) info = 0xb0b1b2b3b4b5b6b7b8b9babbbcbdbebf c0c1c2c3c4c5c6c7c8c9cacbcccdcecf d0d1d2d3d4d5d6d7d8d9dadbdcdddedf e0e1e2e3e4e5e6e7e8e9eaebecedeeef f0f1f2f3f4f5f6f7f8f9fafbfcfdfeff (80 octets) L = 82
PRK = 0x8adae09a2a307059478d309b26c4115a224cfaf6 (20 octets) OKM = 0x0bd770a74d1160f7c9f12cd5912a06eb ff6adcae899d92191fe4305673ba2ffe 8fa3f1a4e5ad79f3f334b3b202b2173c 486ea37ce3d397ed034c7f9dfeb15c5e 927336d0441f4c4300e2cff0d0900b52 d3b4 (82 octets)
PRK = 0x8adae09a2a307059478d309b26c4115a224cfaf6 (20 octets) OKM = 0x0bd770a74d1160f7c9f12cd5912a06eb ff6adcae899d92191fe4305673ba2ffe 8fa3f1a4e5ad79f3f334b3b202b2173c 486ea37ce3d397ed034c7f9dfeb15c5e 927336d0441f4c4300e2cff0d0900b52 d3b4 (82 octets)
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
PRK = 0xda8c8a73c7fa77288ec6f5e7c297786aa0d32d01 (20 octets) OKM = 0x0ac1af7002b3d761d1e55298da9d0506 b9ae52057220a306e07b6b87e8df21d0 ea00033de03984d34918 (42 octets)
PRK = 0xDA8C8A73C7FA77288888888888888888888886AA0D32D01（20オクテット）OKM = 0x0AC1AF7002B3D761D1E55298DA9D0506 B9AE5205220A306E07B6B87EATTF21DF21DF21DECTER
Test with SHA-1, salt not provided (defaults to HashLen zero octets), zero-length info
SHA-1でテストし、塩が提供されていない（デフォルトはハッシュレンゼロオクテット）、ゼロレングス情報
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 = 0x2C9117204D745F3500D636A62F64F0A B3BAE548AA53D4423B0D1F27E67E673A673A673A673A673A673A673A673A
Authors' Addresses
著者のアドレス
Hugo Krawczyk IBM Research 19 Skyline Drive Hawthorne, NY 10532 USA
Hugo Krawczyk IBM Research 19スカイラインドライブホーソーン、ニューヨーク10532 USA
EMail: hugokraw@us.ibm.com
Pasi Eronen Nokia Research Center P.O. Box 407 FI-00045 Nokia Group Finland
Pasi Eronen Nokia Research Center P.O.Box 407 FI-00045 Nokia Group Finland
EMail: pasi.eronen@nokia.com