RFC2104 日本語訳

Network Working Group                                       H. Krawczyk
Request for Comments: 2104                                          IBM
Category: Informational                                      M. Bellare
                                                                   UCSD
                                                             R. Canetti
                                                                    IBM
                                                          February 1997

Krawczykがコメントのために要求するワーキンググループH.をネットワークでつないでください: 2104年のIBMカテゴリ: 情報のM.Bellare UCSD R.カネッティIBM1997年2月

             HMAC: Keyed-Hashing for Message Authentication

HMAC: 通報認証のための合わせられた論じ尽くすこと

Status of This Memo

このメモの状態

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

Abstract

要約

   This document describes HMAC, a mechanism for message authentication
   using cryptographic hash functions. HMAC can be used with any
   iterative cryptographic hash function, e.g., MD5, SHA-1, in
   combination with a secret shared key.  The cryptographic strength of
   HMAC depends on the properties of the underlying hash function.

このドキュメントは暗号のハッシュ関数を使用する通報認証のためにHMAC、メカニズムについて説明します。 秘密の共有されたキーと組み合わせてどんな繰り返しの暗号のハッシュ関数、例えば、MD5、SHA-1と共にもHMACを使用できます。 HMACの暗号の強さは基本的なハッシュ関数の所有地に依存します。

1. Introduction

1. 序論

   Providing a way to check the integrity of information transmitted
   over or stored in an unreliable medium is a prime necessity in the
   world of open computing and communications. Mechanisms that provide
   such integrity check based on a secret key are usually called
   "message authentication codes" (MAC). Typically, message
   authentication codes are used between two parties that share a secret
   key in order to validate information transmitted between these
   parties. In this document we present such a MAC mechanism based on
   cryptographic hash functions. This mechanism, called HMAC, is based
   on work by the authors [BCK1] where the construction is presented and
   cryptographically analyzed. We refer to that work for the details on
   the rationale and security analysis of HMAC, and its comparison to
   other keyed-hash methods.

伝えられた情報の保全を健康診断する方法を提供するか、または頼り無い媒体に格納されているのが、開いているコンピューティングとコミュニケーションの世界の主要な必要性です。 通常、秘密鍵に基づくそのような保全チェックを提供するメカニズムは「メッセージ確認コード」(MAC)と呼ばれます。 通常、メッセージ確認コードはこれらのパーティーの間に伝えられた情報を有効にするために秘密鍵を共有する2回のパーティーの間で使用されます。 本書では私たちは暗号のハッシュ関数に基づくそのようなMACメカニズムを提示します。 工事が提示されて、暗号で分析されるところでHMACと呼ばれる作者[BCK1]のこのメカニズムは仕事に基づいています。 私たちは原理に関する詳細、HMACの証券分析、およびその比較について他の合わせられた細切れ肉料理方法とその仕事を呼びます。

Krawczyk, et. al.            Informational                      [Page 1]

RFC 2104                          HMAC                     February 1997

et Krawczyk、アル。 [1ページ]情報のRFC2104HMAC1997年2月

   HMAC can be used in combination with any iterated cryptographic hash
   function. MD5 and SHA-1 are examples of such hash functions. HMAC
   also uses a secret key for calculation and verification of the
   message authentication values. The main goals behind this
   construction are

どんな繰り返された暗号のハッシュ関数と組み合わせてHMACを使用できます。 MD5とSHA-1はそのようなハッシュ関数に関する例です。 また、HMACは通報認証値の計算と検証に秘密鍵を使用します。 この工事の後ろの第一目的はそうです。

   * To use, without modifications, available hash functions.
     In particular, hash functions that perform well in software,
     and for which code is freely and widely available.

* 変更なしで利用可能な細切れ肉料理を使用するのは機能します。 特に、ソフトウェアでよく振る舞って、コードが自由で広く利用可能である機能を論じ尽くしてください。

   * To preserve the original performance of the hash function without
     incurring a significant degradation.

* 重要な退行を被らないでハッシュ関数の初演を保存するために。

   * To use and handle keys in a simple way.

* 簡単な方法でキーを使用して、扱うために。

   * To have a well understood cryptographic analysis of the strength of
     the authentication mechanism based on reasonable assumptions on the
     underlying hash function.

* 井戸を持っているのは基本的なハッシュ関数で妥当な想定に基づく認証機構の強さの暗号の分析を理解していました。

   * To allow for easy replaceability of the underlying hash function in
     case that faster or more secure hash functions are found or
     required.

* 場合における、基本的なハッシュ関数の簡単な置換可能性のためにそれを許容するために、より速いか、より安全なハッシュ関数が、見つけられるか、または必要です。

   This document specifies HMAC using a generic cryptographic hash
   function (denoted by H). Specific instantiations of HMAC need to
   define a particular hash function. Current candidates for such hash
   functions include SHA-1 [SHA], MD5 [MD5], RIPEMD-128/160 [RIPEMD].
   These different realizations of HMAC will be denoted by HMAC-SHA1,
   HMAC-MD5, HMAC-RIPEMD, etc.

このドキュメントは、一般的な暗号のハッシュ関数(Hで、指示される)を使用することでHMACを指定します。 HMACの特定の具体化は、特定のハッシュ関数を定義する必要があります。 そのようなハッシュ関数の現在の候補はSHA-1[SHA]、MD5[MD5]、RIPEMD-128/160[RIPEMD]を入れます。 HMACのこれらの異なった実現はHMAC-SHA1、HMAC-MD5、HMAC-RIPEMDなどによって指示されるでしょう。

   Note: To the date of writing of this document MD5 and SHA-1 are the
   most widely used cryptographic hash functions. MD5 has been recently
   shown to be vulnerable to collision search attacks [Dobb].  This
   attack and other currently known weaknesses of MD5 do not compromise
   the use of MD5 within HMAC as specified in this document (see
   [Dobb]); however, SHA-1 appears to be a cryptographically stronger
   function. To this date, MD5 can be considered for use in HMAC for
   applications where the superior performance of MD5 is critical.   In
   any case, implementers and users need to be aware of possible
   cryptanalytic developments regarding any of these cryptographic hash
   functions, and the eventual need to replace the underlying hash
   function. (See section 6 for more information on the security of
   HMAC.)

以下に注意してください。 このドキュメントを主題にして書く日付まで、MD5とSHA-1は最も広く使用された暗号のハッシュ関数です。 MD5は、最近、衝突検索攻撃[ドッブ]に傷つきやすくなるように見せられました。 MD5のこの攻撃と他の現在知られている弱点はこのドキュメントの指定されるとしてのHMACの中でMD5の使用で妥協しません([ドッブ]を見てください)。 しかしながら、SHA-1は、暗号でaであるように見えます。より強い機能。 今日まで、HMACにおける、MD5の優れた性能が重要であるアプリケーションの使用のためにMD5を考えることができます。 どのような場合でも、implementersとユーザは、これらの暗号のハッシュ関数のどれか、および基本的なハッシュ関数を取り替える最後の必要性に関して可能なcryptanalytic開発を意識している必要があります。 (HMACのセキュリティの詳しい情報に関してセクション6を見てください。)

Krawczyk, et. al.            Informational                      [Page 2]

RFC 2104                          HMAC                     February 1997

et Krawczyk、アル。 [2ページ]情報のRFC2104HMAC1997年2月

2. Definition of HMAC

2. HMACの定義

   The definition of HMAC requires a cryptographic hash function, which
   we denote by H, and a secret key K. We assume H to be a cryptographic
   hash function where data is hashed by iterating a basic compression
   function on blocks of data.   We denote by B the byte-length of such
   blocks (B=64 for all the above mentioned examples of hash functions),
   and by L the byte-length of hash outputs (L=16 for MD5, L=20 for
   SHA-1).  The authentication key K can be of any length up to B, the
   block length of the hash function.  Applications that use keys longer
   than B bytes will first hash the key using H and then use the
   resultant L byte string as the actual key to HMAC. In any case the
   minimal recommended length for K is L bytes (as the hash output
   length). See section 3 for more information on keys.

HMACの定義は、私たちがHで指示する暗号のハッシュ関数、およびK.WeがHであると仮定する秘密鍵がデータがブロックのデータでの基本的な圧縮機能を繰り返すことによって論じ尽くされる暗号のハッシュ関数であることを必要とします。 私たちはBそのようなもののバイト-長さのブロック(ハッシュ関数に関する上記のすべての例のためのB=64)、およびLで細切れ肉料理出力(MD5のためのL=16、SHA-1のためのL=20)のバイト-長さを指示します。 認証の主要なKはBまでのどんな長さ、ハッシュ関数のブロック長のものであることができます。 Bバイトより長い間キーを使用するアプリケーションが、最初に、Hを使用することでキーを論じ尽くして、次に、実際のキーとして結果のLバイトストリングをHMACに使用するでしょう。 どのような場合でも、Kのための最小量のお勧めの長さはLバイト(細切れ肉料理が長さを出力したので)です。 キーの詳しい情報に関してセクション3を見てください。

   We define two fixed and different strings ipad and opad as follows
   (the 'i' and 'o' are mnemonics for inner and outer):

私たちが異なったストリングの修理された2、ipad、および以下のopadを定義する、(より多くのinの間、'i'と'o'がニーモニックである、外側、)、:

                   ipad = the byte 0x36 repeated B times
                  opad = the byte 0x5C repeated B times.

opadがバイト0x5Cと等しいというバイト0x36に繰り返されたB ipad=回はB回を繰り返しました。

   To compute HMAC over the data `text' we perform

'テキスト'という私たちが実行するデータに関してHMACを計算するために

                    H(K XOR opad, H(K XOR ipad, text))

H(K XOR opad、H(K XOR ipad、テキスト))

   Namely,

すなわち

    (1) append zeros to the end of K to create a B byte string
        (e.g., if K is of length 20 bytes and B=64, then K will be
         appended with 44 zero bytes 0x00)
    (2) XOR (bitwise exclusive-OR) the B byte string computed in step
        (1) with ipad
    (3) append the stream of data 'text' to the B byte string resulting
        from step (2)
    (4) apply H to the stream generated in step (3)
    (5) XOR (bitwise exclusive-OR) the B byte string computed in
        step (1) with opad
    (6) append the H result from step (4) to the B byte string
        resulting from step (5)
    (7) apply H to the stream generated in step (6) and output
        the result

(1) Bバイトを作成するKでは、Bバイトストリングがステップ(1)でipad(3)で計算したストリング(例えば、Kが20バイトとB=64、当時のKが追加される長さのものであるなら、44はバイト0x00のゼロに合っている)(2)XOR(排他的論理和をbitwiseする)が'テキスト'というデータのストリームをBバイトストリングの結果になるのに追加する終わりにゼロを追加してください; (4)が適用するステップ(2)から、Bバイトストリングがステップ(1)でopad(6)で計算したステップ(3)(5)XOR(排他的論理和をbitwiseする)で発生する流れへのHはステップ(5)(7)から生じるストリングがステップ(6)で発生する流れにHを適用して、結果を出力するというステップ(4)からBバイトまでのH結果を追加します。

   For illustration purposes, sample code based on MD5 is provided as an
   appendix.

イラスト目的のために、付録としてMD5に基づくサンプルコードを提供します。

Krawczyk, et. al.            Informational                      [Page 3]

RFC 2104                          HMAC                     February 1997

et Krawczyk、アル。 [3ページ]情報のRFC2104HMAC1997年2月

3. Keys

3. キー

   The key for HMAC can be of any length (keys longer than B bytes are
   first hashed using H).  However, less than L bytes is strongly
   discouraged as it would decrease the security strength of the
   function.  Keys longer than L bytes are acceptable but the extra
   length would not significantly increase the function strength. (A
   longer key may be advisable if the randomness of the key is
   considered weak.)

HMACのためのキーはどんな長さ(Bバイトが最初にHを使用することで論じ尽くされるより長いキー)のものであることができます。 しかしながら、機能のセキュリティの強さを減少させるだろうというのに従って、Lバイト以下は強くがっかりしています。 Lバイトが許容できるより長いキーにもかかわらず、余分な長さは機能の強さをかなり増加させないでしょう。 (キーの偶発性が弱いと考えられるなら、より長いキーは賢明であるかもしれません。)

   Keys need to be chosen at random (or using a cryptographically strong
   pseudo-random generator seeded with a random seed), and periodically
   refreshed.  (Current attacks do not indicate a specific recommended
   frequency for key changes as these attacks are practically
   infeasible.  However, periodic key refreshment is a fundamental
   security practice that helps against potential weaknesses of the
   function and keys, and limits the damage of an exposed key.)

キーは、無作為(暗号でaを使用して、強い擬似ランダムジェネレータに無作為の種子で種を蒔いた)に選ばれていて、定期的にリフレッシュされる必要があります。 (これらの攻撃が実際に実行不可能であるので、現在の攻撃はキーチェンジのために特定のお勧めの頻度を示しません。 しかしながら、周期的な主要な軽い飲食物は機能、キー、および限界の潜在的弱点に対して露出しているキーの損害を助ける根本的なセキュリティ習慣です。)

4. Implementation Note

4. 実現注意

   HMAC is defined in such a way that the underlying hash function H can
   be used with no modification to its code. In particular, it uses the
   function H with the pre-defined initial value IV (a fixed value
   specified by each iterative hash function to initialize its
   compression function).  However, if desired, a performance
   improvement can be achieved at the cost of (possibly) modifying the
   code of H to support variable IVs.

HMACはコードへの変更なしで基本的なハッシュ関数Hを使用できるような方法で定義されます。 特に、それは事前に定義された初期の値IVがある機能Hを使用します(一定の価値は圧縮機能を初期化するためにそれぞれの繰り返しのハッシュ関数で指定しました)。 しかしながら、望まれているなら、可変IVsを支持するように(ことによると)Hのコードを変更する費用で性能改良を達成できます。

   The idea is that the intermediate results of the compression function
   on the B-byte blocks (K XOR ipad) and (K XOR opad) can be precomputed
   only once at the time of generation of the key K, or before its first
   use. These intermediate results are stored and then used to
   initialize the IV of H each time that a message needs to be
   authenticated.  This method saves, for each authenticated message,
   the application of the compression function of H on two B-byte blocks
   (i.e., on (K XOR ipad) and (K XOR opad)). Such a savings may be
   significant when authenticating short streams of data.  We stress
   that the stored intermediate values need to be treated and protected
   the same as secret keys.

考えは主要なKの世代時点の一度、またはその最初の使用の前にだけB-バイトブロック(K XOR ipad)と(K XOR opad)での圧縮機能の中間結果を前計算できるということです。 これらの中間結果は、各回メッセージが認証されるために必要とするIV Hを初期化するのに格納されて、次に、使用されます。 この方法は保存されます、それぞれの認証されたメッセージのために、2つのB-バイトブロック(すなわち、(K XOR ipad)と(K XOR opad)の)におけるHの圧縮機能の適用。 データの短いストリームを認証するとき、そのような貯蓄は重要であるかもしれません。 私たちは、格納された中間的値が秘密鍵として同じように扱われて、保護される必要であると強調します。

   Choosing to implement HMAC in the above way is a decision of the
   local implementation and has no effect on inter-operability.

上の方法でHMACを実行するのを選ぶのを、地方の実現の決定であり、相互運用性で効き目がありません。

Krawczyk, et. al.            Informational                      [Page 4]

RFC 2104                          HMAC                     February 1997

et Krawczyk、アル。 [4ページ]情報のRFC2104HMAC1997年2月

5. Truncated output

5. 端が欠けている出力

   A well-known practice with message authentication codes is to
   truncate the output of the MAC and output only part of the bits
   (e.g., [MM, ANSI]).  Preneel and van Oorschot [PV] show some
   analytical advantages of truncating the output of hash-based MAC
   functions. The results in this area are not absolute as for the
   overall security advantages of truncation. It has advantages (less
   information on the hash result available to an attacker) and
   disadvantages (less bits to predict for the attacker).  Applications
   of HMAC can choose to truncate the output of HMAC by outputting the t
   leftmost bits of the HMAC computation for some parameter t (namely,
   the computation is carried in the normal way as defined in section 2
   above but the end result is truncated to t bits). We recommend that
   the output length t be not less than half the length of the hash
   output (to match the birthday attack bound) and not less than 80 bits
   (a suitable lower bound on the number of bits that need to be
   predicted by an attacker).  We propose denoting a realization of HMAC
   that uses a hash function H with t bits of output as HMAC-H-t. For
   example, HMAC-SHA1-80 denotes HMAC computed using the SHA-1 function
   and with the output truncated to 80 bits.  (If the parameter t is not
   specified, e.g. HMAC-MD5, then it is assumed that all the bits of the
   hash are output.)

メッセージ確認コードがある周知の習慣は、MACの出力に先端を切らせて、ビット(例えば、[MM、ANSI])の一部だけを出力することになっています。 PreneelとバンOorschot[PV]は細切れ肉料理ベースのMAC機能の出力に先端を切らせるいくつかの分析利点を示しています。 この領域の結果はトランケーションの総合的なセキュリティ上の利点のように絶対ではありません。 それには、利点(攻撃者にとって、利用可能な細切れ肉料理結果の、より少ない情報)と損失(攻撃者のために予測するより少ないビット)があります。 HMACのアプリケーションは、HMACの出力に何らかのパラメタtのためのHMAC計算のt一番左ビットを出力することによって先端を切らせるのを選ぶことができます(すなわち、計算がセクション2の定義されるとしての正常な方法で上まで運ばれますが、結末はtビットに先端を切られます)。 私たちは、出力の長さtが少なくとも細切れ肉料理出力(誕生日の攻撃バウンドに合う)の長さの半分、少なくとも80ビット(攻撃者によって予測される必要があるビットの数における適当な下界)であることを推薦します。 私たちは、HMAC-H-tとして出力のtビットでハッシュ関数Hを使用するHMACの実現を指示するよう提案します。 例えば、HMAC-SHA1-80はSHA-1機能を使用することで計算されて、出力で80ビットに先端を切られたHMACを指示します。 (パラメタtが例えば、HMAC-MD5、指定されていて、次に、細切れ肉料理のすべてのビットが出力であると思われるということでないなら。)

6. Security

6. セキュリティ

   The security of the message authentication mechanism presented here
   depends on cryptographic properties of the hash function H: the
   resistance to collision finding (limited to the case where the
   initial value is secret and random, and where the output of the
   function is not explicitly available to the attacker), and the
   message authentication property of the compression function of H when
   applied to single blocks (in HMAC these blocks are partially unknown
   to an attacker as they contain the result of the inner H computation
   and, in particular, cannot be fully chosen by the attacker).

ここに提示されたメッセージ認証機構のセキュリティはハッシュ関数Hの暗号の所有地によります: 衝突調査結果(初期の値が秘密であって、無作為であり、攻撃者には、機能の出力が明らかに利用可能でないケースに制限される)、および単滑車に適用されると圧縮の認証の特性がHを機能させるという(HMACでは、それらを内側のH計算の結果を含んでいて、攻撃者が特に完全に選ぶことができるというわけではないので、攻撃者にとって、これらのブロックは部分的に未知です)メッセージへの抵抗。

   These properties, and actually stronger ones, are commonly assumed
   for hash functions of the kind used with HMAC. In particular, a hash
   function for which the above properties do not hold would become
   unsuitable for most (probably, all) cryptographic applications,
   including alternative message authentication schemes based on such
   functions.  (For a complete analysis and rationale of the HMAC
   function the reader is referred to [BCK1].)

これらの特性、および実際により強いものはHMACと共に使用される種類のハッシュ関数のために一般的に想定されます。 特に、上の特性が持ちこたえないハッシュ関数は大部分に、不適当な(たぶんすべて)暗号のアプリケーションになるでしょう、そのような機能に基づく代替の通報認証計画を含んでいて。 (HMAC機能の全分析と原理について、読者は言及されます[BCK1]。)

Krawczyk, et. al.            Informational                      [Page 5]

RFC 2104                          HMAC                     February 1997

et Krawczyk、アル。 [5ページ]情報のRFC2104HMAC1997年2月

   Given the limited confidence gained so far as for the cryptographic
   strength of candidate hash functions, it is important to observe the
   following two properties of the HMAC construction and its secure use
   for message authentication:

今までのところ候補ハッシュ関数の暗号の強さのように獲得されている限られた信用を考えて、HMAC工事の以下の2つの特性とその通報認証の安全な使用を観測するのは重要です:

   1. The construction is independent of the details of the particular
   hash function H in use and then the latter can be replaced by any
   other secure (iterative) cryptographic hash function.

1. 工事は使用中の特定のハッシュ関数Hの詳細から独立しています、そして、次に、後者をいかなる他の安全な(繰り返しの)暗号のハッシュ関数にも取り替えることができます。

   2. Message authentication, as opposed to encryption, has a
   "transient" effect. A published breaking of a message authentication
   scheme would lead to the replacement of that scheme, but would have
   no adversarial effect on information authenticated in the past.  This
   is in sharp contrast with encryption, where information encrypted
   today may suffer from exposure in the future if, and when, the
   encryption algorithm is broken.

2. 通報認証には、暗号化と対照的に、「一時的な」効果があります。 通報認証計画を発行された壊すのは、その計画の交換に通じるでしょうが、過去に認証された情報にどんな敵の影響も与えないでしょう。 これは著しい対照暗号化と共に中です、今日コード化されている情報が将来露出に苦しむかもしれないところでいつ(破られた暗号化アルゴリズム)

   The strongest attack known against HMAC is based on the frequency of
   collisions for the hash function H ("birthday attack") [PV,BCK2], and
   is totally impractical for minimally reasonable hash functions.

HMACに対して知られている中で最も強い攻撃は、ハッシュ関数H(「誕生日の攻撃」)[PV、BCK2]のために衝突の頻度に基づいていて、最少量で妥当なハッシュ関数に、完全に非実用的です。

   As an example, if we consider a hash function like MD5 where the
   output length equals L=16 bytes (128 bits) the attacker needs to
   acquire the correct message authentication tags computed (with the
   _same_ secret key K!) on about 2**64 known plaintexts.  This would
   require the processing of at least 2**64 blocks under H, an
   impossible task in any realistic scenario (for a block length of 64
   bytes this would take 250,000 years in a continuous 1Gbps link, and
   without changing the secret key K during all this time).  This attack
   could become realistic only if serious flaws in the collision
   behavior of the function H are discovered (e.g.  collisions found
   after 2**30 messages). Such a discovery would determine the immediate
   replacement of the function H (the effects of such failure would be
   far more severe for the traditional uses of H in the context of
   digital signatures, public key certificates, etc.).

例として、私たちが出力の長さがL=16バイト(128ビット)と等しいMD5のようなハッシュ関数を考えるなら、攻撃者は、**64のおよそ2で正しい(_の同じ_秘密鍵K!がある)通報認証タグが計算されたのを知られている平文を取得する必要があります。 これはH(どんな現実的なシナリオ(連続した1Gbpsリンクと、この時間中に秘密鍵Kを変えないで、64バイトのブロック長には、これは25万年かかる)の不可能なタスクも)の**64ブロック下で少なくとも2の処理を必要とするでしょう。 機能Hの衝突の振舞いにおける重大な欠陥が発見される場合にだけ(例えば、衝突は2**の後に30のメッセージに当たりました)、この攻撃は現実的になるかもしれません。 そのような発見は機能Hの即座の交換を決定するでしょう(デジタル署名、公開鍵証明書などの文脈における、Hの伝統的な用途には、そのような失敗の影響ははるかに厳しいでしょう)。

   Note: this attack needs to be strongly contrasted with regular
   collision attacks on cryptographic hash functions where no secret key
   is involved and where 2**64 off-line parallelizable (!) operations
   suffice to find collisions.  The latter attack is approaching
   feasibility [VW] while the birthday attack on HMAC is totally
   impractical.  (In the above examples, if one uses a hash function
   with, say, 160 bit of output then 2**64 should be replaced by 2**80.)

以下に注意してください。 この攻撃は、衝突を見つけるために強く秘密鍵が全くかかわらないで、2**64オフラインparallelizable (!)操作が十分である暗号のハッシュ関数に対する定期的な衝突攻撃に対して対照される必要があります。 HMACに対する誕生日の攻撃が完全に非実用的である間、後者の攻撃は実行可能性[VW]にアプローチしています。 (上記の例では、1つがたとえば、出力の160ビットがあるハッシュ関数を使用するなら、2**64を2**80に取り替えるべきです。)

Krawczyk, et. al.            Informational                      [Page 6]

RFC 2104                          HMAC                     February 1997

et Krawczyk、アル。 [6ページ]情報のRFC2104HMAC1997年2月

   A correct implementation of the above construction, the choice of
   random (or cryptographically pseudorandom) keys, a secure key
   exchange mechanism, frequent key refreshments, and good secrecy
   protection of keys are all essential ingredients for the security of
   the integrity verification mechanism provided by HMAC.

または、上の工事の正しい実現、無作為の選択、(暗号で、キーの擬似ランダム) キー、安全な主要な交換メカニズム、頻繁な主要な軽い飲食物、および良い秘密主義保護はすべてHMACによって提供された保全検証メカニズムのセキュリティのための不可欠の成分です。

Krawczyk, et. al.            Informational                      [Page 7]

RFC 2104                          HMAC                     February 1997

et Krawczyk、アル。 [7ページ]情報のRFC2104HMAC1997年2月

Appendix -- Sample Code

付録--サンプルコード

   For the sake of illustration we provide the following sample code for
   the implementation of HMAC-MD5 as well as some corresponding test
   vectors (the code is based on MD5 code as described in [MD5]).

イラストのために、私たちはいくつかの対応するテストベクトルと同様にHMAC-MD5の実現に以下のサンプルコードを提供します(コードは[MD5]で説明されるようにMD5コードに基づいています)。

/*
** Function: hmac_md5
*/

/***機能: hmac_md5*/

void
hmac_md5(text, text_len, key, key_len, digest)
unsigned char*  text;                /* pointer to data stream */
int             text_len;            /* length of data stream */
unsigned char*  key;                 /* pointer to authentication key */
int             key_len;             /* length of authentication key */
caddr_t         digest;              /* caller digest to be filled in */

hmac_md5(テキスト、テキスト_len、キー、キー_lenは読みこなされる)の無記名の炭*テキストを欠如させてください。 データへの/*ポインタは*/intテキスト_lenを流します。 データ・ストリーム*/無記名の炭*キーの/*長さ。 認証主要な*/intキー_lenへの/*ポインタ。 認証主要な*/caddr_tダイジェストの/*長さ。 */にいっぱいにされるべき/*訪問者ダイジェスト

{
        MD5_CTX context;
        unsigned char k_ipad[65];    /* inner padding -
                                      * key XORd with ipad
                                      */
        unsigned char k_opad[65];    /* outer padding -
                                      * key XORd with opad
                                      */
        unsigned char tk[16];
        int i;
        /* if key is longer than 64 bytes reset it to key=MD5(key) */
        if (key_len > 64) {

*MD5_CTX文脈; 無記名の炭のk_ipad[65];/内側の詰め物--**キーが(キー_len>64)であるなら=MD5(主要な)*/を合わせるために64バイトがそれをリセットしたより長いなら、opad*/無記名の炭のtk[16]; int i; /に従って、ipadが*/無記名であることの主要なXORdはk_opad[65]; /*外側の詰め物--*主要なXORdを炭にします。

                MD5_CTX      tctx;

MD5_CTX tctx。

                MD5Init(&tctx);
                MD5Update(&tctx, key, key_len);
                MD5Final(tk, &tctx);

MD5Init(tctx)。 MD5Update(tctx、キー、キー_len)。 MD5Final(tk、およびtctx)。

                key = tk;
                key_len = 16;
        }

主要な=tk。 主要な_len=16。 }

        /*
         * the HMAC_MD5 transform looks like:
         *
         * MD5(K XOR opad, MD5(K XOR ipad, text))
         *
         * where K is an n byte key
         * ipad is the byte 0x36 repeated 64 times

HMAC_MD5が変える/**に似ています: * * MD5、(K XOR opad、MD5、(テキスト) K XOR ipad、Kが*ipadにnバイトのキーである**はバイト0x36に繰り返された64回です。

Krawczyk, et. al.            Informational                      [Page 8]

RFC 2104                          HMAC                     February 1997

et Krawczyk、アル。 [8ページ]情報のRFC2104HMAC1997年2月

         * opad is the byte 0x5c repeated 64 times
         * and text is the data being protected
         */

* opadは64回*繰り返されたバイト0x5cです、そして、テキストによる保護された*/であるデータです。

        /* start out by storing key in pads */
        bzero( k_ipad, sizeof k_ipad);
        bzero( k_opad, sizeof k_opad);
        bcopy( key, k_ipad, key_len);
        bcopy( key, k_opad, key_len);

キーを蓄えるのによる/*始めは*/bzero(k_ipad、sizeof k_ipad)を水増しします。 bzero(k_opad、sizeof k_opad)。 bcopy(キー、k_ipad、キー_len)。 bcopy(キー、k_opad、キー_len)。

        /* XOR key with ipad and opad values */
        for (i=0; i<64; i++) {
                k_ipad[i] ^= 0x36;
                k_opad[i] ^= 0x5c;
        }
        /*
         * perform inner MD5
         */
        MD5Init(&context);                   /* init context for 1st
                                              * pass */
        MD5Update(&context, k_ipad, 64)      /* start with inner pad */
        MD5Update(&context, text, text_len); /* then text of datagram */
        MD5Final(digest, &context);          /* finish up 1st pass */
        /*
         * perform outer MD5
         */
        MD5Init(&context);                   /* init context for 2nd
                                              * pass */
        MD5Update(&context, k_opad, 64);     /* start with outer pad */
        MD5Update(&context, digest, 16);     /* then results of 1st
                                              * hash */
        MD5Final(digest, &context);          /* finish up 2nd pass */
}

(i=0; i<64; i++)k_ipad[i]^=0x36; k_opad[i]^=0x5c;/**に、ipadとopad値*/によって主要な/*XORは内側のMD5*/MD5Init(文脈)を実行します。 最初*のパス*/MD5Updateのための/*イニット文脈、(文脈、k_ipad、64)/*が内側のパッド*/MD5Update(文脈、テキスト、テキスト_len)から始まります。 データグラム*/MD5Final(ダイジェスト、および文脈)の/*当時のテキスト。 最初のパス*//**への/*終わりは外側のMD5*/MD5Init(文脈)を実行します。 第2*パス*/MD5Updateのための/*イニット文脈、(文脈、k_opad、64)。 外側のパッド*/MD5Updateとの/*始め、(文脈、ダイジェスト、16)。 最初の*の/*当時の結果は*/MD5Final(ダイジェスト、および文脈)を論じ尽くします。 2番目のパス*/への/*終わり

Test Vectors (Trailing '%%BODY%%' of a character string not included in test):

'Vectors(テストに含まれていなかった文字列の引きずっている'0円')をテストしてください:

  key =         0x0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b
  key_len =     16 bytes
  data =        "Hi There"
  data_len =    8  bytes
  digest =      0x9294727a3638bb1c13f48ef8158bfc9d

8= 「やあ」という=0x0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0bの_のlenの=の16バイトの主要なデータデータ_len=バイトの主要なダイジェスト=0x9294727a3638bb1c13f48ef8158bfc9d

  key =         "Jefe"
  data =        "what do ya want for nothing?"
  data_len =    28 bytes
  digest =      0x750c783e6ab0b503eaa86e310a5db738

「あなたは無駄に何が欲しいですか?」の28データ_len=バイトの主要な="Jefe"データ=ダイジェストは0x750c783e6ab0b503eaa86e310a5db738と等しいです。

  key =         0xAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

主要な=0xAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

Krawczyk, et. al.            Informational                      [Page 9]

RFC 2104                          HMAC                     February 1997

et Krawczyk、アル。 [9ページ]情報のRFC2104HMAC1997年2月

  key_len       16 bytes
  data =        0xDDDDDDDDDDDDDDDDDDDD...
                ..DDDDDDDDDDDDDDDDDDDD...
                ..DDDDDDDDDDDDDDDDDDDD...
                ..DDDDDDDDDDDDDDDDDDDD...
                ..DDDDDDDDDDDDDDDDDDDD
  data_len =    50 bytes
  digest =      0x56be34521d144c88dbb8c733f0e8b3f6

_のlenの16バイトの主要なデータは0xDDDDDDDDDDDDDDDDDDDDと等しいです… ..DDDDDDDDDDDDDDDDDDDD… ..DDDDDDDDDDDDDDDDDDDD… ..DDDDDDDDDDDDDDDDDDDD… ..DDDDDDDDDDDDDDDDDDDDデータ_lenは50バイトのダイジェスト=0x56be34521d144c88dbb8c733f0e8b3f6と等しいです。

Acknowledgments

承認

   Pau-Chen Cheng, Jeff Kraemer, and Michael Oehler, have provided
   useful comments on early drafts, and ran the first interoperability
   tests of this specification. Jeff and Pau-Chen kindly provided the
   sample code and test vectors that appear in the appendix.  Burt
   Kaliski, Bart Preneel, Matt Robshaw, Adi Shamir, and Paul van
   Oorschot have provided useful comments and suggestions during the
   investigation of the HMAC construction.

マイケル・オーラー、早いことの提供された役に立つコメントを持ってください。そして、ポー-チェン、チェン、ジェフ・クラーメル、この仕様の最初の相互運用性テストを作成して、走らせました。 ジェフとポー-チェンは親切に付録に載っているサンプルコードとテストベクトルを提供しました。 バートKaliski、バードPreneel、マット・Robshaw、アディシャミル、およびポールバンOorschotはHMAC工事の調査の間、役に立つコメントと提案を提供しています。

References

参照

   [ANSI]  ANSI X9.9, "American National Standard for Financial
           Institution Message Authentication (Wholesale)," American
           Bankers Association, 1981.   Revised 1986.

[ANSI]ANSI X9.9、「金融機関通報認証(大量の)のための米国標準規格」、アメリカ銀行家協会、1981。 1986を改訂しました。

   [Atk]   Atkinson, R., "IP Authentication Header", RFC 1826, August
           1995.

[Atk] アトキンソン、R.、「IP認証ヘッダー」、RFC1826、1995年8月。

   [BCK1]  M. Bellare, R. Canetti, and H. Krawczyk,
           "Keyed Hash Functions and Message Authentication",
           Proceedings of Crypto'96, LNCS 1109, pp. 1-15.
           (http://www.research.ibm.com/security/keyed-md5.html)

[BCK1] M.Bellare、R.カネッティ、およびH.Krawczyk、「合わせられて、機能を論じ尽くしてください、そして、認証を通信させてください」、Crypto LNCS1109 96年、ページのProceedings 1-15. ( http://www.research.ibm.com/security/keyed-md5.html )

   [BCK2]  M. Bellare, R. Canetti, and H. Krawczyk,
           "Pseudorandom Functions Revisited: The Cascade Construction",
           Proceedings of FOCS'96.

[BCK2] M.Bellare、R.カネッティ、およびH.Krawczyk、「擬似ランダムは再訪していた状態で機能します」。 「滝の工事」、FOCS96年の議事。

   [Dobb]  H. Dobbertin, "The Status of MD5  After a Recent Attack",
           RSA Labs' CryptoBytes, Vol. 2 No. 2, Summer 1996.
           http://www.rsa.com/rsalabs/pubs/cryptobytes.html

[ドッブ]H.Dobbertin、「最近の攻撃の後のMD5の状態」、RSA研究室のCryptoBytes、Vol.2No.2(1996年夏) http://www.rsa.com/rsalabs/pubs/cryptobytes.html

   [PV]    B. Preneel and P. van Oorschot, "Building fast MACs from hash
           functions", Advances in Cryptology -- CRYPTO'95 Proceedings,
           Lecture Notes in Computer Science, Springer-Verlag Vol.963,
           1995, pp. 1-14.

[PV]B.PreneelとP.はOorschotをバンに積みます、「ハッシュ関数から速いMACsを造っ」て、CryptologyのAdvances--CRYPTO95年Proceedings、コンピュータScienceのLecture Notes、Springer-Verlag Vol.963、1995、ページ 1-14.

   [MD5]   Rivest, R., "The MD5 Message-Digest Algorithm",
           RFC 1321, April 1992.

[MD5] Rivest、R.、「MD5メッセージダイジェストアルゴリズム」、RFC1321、1992年4月。

Krawczyk, et. al.            Informational                     [Page 10]

RFC 2104                          HMAC                     February 1997

et Krawczyk、アル。 [10ページ]情報のRFC2104HMAC1997年2月

   [MM]    Meyer, S. and Matyas, S.M., Cryptography, New York Wiley,
           1982.

[mm] マイヤーとS.とマーチャーシュ、S.M.、暗号、ニューヨークワイリー、1982

   [RIPEMD] H. Dobbertin, A. Bosselaers, and B. Preneel, "RIPEMD-160: A
            strengthened version of RIPEMD", Fast Software Encryption,
            LNCS Vol 1039, pp. 71-82.
            ftp://ftp.esat.kuleuven.ac.be/pub/COSIC/bosselae/ripemd/.

[RIPEMD]H.Dobbertin、A.Bosselaers、およびB.Preneel、「RIPEMD-160:」 「RIPEMDの強まっているバージョン」、Fast Software Encryption、LNCS Vol1039、ページ 71-82 ftp://ftp.esat.kuleuven.ac.be/pub/COSIC/bosselae/ripemd/ 。

   [SHA]   NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995.

[SHA]NIST、FIPSパブ180-1: 細切れ肉料理規格、1995年4月を確保してください。

   [Tsu]   G. Tsudik, "Message authentication with one-way hash
           functions", In Proceedings of Infocom'92, May 1992.
           (Also in "Access Control and Policy Enforcement in
            Internetworks", Ph.D. Dissertation, Computer Science
            Department, University of Southern California, April 1991.)

[津]G.Tsudik、「片道ハッシュ関数がある通報認証」、Infocom92年、1992年5月のIn Proceedings。 (「インターネットワークにおけるアクセス管理と方針実施」、も博士号Dissertation、コンピュータ理学部、南カリフォルニア大学、4月1991)

   [VW]    P. van Oorschot and M. Wiener, "Parallel Collision
           Search with Applications to Hash Functions and Discrete
           Logarithms", Proceedings of the 2nd ACM Conf. Computer and
           Communications Security, Fairfax, VA, November 1994.

[VW] P. OorschotとM.Wiener、「ハッシュ関数と離散対数へのアプリケーションとの平行な衝突検索」をバンに積んでください、第2ACM ConfのProceedings。 コンピュータと通信秘密保全、フェアファクス、ヴァージニア、1994年11月。

Authors' Addresses

作者のアドレス

   Hugo Krawczyk
   IBM T.J. Watson Research Center
   P.O.Box 704
   Yorktown Heights, NY 10598

ニューヨーク ユーゴーKrawczyk IBM T.J.ワトソン研究所私書箱704ヨークタウンの高さ、10598

   EMail: hugo@watson.ibm.com

メール: hugo@watson.ibm.com

   Mihir Bellare
   Dept of Computer Science and Engineering
   Mail Code 0114
   University of California at San Diego
   9500 Gilman Drive
   La Jolla, CA 92093

コンピュータサイエンスのMihir Bellare部と工学メールコード0114カリフォルニア大学サンディエゴ校9500ギルマン・ドライブラ・ホーヤ、カリフォルニア 92093

   EMail: mihir@cs.ucsd.edu

メール: mihir@cs.ucsd.edu

   Ran Canetti
   IBM T.J. Watson Research Center
   P.O.Box 704
   Yorktown Heights, NY 10598

ニューヨーク カネッティIBM T.J.ワトソン研究所私書箱704ヨークタウンの高さ、10598を走らせました。

   EMail: canetti@watson.ibm.com

メール: canetti@watson.ibm.com

Krawczyk, et. al.            Informational                     [Page 11]

et Krawczyk、アル。 情報[11ページ]