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)
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によって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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を、指定し、既にいくつかのIETFプロトコルで使用され、[PANA]、[のIKEv2]を含む、および[ 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.第二段階は、いくつかの追加の擬似ランダムキー（KDFの出力）にキーKを「拡大」それからの入力キーイング材料と「抽出」をとります。
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.
多くのアプリケーションでは、鍵材料の入力は必ずしも均一に分布されていない、攻撃者はそれについてのいくつかの部分的知識を有していてもよい（例えば、ディフィー・ヘルマン鍵交換プロトコルにより計算された値）は、いくつかのように、またはそれの偶数部分制御（エントロピー収集アプリケーション）。したがって、「抽出物」ステージの目標は短いが、暗号的に強い、疑似ランダムキーに入力キーイング材料の可能性分散エントロピーを「濃縮」することです。一部のアプリケーションでは、入力がすでに良い擬似ランダムキーであってもよく、これらの場合に、ステージが不要である「抽出物」、および「拡張」部分は、単独で使用することができます。
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).
（例えばは、NIST Special Publication 800-56A [800-56A]、は、NIST Special Publication 800から108 [800から108]とIEEE標準1363a-2004 [1363a]、のいずれかのようないくつかの既存のKDF仕様は、唯一の第二段階を考慮することに注意してください拡大擬似ランダムキー）、または明示的に「抽出物」と、多くの場合、設計上の欠点が生じ、ステージを「拡大」を区別しません。この仕様の目標は、基礎となるハッシュ関数についての仮定を最小限に抑えながら、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-ハッシュは、ハッシュ関数「ハッシュ」でインスタンス化HMAC関数[HMAC]です。 HMACは、常に2つの引数を有する：最初のキーおよび第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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[キーワード]に記載されているように解釈されます。
HKDF-Extract(salt, IKM) -> PRK
HKDF-エキス（塩、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
入力：塩オプションの塩値（非秘密のランダム値）。提供されていない場合、それはHashLenゼロの文字列に設定されています。 IKM入力鍵材料
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-展開（PRK、情報、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)
入力：少なくともHashLenオクテット（通常、抽出工程からの出力）先任意コンテキストおよびアプリケーション固有の情報（長さゼロの文字列であってもよい）オクテットで出力鍵材料のLの長さ（<= 255 *のPRK疑似ランダムキーHashLen）
Output: OKM output keying material (of L octets)
出力：（Lオクテットの）OKM出力鍵素材
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のT（N）OKM =最初のLオクテット
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）|情報| 0×02）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はでランダム塩がなくても動作するように定義されています。これは、塩値が利用できないアプリケーションに対応するために行われます。私たちは、ハッシュ関数の異なる用途間の独立性を確保し、「ソースに依存しない」の抽出をサポートし、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
ランダムな塩は、2つの方法で初期鍵材料は基本的に異なる：それは非機密であると再使用することができます。このようにして、塩の値は、多くの用途にご利用いただけます。例えば、連続的エントロピーの再生可能なプールにHKDFを適用することによって出力を生成する擬似乱数生成器（PRNG）が（例えば、サンプリングされたシステムイベント）塩値を固定することができ、複数のアプリケーションのためにそれを使用します
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交換から暗号鍵を導出する鍵合意プロトコルは、鍵合意の一部として、通信相手との間で交換と認証公共ナンスからソルト値（これは[の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.
理想的には、塩の値が長さ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.
ない、典型的なケースながら、いくつかのアプリケーションでも使用可能な秘密のソルト値を有することができる、ということは注目に値します。このような場合には、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）のように使用される場合、例えば、「INFO」プロトコル番号、アルゴリズム識別子、ユーザID等の特定のInを含んでいてもよい、それは異なる状況のために同じ鍵材料（の誘導を防止することができます異なるコンテキスト）。所望であれば、それはまた、鍵拡張部に追加の入力を収容することができる（例えば、アプリケーションは、このように「情報」フィールドの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暗号スイートプリマスタ秘密は最初の2つのオクテットを除いた擬似乱数列であろう）。この場合、一方が抽出部分をスキップすることができ、展開ステップにおいてキーHMACに直接IKMを使用します。一方、アプリケーションはまだ一般的なケースとの互換性のために抽出部を使用することができます。 IKMは、ランダム（又は擬似ランダム）が、HMACキーよりも長い場合、特に、抽出ステップは、HMACが動作するように定義されているので、HMACの場合に抽出を介して、この短縮は厳密に必要ではない（出力に適したHMACキーを提供することができ長いキー過ぎる）と。 IKMは、ディフィー・ヘルマンとTLSの場合と同様のDiffie-Hellman値である場合、抽出部がスキップされるべきではないこと、しかし、注意してください。そうすることHMACのためのキーとしてPRK（一様にランダムまたは疑似ランダム文字列でない）のDiffie-Hellman値g ^ {X-Y}自体を使用して生じます。その代わりに、HKDF（好ましくはソルト値を有する）G ^ {X-Y}に抽出工程を適用し、膨張部の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以下である場合には、一方がOKMとして直接PRKを使用することができます。これは、しかし、それが導出プロセスの一部として、「情報」の使用を省略するだろう特にため、推奨されていない（そして抽出ステップへの入力として「情報」を追加することは賢明ではない - [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の各インスタンスは、その分布からのサンプルです。鍵導出関数の主要な目標は、それを保証することである、任意の二つの値IKMとIKMに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-の不可欠な部分である例えば、IKEで（攻撃者が正当な政党から来るのではなく、選択として認証されていることを確認する必要があります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）など）乱数の不完全なソースからの擬似乱数生成器の構築を含みます。システム・イベント、ユーザのキーストローク等から収集例えばエントロピーとして乱数の弱い源、のうちpseudorandomnessの生成;鍵合意プロトコルで共有の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で抽出ステップは、既存のエントロピーを集中することができますが、エントロピーを増幅することはできません。ソルト値、および鍵導出計算を意図的に減速：パスワードベースの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のシンプルさにもかかわらず、この構造の設計と解析で考慮されている多くのセキュリティ上の考慮事項があります。これらの側面のすべての博覧会は、このドキュメントの範囲を超えています。設計用と第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.
主要な努力は、暗号学的ハッシュ関数を利用した方法で多くの注意を払って多目的KDFとしてHKDFの暗号解析を提供するために、上記の論文[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（暗号化フォーラム研究グループ）のリストのメンバーに感謝したいと思います。
[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[HMAC] Krawczyk、H.、ベラー、M.、およびR.カネッティ、 "HMAC：メッセージ認証のための鍵付きハッシュ化"、RFC 2104、1997年2月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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 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.
、は、NIST Special Publication 800から108、2008年11月[800から108]米国国立標準技術研究所、「擬似ランダム関数を使用した鍵導出のための勧告」。
[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. Eronen、RFC 5448、2009年5月、 "第3世代認証及び鍵合意（EAP-AKA '）のための拡張認証プロトコル方法の改善します"。
[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スキーム"、CRYPTO 2010予稿が（表示される）2010年、<http://eprint.iacr.org/2010/264>。
[IKEv2] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[IKEv2の]カウフマン、C.、エド。、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、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]フォースバーグ、D.、オオバ、Y.、編、パティル、B.、Tschofenig、H.、およびA. Yegin、RFC 5191、2008年5月 "ネットワークアクセス（PANA）の認証を搬送するプロトコル"。
[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月。
Appendix A. Test Vectors
付録A.テストベクトル
This appendix provides test vectors for SHA-256 and SHA-1 hash functions [SHS].
この付録では、SHA-256およびSHA-1ハッシュ関数[SHS]のためのテストベクトルを提供します。
A.1. Test Case 1
A.1。テストケース1
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
ハッシュ= SHA-256 IKM = 0x0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b（22オクテット）塩= 0x000102030405060708090a0b0c（13オクテット）情報= 0xf0f1f2f3f4f5f6f7f8f9（10オクテット）L = 42
PRK = 0x077709362c2e32df0ddc3f0dc47bba63 90b6c73bb50f9c3122ec844ad7c2b3e5 (32 octets) OKM = 0x3cb25f25faacd57a90434f64d0362f2a 2d2d0a90cf1a5a4c5db02d56ecc4c5bf 34007208d5b887185865 (42 octets)
PRK = 0x077709362c2e32df0ddc3f0dc47bba63 90b6c73bb50f9c3122ec844ad7c2b3e5（32オクテット）OKM = 0x3cb25f25faacd57a90434f64d0362f2a 2d2d0a90cf1a5a4c5db02d56ecc4c5bf 34007208d5b887185865（42オクテット）
A.2. Test Case 2
A.2。テストケース2
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
ハッシュ= SHA-256 IKM = 0x000102030405060708090a0b0c0d0e0f 101112131415161718191a1b1c1d1e1f 202122232425262728292a2b2c2d2e2f 303132333435363738393a3b3c3d3e3f 404142434445464748494a4b4c4d4e4f（80オクテット）塩= 0x606162636465666768696a6b6c6d6e6f 707172737475767778797a7b7c7d7e7f 808182838485868788898a8b8c8d8e8f 909192939495969798999a9b9c9d9e9f a0a1a2a3a4a5a6a7a8a9aaabacadaeaf（80オクテット）情報= 0xb0b1b2b3b4b5b6b7b8b9babbbcbdbebf c0c1c2c3c4c5c6c7c8c9cacbcccdcecf d0d1d2d3d4d5d6d7d8d9dadbdcdddedf e0e1e2e3e4e5e6e7e8e9eaebecedeeef f0f1f2f3f4f5f6f7f8f9fafbfcfdfeff（80オクテット）L = 82
PRK = 0x06a6b88c5853361a06104c9ceb35b45c ef760014904671014a193f40c15fc244 (32 octets) OKM = 0xb11e398dc80327a1c8e7f78c596a4934 4f012eda2d4efad8a050cc4c19afa97c 59045a99cac7827271cb41c65e590e09 da3275600c2f09b8367793a9aca3db71 cc30c58179ec3e87c14c01d5c1f3434f 1d87 (82 octets)
PRK = 0x06a6b88c5853361a06104c9ceb35b45c ef760014904671014a193f40c15fc244（32オクテット）OKM = 0xb11e398dc80327a1c8e7f78c596a4934 4f012eda2d4efad8a050cc4c19afa97c 59045a99cac7827271cb41c65e590e09 da3275600c2f09b8367793a9aca3db71 cc30c58179ec3e87c14c01d5c1f3434f 1d87（82オクテット）
A.3. Test Case 3
A.3。テストケース3
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
ハッシュ= SHA-256 IKM = 0x0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b（22オクテット）塩=（0オクテット）情報=（0オクテット）L = 42
PRK = 0x19ef24a32c717b167f33a91d6f648bdf 96596776afdb6377ac434c1c293ccb04 (32 octets) OKM = 0x8da4e775a563c18f715f802a063c5a31 b8a11f5c5ee1879ec3454e5f3c738d2d 9d201395faa4b61a96c8 (42 octets)
PRK = 0x19ef24a32c717b167f33a91d6f648bdf 96596776afdb6377ac434c1c293ccb04（32オクテット）OKM = 0x8da4e775a563c18f715f802a063c5a31 b8a11f5c5ee1879ec3454e5f3c738d2d 9d201395faa4b61a96c8（42オクテット）
A.4. Test Case 4
A.4。テストケース4
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
ハッシュ= SHA-1 IKM = 0x0b0b0b0b0b0b0b0b0b0b0b（11オクテット）塩= 0x000102030405060708090a0b0c（13オクテット）情報= 0xf0f1f2f3f4f5f6f7f8f9（10オクテット）L = 42
PRK = 0x9b6c18c432a7bf8f0e71c8eb88f4b30baa2ba243 (20 octets) OKM = 0x085a01ea1b10f36933068b56efa5ad81 a4f14b822f5b091568a9cdd4f155fda2 c22e422478d305f3f896 (42 octets)
PRK = 0x9b6c18c432a7bf8f0e71c8eb88f4b30baa2ba243（20オクテット）OKM = 0x085a01ea1b10f36933068b56efa5ad81 a4f14b822f5b091568a9cdd4f155fda2 c22e422478d305f3f896（42オクテット）
A.5. Test Case 5
A.5。テストケース5
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
ハッシュ= SHA-1 IKM = 0x000102030405060708090a0b0c0d0e0f 101112131415161718191a1b1c1d1e1f 202122232425262728292a2b2c2d2e2f 303132333435363738393a3b3c3d3e3f 404142434445464748494a4b4c4d4e4f（80オクテット）塩= 0x606162636465666768696a6b6c6d6e6f 707172737475767778797a7b7c7d7e7f 808182838485868788898a8b8c8d8e8f 909192939495969798999a9b9c9d9e9f a0a1a2a3a4a5a6a7a8a9aaabacadaeaf（80オクテット）情報= 0xb0b1b2b3b4b5b6b7b8b9babbbcbdbebf c0c1c2c3c4c5c6c7c8c9cacbcccdcecf d0d1d2d3d4d5d6d7d8d9dadbdcdddedf e0e1e2e3e4e5e6e7e8e9eaebecedeeef f0f1f2f3f4f5f6f7f8f9fafbfcfdfeff（80オクテット）L = 82
PRK = 0x8adae09a2a307059478d309b26c4115a224cfaf6 (20 octets) OKM = 0x0bd770a74d1160f7c9f12cd5912a06eb ff6adcae899d92191fe4305673ba2ffe 8fa3f1a4e5ad79f3f334b3b202b2173c 486ea37ce3d397ed034c7f9dfeb15c5e 927336d0441f4c4300e2cff0d0900b52 d3b4 (82 octets)
PRK = 0x8adae09a2a307059478d309b26c4115a224cfaf6（20オクテット）OKM = 0x0bd770a74d1160f7c9f12cd5912a06eb ff6adcae899d92191fe4305673ba2ffe 8fa3f1a4e5ad79f3f334b3b202b2173c 486ea37ce3d397ed034c7f9dfeb15c5e 927336d0441f4c4300e2cff0d0900b52 d3b4（82オクテット）
A.6. Test Case 6
A.6。テストケース6
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
ハッシュ= SHA-1 IKM = 0x0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b（22オクテット）塩=（0オクテット）情報=（0オクテット）L = 42
PRK = 0xda8c8a73c7fa77288ec6f5e7c297786aa0d32d01 (20 octets) OKM = 0x0ac1af7002b3d761d1e55298da9d0506 b9ae52057220a306e07b6b87e8df21d0 ea00033de03984d34918 (42 octets)
PRK = 0xda8c8a73c7fa77288ec6f5e7c297786aa0d32d01（20オクテット）OKM = 0x0ac1af7002b3d761d1e55298da9d0506 b9ae52057220a306e07b6b87e8df21d0 ea00033de03984d34918（42オクテット）
A.7. Test Case 7
A.7。テストケース7
Test with SHA-1, salt not provided (defaults to HashLen zero octets), zero-length info
SHA-1を用いた試験、塩（HashLenデフォルトゼロオクテット）、長さゼロの情報設けられていません
Hash = SHA-1 IKM = 0x0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c (22 octets) salt = not provided (defaults to HashLen zero octets) info = (0 octets) L = 42
ハッシュ= SHA-1 IKM = 0x0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c（22オクテット）塩は、=（HashLenデフォルトゼロオクテット）情報=（0オクテット）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
ヒューゴKrawczyk IBMリサーチ19スカイラインドライブホーソーン、NY 10532 USA
EMail: hugokraw@us.ibm.com
メールアドレス：hugokraw@us.ibm.com
Pasi Eronen Nokia Research Center P.O. Box 407 FI-00045 Nokia Group Finland
ノキア・リサーチセンター私書箱のパシEronenボックス407 FI-00045 Nokiaのグループフィンランド
EMail: pasi.eronen@nokia.com
メールアドレス：pasi.eronen@nokia.com