[要約] RFC 7664は、Dragonfly Key Exchangeという安全なパスワードベースの認証および鍵交換プロトコルに関する文書です。このプロトコルは、低計算能力を持つデバイス間での安全な通信を可能にすることを目的としており、Wi-Fi Protected Access (WPA3) などの無線ネットワークセキュリティで利用されています。関連するRFCにはRFC 7914（SRP: Secure Remote Password Protocol）があり、これもパスワードベースの認証メカニズムを提供しますが、Dragonflyは特に効率的な鍵交換を実現する点で異なります。
Internet Research Task Force (IRTF) D. Harkins, Ed.
Request for Comments: 7664 Aruba Networks
Category: Informational November 2015
ISSN: 2070-1721
Dragonfly Key Exchange
トンボの鍵交換
Abstract
概要
This document specifies a key exchange using discrete logarithm cryptography that is authenticated using a password or passphrase. It is resistant to active attack, passive attack, and offline dictionary attack. This document is a product of the Crypto Forum Research Group (CFRG).
このドキュメントでは、パスワードまたはパスフレーズを使用して認証される離散対数暗号化を使用する鍵交換を指定します。能動的攻撃、受動的攻撃、オフライン辞書攻撃に耐性があります。このドキュメントは、Crypto Forum Research Group（CFRG）の製品です。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the individual opinion(s) of one or more members of the Crypto Forum Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
この文書は、Internet Research Task Force（IRTF）の製品です。 IRTFは、インターネット関連の研究開発活動の結果を公開しています。これらの結果は、展開に適さない可能性があります。このRFCは、インターネットリサーチタスクフォース（IRTF）の暗号フォーラム研究グループの1人以上のメンバーの個々の意見を表します。 IRSGによる公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 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/rfc7664.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7664で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 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.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2
1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.1. Notations . . . . . . . . . . . . . . . . . . . . . . 3
1.2.2. Resistance to Dictionary Attack . . . . . . . . . . . 3
2. Discrete Logarithm Cryptography . . . . . . . . . . . . . . . 4
2.1. Elliptic Curve Cryptography . . . . . . . . . . . . . . . 4
2.2. Finite Field Cryptography . . . . . . . . . . . . . . . . 5
3. The Dragonfly Key Exchange . . . . . . . . . . . . . . . . . 6
3.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Derivation of the Password Element . . . . . . . . . . . 8
3.2.1. Hunting and Pecking with ECC Groups . . . . . . . . . 10
3.2.2. Hunting and Pecking with MODP Groups . . . . . . . . 12
3.3. The Commit Exchange . . . . . . . . . . . . . . . . . . . 13
3.4. The Confirm Exchange . . . . . . . . . . . . . . . . . . 14
4. Security Considerations . . . . . . . . . . . . . . . . . . . 15
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.1. Normative References . . . . . . . . . . . . . . . . . . 16
5.2. Informative References . . . . . . . . . . . . . . . . . 16
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18
Passwords and passphrases are the predominant way of doing authentication in the Internet today. Many protocols that use passwords and passphrases for authentication exchange password-derived data as a proof-of-knowledge of the password (for example, [RFC7296] and [RFC5433]). This opens the exchange up to an offline dictionary attack where the attacker gleans enough knowledge from either an active or passive attack on the protocol to run through a pool of potential passwords and compute verifiers until it is able to match the password-derived data.
今日のインターネットでは、パスワードとパスフレーズが主な認証方法です。認証にパスワードとパスフレーズを使用する多くのプロトコルは、パスワードから得られたデータをパスワードの知識の証明として交換します（たとえば、[RFC7296]と[RFC5433]）。これにより、オフラインの辞書攻撃に至るまでのやり取りが開かれ、攻撃者はプロトコルに対するアクティブまたはパッシブな攻撃から十分な知識を集めて、潜在的なパスワードのプールを実行し、パスワードから派生したデータと一致するまで検証を計算します。
This protocol employs discrete logarithm cryptography to perform an efficient exchange in a way that performs mutual authentication using a password that is provably resistant to an offline dictionary attack. Consensus of the CFRG for this document was rough.
このプロトコルは、離散対数暗号化を採用して、オフライン辞書攻撃に耐性があると考えられるパスワードを使用して相互認証を実行する方法で効率的な交換を実行します。このドキュメントに対するCFRGのコンセンサスは大雑把でした。
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 RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
The following notations are used in this memo.
このメモでは、次の表記が使用されています。
password A shared, secret, and potentially low-entropy word, phrase, code, or key used as a credential to mutually authenticate the peers. It is not restricted to characters in a human language.
パスワードピアを相互認証するための資格情報として使用される、共有された、秘密の、潜在的に低エントロピーの単語、フレーズ、コード、またはキー。人間の言語の文字に限定されません。
a | b denotes concatenation of bit string "a" with bit string "b".
a | bは、ビット文字列 "a"とビット文字列 "b"の連結を示します。
len(a) indicates the length in bits of the bit string "a".
len（a）は、ビット文字列 "a"のビット長を示します。
lsb(a) returns the least-significant bit of the bit string "a".
lsb（a）は、ビット文字列 "a"の最下位ビットを返します。
lgr(a,b) takes "a" and a prime, "b", and returns the Legendre symbol (a/b).
lgr（a、b）は "a"と素数 "b"を取り、ルジャンドル記号（a / b）を返します。
min(a,b) returns the lexicographical minimum of strings "a" and "b", or zero (0) if "a" equals "b".
min（a、b）は、文字列 "a"と "b"の辞書式最小値を返します。 "a"が "b"と等しい場合はゼロ（0）を返します。
max(a,b) returns the lexicographical maximum of strings "a" and "b", or zero (0) if "a" equals "b".
max（a、b）は、文字列 "a"と "b"の辞書式の最大値、または "a"が "b"と等しい場合はゼロ（0）を返します。
The convention for this memo is to represent an element in a finite cyclic group with an uppercase letter or acronym, while a scalar is indicated with a lowercase letter or acronym. An element that represents a point on an elliptic curve has an implied composite nature -- i.e., it has both an x- and y-coordinate.
このメモの規約は、有限の循環グループの要素を大文字または頭字語で表すことですが、スカラーは小文字または頭字語で示します。楕円曲線上の点を表す要素は、暗黙の複合的な性質を持っています。つまり、x座標とy座標の両方を持っています。
Resistance to dictionary attack means that any advantage an adversary can gain must be directly related to the number of interactions she makes with an honest protocol participant and not through computation. The adversary will not be able to obtain any information about the password except whether a single guess from a protocol run is correct or incorrect.
辞書攻撃への抵抗とは、攻撃者が得ることができる利点は、計算ではなく、正直なプロトコル参加者とのやり取りの数に直接関係する必要があることを意味します。攻撃者は、プロトコル実行からの単一の推測が正しいか正しくないかを除いて、パスワードに関する情報を取得できません。
Dragonfly uses discrete logarithm cryptography to achieve authentication and key agreement (see [SP800-56A]). Each party to the exchange derives ephemeral keys with respect to a particular set of domain parameters (referred to here as a "group"). A group can be based on Finite Field Cryptography (FFC) or Elliptic Curve Cryptography (ECC).
Dragonflyは、離散対数暗号を使用して認証と鍵の合意を実現します（[SP800-56A]を参照）。取引所の各当事者は、ドメインパラメータの特定のセット（ここでは「グループ」と呼ばれます）に関する一時キーを導出します。グループは、有限フィールド暗号（FFC）または楕円曲線暗号（ECC）に基づくことができます。
Three operations are defined for both types of groups:
両方のタイプのグループに対して3つの操作が定義されています。
o "scalar operation" -- takes a scalar and an element in the group to produce another element -- Z = scalar-op(x, Y).
o 「スカラー演算」-グループ内のスカラーと要素を取り、別の要素を生成します-Z = scalar-op（x、Y）。
o "element operation" -- takes two elements in the group to produce a third -- Z = element-op(X, Y).
o 「要素演算」-グループ内の2つの要素を使用して、3番目の要素を生成します-Z = element-op（X、Y）。
o "inverse operation" -- takes an element and returns another element such that the element operation on the two produces the identity element of the group -- Y = inverse(X).
o 「逆演算」-要素を受け取り、2つの要素の演算がグループの単位要素を生成するように別の要素を返します-Y = reverse（X）。
Domain parameters for the ECC groups used by Dragonfly are:
Dragonflyが使用するECCグループのドメインパラメータは次のとおりです。
o A prime, p, determining a prime field GF(p). The cryptographic group will be a subgroup of the full elliptic curve group that consists of points on an elliptic curve -- elements from GF(p) that satisfy the curve's equation -- together with the "point at infinity" that serves as the identity element. The group operation for ECC groups is addition of points on the elliptic curve.
o 素数pは、素体GF（p）を決定します。暗号グループは、楕円曲線上の点（曲線の方程式を満たすGF（p）の要素）と、恒等要素として機能する「無限遠点」で構成される完全な楕円曲線グループのサブグループになります。 。 ECCグループのグループ操作は、楕円曲線上の点の追加です。
o Elements a and b from GF(p) that define the curve's equation. The point (x, y) in GF(p) x GF(p) is on the elliptic curve if and only if (y^2 - x^3 - a*x - b) mod p equals zero (0).
o 曲線の方程式を定義するGF（p）の要素aおよびb。 （y ^ 2-x ^ 3-a * x-b）mod pがゼロ（0）に等しい場合に限り、GF（p）x GF（p）の点（x、y）は楕円曲線上にあります。
o A point, G, on the elliptic curve, which serves as a generator for the ECC group. G is chosen such that its order, with respect to elliptic curve addition, is a sufficiently large prime.
o ECCグループのジェネレーターとして機能する楕円曲線上の点G。 Gは、楕円曲線の追加に関して、その次数が十分に大きな素数になるように選択されます。
o A prime, q, which is the order of G, and thus is also the size of the cryptographic subgroup that is generated by G.
o Gの次数である素数qは、Gによって生成される暗号サブグループのサイズでもあります。
An (x,y) pair is a valid ECC element if: 1) the x- and y-coordinates are both greater than zero (0) and less than the prime defining the underlying field; and, 2) the x- and y-coordinates satisfy the equation for the curve and produce a valid point on the curve that is not the point at infinity. If either one of those conditions do not hold, the (x,y) pair is not a valid element.
（x、y）ペアは、次の場合に有効なECC要素です。1）x座標とy座標の両方がゼロ（0）より大きく、基礎となるフィールドを定義する素数よりも小さい。 2）x座標とy座標は曲線の方程式を満たし、無限遠点ではない有効な曲線上の点を生成します。これらの条件のいずれかが満たされない場合、（x、y）のペアは有効な要素ではありません。
The scalar operation is addition of a point on the curve with itself a number of times. The point Y is multiplied x times to produce another point Z:
スカラー操作とは、曲線上の点をそれ自体と何度も加算することです。点Yがx回乗算されて、別の点Zが生成されます。
Z = scalar-op(x, Y) = x*Y
The element operation is addition of two points on the curve. Points X and Y are summed to produce another point Z:
要素の操作は、曲線上の2点の加算です。ポイントXとYを合計して、別のポイントZを生成します。
Z = element-op(X, Y) = X + Y
The inverse function is defined such that the sum of an element and its inverse is "0", the point at infinity of an elliptic curve group:
逆関数は、要素とその逆の合計が楕円曲線グループの無限遠点である「0」になるように定義されます。
R + inverse(R) = "0"
Elliptic curve groups require a mapping function, q = F(Q), to convert a group element to an integer. The mapping function used in this memo returns the x-coordinate of the point it is passed.
楕円曲線グループには、グループ要素を整数に変換するためのマッピング関数q = F（Q）が必要です。このメモで使用されているマッピング関数は、渡された点のx座標を返します。
scalar-op(x, Y) can be viewed as x iterations of element-op() by defining:
scalar-op（x、Y）は、以下を定義することにより、element-op()のx回の反復と見なすことができます。
Y = scalar-op(1, Y)
Y =スカラー演算（1、Y）
Y = scalar-op(x, Y) = element-op(Y, scalar-op(x-1, Y)), for x > 1
A definition of how to add two points on an elliptic curve (i.e., element-op(X, Y)) can be found in [RFC6090].
楕円曲線に2つの点を追加する方法の定義（つまり、element-op（X、Y））は、[RFC6090]にあります。
Note: There is another elliptic curve domain parameter, a cofactor, h, that is defined by the requirement that the size of the full elliptic curve group (including "0") be the product of h and q. Elliptic curve groups used with Dragonfly authentication MUST have a cofactor of one (1).
注：別の楕円曲線領域パラメーター、補因子hがあります。これは、完全な楕円曲線グループ（「0」を含む）のサイズがhとqの積であるという要件によって定義されます。 Dragonfly認証で使用される楕円曲線グループには、補因子1が必要です。
Domain parameters for the FFC groups used in Dragonfly are:
Dragonflyで使用されるFFCグループのドメインパラメータは次のとおりです。
o A prime, p, determining a prime field GF(p), the integers modulo p. The FFC group will be a subgroup of GF(p)*, the multiplicative group of non-zero elements in GF(p). The group operation for FFC groups is multiplication modulo p.
o 素数p、素数体GF（p）、pを法とする整数を決定します。 FFCグループは、GF（p）*のサブグループであり、GF（p）の非ゼロ要素の乗法グループです。 FFCグループのグループ演算は、pを法とする乗算です。
o An element, G, in GF(p)* which serves as a generator for the FFC group. G is chosen such that its multiplicative order is a sufficiently large prime divisor of ((p-1)/2).
o FFCグループのジェネレーターとして機能するGF（p）*の要素G。 Gは、その乗算次数が（（p-1）/ 2）の十分に大きな素数になるように選択されます。
o A prime, q, which is the multiplicative order of G, and thus also the size of the cryptographic subgroup of GF(p)* that is generated by G.
o Gの乗法次数である素数q、したがってGによって生成されるGF（p）*の暗号サブグループのサイズ。
A number is a valid element in an FFC group if: 1) it is between one (1) and one (1) less than the prime, p, exclusive (i.e., 1 < element < p-1); and, 2) if modular exponentiation of the element by the group order, q, equals one (1). If either one of those conditions do not hold, the number is not a valid element.
次の場合、数値はFFCグループ内の有効な要素です。1）プライムよりも1から1小さい（p <排他的）（つまり、1 <element <p-1）。そして、2）グループの次数による要素のモジュラ指数qが1に等しい場合。これらの条件のいずれかが満たされない場合、数値は有効な要素ではありません。
The scalar operation is exponentiation of a generator modulo a prime. An element Y is taken to the x-th power modulo the prime returning another element, Z:
スカラー演算は、素数を法とするジェネレータの累乗です。要素Yは、別の要素Zを返す素数を法としてx乗されます。
Z = scalar-op(x, Y) = Y^x mod p
The element operation is modular multiplication. Two elements, X and Y, are multiplied modulo the prime returning another element, Z:
要素演算はモジュラー乗算です。 2つの要素XとYは、素数を法として乗算され、別の要素Zを返します。
Z = element-op(X, Y) = (X * Y) mod p
The inverse function for a MODP group is defined such that the product of an element and its inverse modulo the group prime equals one (1). In other words,
MODPグループの逆関数は、要素の素数とグループの素数を法とするその逆の積が1になるように定義されています。言い換えると、
(R * inverse(R)) mod p = 1
There are two parties to the Dragonfly exchange named, for convenience and by convention, Alice and Bob. The two parties have a shared password that was established in an out-of-band mechanism, and they both agree to use a particular domain parameter set (either ECC or FFC). In the Dragonfly exchange, both Alice and Bob share an identical view of the shared password -- i.e., it is not "augmented", where one side holds a password and the other side holds a non-invertible verifier. This allows Dragonfly to be used in traditional client-server protocols and also in peer-to-peer applications in which there are not fixed roles and either party may initiate the exchange (and both parties may implement it simultaneously).
便宜上および慣例により、アリスとボブという名前のDragonfly取引所には2つの当事者があります。 2つのパーティは、アウトオブバンドメカニズムで確立された共有パスワードを持ち、両者は特定のドメインパラメータセット（ECCまたはFFC）を使用することに同意します。 Dragonfly交換では、アリスとボブの両方が共有パスワードの同一のビューを共有します。つまり、一方がパスワードを保持し、もう一方が非可逆的な検証者を保持する「拡張」されていません。これにより、Dragonflyを従来のクライアントサーバープロトコルで使用したり、固定の役割がなく、いずれかの当事者が交換を開始したりできる（両方の当事者が同時に実装する可能性がある）ピアツーピアアプリケーションでも使用できます。
Prior to beginning the Dragonfly exchange, the two peers MUST derive a secret element in the chosen domain parameter set. Two "hunting-and-pecking" techniques to determine a secret element, one for ECC and one for FFC, are described in Section 3.2, but any secure, deterministic method that is agreed upon can be used. For instance, the technique described in [hash2ec] can be used for ECC groups.
Dragonfly交換を開始する前に、2つのピアは、選択されたドメインパラメータセットの秘密要素を導出する必要があります。 1つはECC、もう1つはFFCの秘密要素を決定するための2つの「ハンティングアンドペッキング」手法については、セクション3.2で説明していますが、合意された安全で確定的な方法を使用できます。たとえば、[hash2ec]で説明されている手法は、ECCグループに使用できます。
The Dragonfly exchange consists of two message exchanges, a "Commit Exchange" in which both sides commit to a single guess of the password, and a "Confirm Exchange" in which both sides confirm knowledge of the password. A side effect of running the Dragonfly exchange is an authenticated, shared, and secret key whose cryptographic strength is set by the agreed-upon group.
Dragonfly交換は、2つのメッセージ交換で構成されます。「コミット交換」では、両側がパスワードの単一の推測にコミットします。「確認交換」では、両側がパスワードの知識を確認します。 Dragonfly交換を実行することの副作用は、暗号化強度が合意されたグループによって設定される、認証、共有、および秘密鍵です。
Dragonfly uses a random function, H(), a mapping function, F(), and a key derivation function, KDF().
Dragonflyは、ランダム関数H()、マッピング関数F()、およびキー導出関数KDF()を使用します。
In order to avoid attacks on the Dragonfly protocol, some basic assumptions are made:
Dragonflyプロトコルへの攻撃を回避するために、いくつかの基本的な仮定が行われます。
1. Function H is a "random oracle" (see [RANDOR]) that maps a binary string of indeterminate length onto a fixed binary string that is x bits in length.
1. 関数Hは、長さが不定のバイナリ文字列を長さがxビットの固定バイナリ文字列にマッピングする「ランダムオラクル」（[RANDOR]を参照）です。
H: {0,1}^* --> {0,1}^x
2. Function F is a mapping function that takes an element in a group and returns an integer. For ECC groups, function F() returns the x-coordinate of the element (which is a point on the elliptic curve); for FFC groups, function F() is the identity function (since all elements in an FFC group are already integers less than the prime).
2. 関数Fは、グループ内の要素を取り、整数を返すマッピング関数です。 ECCグループの場合、関数F()は要素（楕円曲線上の点）のx座標を返します。 FFCグループの場合、関数F()は恒等関数です（FFCグループのすべての要素は素数よりも小さい整数になっているため）。
ECC: x = F(P), where P=(x,y)
FFC: x = F(x)
3. Function KDF is a key derivation function (see, for instance, [SP800-108]) that takes a key to stretch, k, a label to bind to the key, label, and an indication of the desired output, n:
3. 関数KDFは、キー導出関数（たとえば、[SP800-108]を参照）で、ストレッチするキーk、キーにバインドするラベル、ラベル、および目的の出力の指示nを受け取ります。
stretch = KDF-n(k, label)
ストレッチ= KDF-n（k、ラベル）
so that len(stretch) equals n.
len（stretch）がnと等しくなるようにします。
4. The discrete logarithm problem for the chosen group is hard. That is, given G, P, and Y = G^x mod p, it is computationally infeasible to determine x. Similarly, for an ECC group given the curve definition, a generator G, and Y = x * G, it is computationally infeasible to determine x.
4. 選択したグループの離散対数問題は困難です。つまり、G、P、およびY = G ^ x mod pの場合、xを決定することは計算上不可能です。同様に、曲線の定義が与えられたECCグループ、ジェネレーターG、およびY = x * Gの場合、xを決定することは計算上実行不可能です。
5. There exists a pool of passwords from which the password shared by the two peers is drawn. This pool can consist of words from a dictionary, for example. Each password in this pool has an equal probability of being the shared password. All potential attackers have access to this pool of passwords.
5. 2つのピアが共有するパスワードを引き出すパスワードのプールが存在します。このプールは、たとえば、辞書の単語で構成できます。このプール内の各パスワードは、共有パスワードである確率が同じです。すべての潜在的な攻撃者は、このパスワードのプールにアクセスできます。
6. The peers have the ability to produce quality random numbers.
6. ピアは、高品質の乱数を生成することができます。
Prior to beginning the exchange of information, the peers MUST derive a secret element, called the Password Element (PE), in the group defined by the chosen domain parameter set. From the point of view of an attacker who does not know the password, the PE will be a random element in the negotiated group. Two examples are described here for completeness, but any method of deterministically mapping a secret string into an element in a selected group can be used -- for instance, the technique in [hash2ec] for ECC groups. If a different technique than the ones described here is used, the secret string SHOULD include the identities of the peers.
情報の交換を開始する前に、ピアは、選択されたドメインパラメータセットによって定義されたグループ内で、パスワード要素（PE）と呼ばれる秘密要素を導出する必要があります。パスワードを知らない攻撃者の観点から見ると、PEはネゴシエートされたグループのランダムな要素になります。完全を期すために2つの例をここで説明しますが、秘密の文字列を選択したグループの要素に決定論的にマッピングする方法を使用できます。たとえば、ECCグループの[hash2ec]の手法です。ここで説明されているものとは異なる手法を使用する場合、秘密の文字列にはピアのIDを含める必要があります（SHOULD）。
To fix the PE, both peers MUST have a common view of the password. If there is any password processing necessary (for example, to support internationalization), the processed password is then used as the shared credential. If either side wants to store a hashed version of the password (hashing the password with random data called a "salt"), it will be necessary to convey the salt to the other side prior to commencing the exchange, and the hashed password is then used as the shared credential.
PEを修正するには、両方のピアがパスワードの共通のビューを持っている必要があります。 （たとえば、国際化をサポートするために）パスワード処理が必要な場合は、処理されたパスワードが共有資格情報として使用されます。どちらかの側がハッシュされたバージョンのパスワード（「塩」と呼ばれるランダムなデータでパスワードをハッシュ化）を保存する場合、交換を開始する前にソルトをもう一方の側に伝達する必要があります。ハッシュされたパスワードは共有資格情報として使用されます。
Note: Only one party would be able to maintain a salted password, and this would require that the Dragonfly key exchange be used in a protocol that has strict roles for client (that always initiates) and server (that always responds). Due to the symmetric nature of Dragonfly, salting passwords does not prevent an impersonation attack after compromise of a database of salted passwords.
注：ソルト化されたパスワードを維持できるのは1つのパーティだけであり、クライアント（常に開始する）とサーバー（常に応答する）に厳密な役割を持つプロトコルでDragonfly鍵交換を使用する必要があります。 Dragonflyは対称的な性質を持つため、パスワードをソルトしても、ソルトされたパスワードのデータベースが侵害された後のなりすまし攻撃を防ぐことはできません。
The deterministic process to select the PE begins with choosing a secret seed and then performing a group-specific hunting-and-pecking technique -- one for FFC groups and another for ECC groups.
PEを選択する決定論的なプロセスは、シークレットシードを選択してから、グループ固有のハンティングアンドペッキング技術を実行することから始まります。1つはFFCグループ用、もう1つはECCグループ用です。
To thwart side-channel attacks that attempt to determine the number of iterations of the hunting-and-pecking loop used to find the PE for a given password, a security parameter, k, is used that ensures that at least k iterations are always performed. The probability that one requires more than n iterations of the hunting-and-pecking loop to find an ECC PE is roughly (q/2p)^n and to find an FFC PE is roughly (q/p)^n, both of which rapidly approach zero (0) as n increases. The security parameter, k, SHOULD be set sufficiently large such that the probability that finding the PE would take more than k iterations is sufficiently small (see Section 4).
特定のパスワードのPEを見つけるために使用されるハンティングアンドペッキングループの反復数を決定しようとするサイドチャネル攻撃を阻止するために、セキュリティパラメータkを使用して、少なくともk回の反復が常に実行されるようにします。 。 ECC PEを見つけるためにハンティングアンドペッキングループをn回以上繰り返す必要がある確率はおよそ（q / 2p）^ nであり、FFC PEを見つける確率はおよそ（q / p）^ nです。 nが増加するにつれて、急速にゼロ（0）に近づきます。セキュリティパラメータkは、PEを見つける確率がk回を超える可能性が十分に小さくなるように十分に大きく設定する必要があります（セクション4を参照）。
First, an 8-bit counter is set to one (1), and a secret base is computed using the negotiated one-way function with the identities of the two participants, Alice and Bob, the secret password, and the counter:
最初に、8ビットのカウンターが1に設定され、2つの参加者、アリスとボブのID、秘密のパスワード、およびカウンターを使用してネゴシエートされた一方向関数を使用して、秘密のベースが計算されます。
base = H(max(Alice,Bob) | min(Alice,Bob) | password | counter)
The identities are passed to the max() and min() functions to provide the necessary ordering of the inputs to H() while still allowing for a peer-to-peer exchange where both Alice and Bob each view themselves as the "initiator" of the exchange.
IDはmax()関数とmin()関数に渡され、H()への入力に必要な順序を提供しながら、アリスとボブの両方がそれぞれ自分自身を「開始者」と見なすピアツーピア交換を可能にします。交換の。
The base is then stretched using the technique from Section B.5.1 of [FIPS186-4]. The key derivation function, KDF, is used to produce a bitstream whose length is equal to the length of the prime from the group's domain parameter set plus the constant sixty-four (64) to derive a temporary value, and the temporary value is modularly reduced to produce a seed:
次に、[FIPS186-4]のセクションB.5.1の手法を使用してベースを伸ばします。キー導出関数KDFを使用して、グループのドメインパラメーターセットからの素数の長さに等しい長さのビットストリームと、定数値（64）を生成し、一時値を導出します。一時値はモジュール式です。シードを生成するために削減：
n = len(p) + 64
temp = KDF-n(base, "Dragonfly Hunting and Pecking")
temp = KDF-n（base、 "Dragonfly Hunting and Pecking"）
seed = (temp mod (p - 1)) + 1
The string bound to the derived temporary value is for illustrative purposes only. Implementations of the Dragonfly key exchange SHOULD use a usage-specific label with the KDF.
派生した一時的な値にバインドされた文字列は、説明のみを目的としています。 Dragonfly鍵交換の実装では、KDFで用途固有のラベルを使用する必要があります（SHOULD）。
Note: The base is stretched to 64 more bits than are needed so that the bias from the modular reduction is not so apparent.
注：基数は必要以上に64ビットに拡張されているため、モジュラー削減によるバイアスはそれほど明白ではありません。
The seed is then passed to the group-specific hunting-and-pecking technique.
次に、シードはグループ固有のハンティングアンドペッキング技術に渡されます。
If the protocol performing the Dragonfly exchange has the ability to exchange random nonces, those SHOULD be added to the computation of the base to ensure that each run of the protocol produces a different PE.
Dragonfly交換を実行するプロトコルがランダムなナンスを交換する機能を持っている場合、それらのプロトコルをベースの計算に追加して、プロトコルの実行ごとに異なるPEが生成されるようにする必要があります（SHOULD）。
The ECC-specific hunting-and-pecking technique entails looping until a valid point on the elliptic curve has been found. The seed is used as an x-coordinate with the equation of the curve to check whether x^3 + a*x + b is a quadratic residue modulo p. If it is not, then the counter is incremented, a new base and new seed are generated, and the hunting and pecking continues. If it is a quadratic residue modulo p, then the x-coordinate is assigned the value of seed and the current base is stored. When the hunting-and-pecking loop terminates, the x-coordinate is used with the equation of the curve to solve for a y-coordinate. An ambiguity exists since two values for the y-coordinate would be valid, and the low-order bit of the stored base is used to unambiguously determine the correct y-coordinate. The resulting (x,y) pair becomes the Password Element, PE.
ECC固有のハンティングアンドペッキング技術では、楕円曲線上の有効な点が見つかるまでループが必要です。シードは、曲線の方程式のx座標として使用され、x ^ 3 + a * x + bがpを法とする2次残差であるかどうかを確認します。そうでない場合は、カウンターがインクリメントされ、新しいベースと新しいシードが生成され、ハンティングとペッキングが続行されます。 pを法とする二次剰余の場合、x座標にはシードの値が割り当てられ、現在のベースが格納されます。ハンティングアンドペッキングループが終了すると、x座標と曲線の方程式が使用され、y座標が求められます。 y座標の2つの値が有効であるため、あいまいさが存在し、格納されているベースの下位ビットを使用して、正しいy座標を明確に決定します。結果の（x、y）ペアは、パスワード要素、PEになります。
Algorithmically, the process looks like this:
アルゴリズム的には、プロセスは次のようになります。
found = 0
counter = 1
n = len(p) + 64
do {
base = H(max(Alice,Bob) | min(Alice,Bob) | password | counter)
temp = KDF-n(base, "Dragonfly Hunting And Pecking")
seed = (temp mod (p - 1)) + 1
if ( (seed^3 + a*seed + b) is a quadratic residue mod p)
then
if ( found == 0 )
then
x = seed
save = base
found = 1
fi
fi
counter = counter + 1
} while ((found == 0) || (counter <= k))
y = sqrt(x^3 + ax + b)
if ( lsb(y) == lsb(save) )
then
PE = (x,y)
else
PE = (x,p-y)
fi
Figure 1: Fixing PE for ECC Groups
図1：ECCグループのPEの修正
Checking whether a value is a quadratic residue modulo a prime can leak information about that value in a side-channel attack. Therefore, it is RECOMMENDED that the technique used to determine if the value is a quadratic residue modulo p blind the value with a random number so that the blinded value can take on all numbers between 1 and p-1 with equal probability while not changing its quadratic residuosity. Determining the quadratic residue in a fashion that resists leakage of information is handled by flipping a coin and multiplying the blinded value by either a random quadratic residue or a random quadratic nonresidue and checking whether the multiplied value is a quadratic residue (qr) or a quadratic nonresidue (qnr) modulo p, respectively. The random residue and nonresidue can be calculated prior to hunting and pecking by calculating the Legendre symbol on random values until they are found:
値が素数を法とする二次剰余であるかどうかをチェックすると、サイドチャネル攻撃でその値に関する情報が漏洩する可能性があります。したがって、値がpを法とする2次剰余であるかどうかを決定するために使用される手法は、値を乱数でブラインドし、ブラインドされた値が1とp-1の間のすべての数値を等しい確率で変更せずに取ることができるようにすることをお勧めします二次残差。情報の漏出に抵抗する方法で二次残差を決定するには、コインを裏返し、ブラインド値にランダム二次残差またはランダム二次非残差のいずれかを乗算し、乗算された値が二次残差（qr）または二次それぞれpを法とする非剰余（qnr）。ランダムな残基と非残基は、それらが見つかるまでランダムな値でルジャンドル記号を計算することにより、ハンティングとペッキングの前に計算できます。
do {
qr = random() mod p
} while ( lgr(qr, p) != 1)
do {
qnr = random() mod p
} while ( lgr(qnr, p) != -1)
Algorithmically, the masking technique to find out whether or not a value is a quadratic residue looks like this:
アルゴリズム的に、値が2次残差であるかどうかを調べるマスキングテクニックは次のようになります。
is_quadratic_residue (val, p) {
r = (random() mod (p - 1)) + 1
num = (val * r * r) mod p
if ( lsb(r) == 1 )
num = (num * qr) mod p
if ( lgr(num, p) == 1)
then
return TRUE
fi
else
num = (num * qnr) mod p
if ( lgr(num, p) == -1)
then
return TRUE
fi
fi
return FALSE
}
The MODP-specific hunting-and-pecking technique entails finding a random element which, when used as a generator, will create a group with the same order as the group created by the generator from the domain parameter set. The secret generator is found by exponentiating the seed to the value ((p-1)/q), where p is the prime and q is the order from the domain parameter set. If that value is greater than one (1), it becomes the PE; otherwise, the counter is incremented, a new base and seed are generated, and the hunting and pecking continues.
MODP固有のハンティングアンドペッキングテクニックでは、ジェネレーターとして使用すると、ドメインパラメーターセットからジェネレーターによって作成されたグループと同じ順序でグループを作成するランダム要素を見つける必要があります。シークレットジェネレーターは、シードを値（（p-1）/ q）にべき乗することで見つかります。ここで、pは素数、qはドメインパラメーターセットからの次数です。その値が1より大きい場合は、PEになります。それ以外の場合は、カウンターがインクリメントされ、新しいベースとシードが生成され、ハンティングとペッキングが続行されます。
Algorithmically, the process looks like this:
アルゴリズム的には、プロセスは次のようになります。
found = 0
counter = 1
n = len(p) + 64
do {
base = H(max(Alice,Bob) | min(Alice,Bob) | password | counter)
temp = KDF-n(seed, "Dragonfly Hunting And Pecking")
seed = (temp mod (p - 1)) + 1
temp = seed ^ ((p-1)/q) mod p
if (temp > 1)
then
if (not found)
PE = temp
found = 1
fi
fi
counter = counter + 1
} while ((found == 0) || (counter <= k))
Figure 2: Fixing PE for MODP Groups
図2：MODPグループのPEの修正
In the Commit Exchange, both sides commit to a single guess of the password. The peers generate a scalar and an element, exchange them with each other, and process the other's scalar and element to generate a common and shared secret.
Commit Exchangeでは、両側がパスワードの単一の推測にコミットします。ピアは、スカラーと要素を生成し、それらを相互に交換し、他のスカラーと要素を処理して、共通の共有秘密を生成します。
First, each peer generates two random numbers, private and mask that are each greater than one (1) and less than the order from the selected domain parameter set:
最初に、各ピアは2つの乱数、privateとmaskを生成します。これらはそれぞれ1より大きく、選択したドメインパラメータセットの次数よりも小さいです。
1 < private < q
1 < mask < q
These two secrets and the Password Element are then used to construct the scalar and element:
次に、これらの2つのシークレットとパスワード要素を使用して、スカラーと要素を作成します。
scalar = (private + mask) modulo q
Element = inverse(scalar-op(mask, PE))
If the scalar is less than two (2), the private and mask MUST be thrown away and new values generated. Once a valid scalar and Element are generated, the mask is no longer needed and MUST be irretrievably destroyed.
スカラーが2未満の場合は、プライベートとマスクを破棄し、新しい値を生成する必要があります。有効なスカラーと要素が生成されると、マスクは不要になり、回復不能に破棄する必要があります。
The peers exchange their scalar and Element and check the peer's scalar and Element, deemed peer-scalar and Peer-Element. If the peer has sent an identical scalar and Element -- i.e., if scalar equals peer-scalar and Element equals Peer-Element -- it is sign of a reflection attack, and the exchange MUST be aborted. If the values differ, peer-scalar and Peer-Element must be validated. For the peer-scalar to be valid, it MUST be between 1 and q exclusive. Validation of the Peer-Element depends on the type of cryptosystem -- validation of an (x,y) pair as an ECC element is specified in Section 2.1, and validation of a number as an FFC element is specified in Section 2.2. If either the peer-scalar or Peer-Element fail validation, then the exchange MUST be terminated and authentication fails. If both the peer-scalar and Peer-Element are valid, they are used with the Password Element to derive a shared secret, ss:
ピアは、スカラーと要素を交換し、ピアのスカラーと要素をチェックします。これは、ピアスカラーとピア要素と見なされます。ピアが同じスカラーとエレメントを送信した場合（つまり、スカラーがピアスカラーに等しく、エレメントがピアエレメントに等しい場合）、これはリフレクション攻撃の兆候であり、交換を中止する必要があります。値が異なる場合は、peer-scalarおよびPeer-Elementを検証する必要があります。ピアスカラーが有効であるためには、1とqの間でなければなりません。ピアエレメントの検証は、暗号システムのタイプによって異なります。ECCエレメントとしての（x、y）ペアの検証はセクション2.1で指定され、FFCエレメントとしての数値の検証はセクション2.2で指定されます。ピアスカラーまたはピア要素のいずれかが検証に失敗した場合、交換を終了する必要があり、認証は失敗します。 peer-scalarとPeer-Elementの両方が有効な場合、それらはPassword Elementと共に使用され、共有秘密鍵ssを導出します。
ss = F(scalar-op(private,
element-op(peer-Element,
scalar-op(peer-scalar, PE))))
To enforce key separation and cryptographic hygiene, the shared secret is stretched into two subkeys -- a key confirmation key, kck, and a master key, mk. Each of the subkeys SHOULD be at least the length of the prime used in the selected group.
鍵の分離と暗号化の衛生を強化するために、共有シークレットは2つのサブ鍵（鍵確認鍵（kck）とマスター鍵（mk））に拡張されます。各サブキーは、少なくとも選択されたグループで使用される素数の長さである必要があります（SHOULD）。
kck | mk = KDF-n(ss, "Dragonfly Key Derivation")
kck | mk = KDF-n（ss、 "Dragonfly Key Derivation"）
where n = len(p)*2.
ここで、n = len（p）* 2です。
In the Confirm Exchange, both sides confirm that they derived the same secret, and therefore, are in possession of the same password.
確認交換では、双方が同じ秘密を導出したことを確認するため、同じパスワードを所有しています。
The Commit Exchange consists of an exchange of data that is the output of the random function, H(), the key confirmation key, and the two scalars and two elements exchanged in the Commit Exchange. The order of the scalars and elements are: scalars before elements, and sender's value before recipient's value. So from each peer's perspective, it would generate:
コミット交換は、ランダム関数H()の出力であるデータの交換、キー確認キー、およびコミット交換で交換される2つのスカラーと2つの要素で構成されます。スカラーと要素の順序は、要素の前のスカラー、受信者の値の前の送信者の値です。したがって、各ピアの観点からは、次のものが生成されます。
confirm = H(kck | scalar | peer-scalar |
Element | Peer-Element | <sender-id>)
Where <sender-id> is the identity of the sender of the confirm message. This identity SHALL be that contributed by the sender of the confirm message in generation of the base in Section 3.2.
ここで、<sender-id>は確認メッセージの送信者のIDです。このアイデンティティは、セクション3.2のベースの生成で確認メッセージの送信者によって提供されたものである必要があります。
The two peers exchange these confirmations and verify the correctness of the other peer's confirmation that they receive. If the other peer's confirmation is valid, authentication succeeds; if the other peer's confirmation is not valid, authentication fails.
2つのピアはこれらの確認を交換し、受信した他のピアの確認が正しいことを確認します。他のピアの確認が有効な場合、認証は成功します。他のピアの確認が有効でない場合、認証は失敗します。
If authentication fails, all ephemeral state created as part of the particular run of the Dragonfly exchange MUST be irretrievably destroyed. If authentication does not fail, mk can be exported as an authenticated and secret key that can be used by another protocol, for instance IPsec, to protect other data.
認証が失敗した場合、Dragonfly交換の特定の実行の一部として作成されたすべての一時的な状態は、回復不能に破棄する必要があります。認証が失敗しない場合は、mkを認証済みの秘密鍵としてエクスポートし、IPsecなどの別のプロトコルで使用して、他のデータを保護できます。
The Dragonfly exchange requires both participants to have an identical representation of the password. Salting of the password merely generates a new credential -- the salted password -- that must be identically represented on both sides. If an adversary is able to gain access to the database of salted passwords, she would be able to impersonate one side to the other, even if she was unable to determine the underlying, unsalted password.
Dragonfly交換では、両方の参加者が同一のパスワード表現を持つ必要があります。パスワードのソルトは、新しいクレデンシャル（ソルトされたパスワード）を生成するだけです。これは、両側で同じように表現する必要があります。攻撃者がソルトパスワードのデータベースにアクセスできる場合、攻撃者は基礎となる無塩のパスワードを特定できなかったとしても、一方を他方に偽装することができます。
Resistance to dictionary attack means that an adversary must launch an active attack to make a single guess at the password. If the size of the dictionary from which the password was extracted was d, and each password in the dictionary has an equal probability of being chosen, then the probability of success after a single guess is 1/d. After x guesses, and removal of failed guesses from the pool of possible passwords, the probability becomes 1/(d-x). As x grows, so does the probability of success. Therefore, it is possible for an adversary to determine the password through repeated brute-force, active, guessing attacks. Users of the Dragonfly key exchange SHOULD ensure that the size of the pool from which the password was drawn, d, is sufficiently large to make this attack preventable. Implementations of Dragonfly SHOULD support countermeasures to deal with this attack -- for instance, by refusing authentication attempts for a certain amount of time, after the number of failed authentication attempts reaches a certain threshold. No such threshold or amount of time is recommended in this memo.
辞書攻撃への耐性とは、攻撃者がパスワードを1回推測するためにアクティブな攻撃を開始する必要があることを意味します。パスワードが抽出されたディクショナリのサイズがdで、ディクショナリ内の各パスワードが選択される確率が等しい場合、1回の推測で成功する確率は1 / dです。 xが推測し、失敗した推測を可能なパスワードのプールから削除すると、確率は1 /（d-x）になります。 xが大きくなると、成功の確率も大きくなります。したがって、攻撃者がブルートフォース攻撃、推測攻撃を繰り返し行うことでパスワードを決定する可能性があります。 Dragonfly鍵交換のユーザーは、パスワードの取得元のプールのサイズdが、この攻撃を防止できるように十分に大きいことを確認する必要があります（SHOULD）。 Dragonflyの実装は、この攻撃に対処するための対策をサポートする必要があります（SHOULD）。たとえば、失敗した認証試行の回数が特定のしきい値に達した後、特定の時間、認証試行を拒否することによって。このメモでは、そのようなしきい値や時間量は推奨されていません。
Due to the problems with using groups that contain a small subgroup, it is RECOMMENDED that implementations of Dragonfly not allow for the specification of a group's complete domain parameter to be sent in-line, but instead use a common repository and pass an identifier to a domain parameter set whose strength has been rigorously proven and that does not have small subgroups. If a group's complete domain parameter set is passed in-line, it SHOULD NOT be used with Dragonfly unless it directly matches a known good group.
小さなサブグループを含むグループの使用に問題があるため、Dragonflyの実装では、グループの完全なドメインパラメータの指定をインラインで送信できず、代わりに共通リポジトリを使用して識別子をに渡すことをお勧めします強度が厳密に証明されており、小さなサブグループを持たないドメインパラメータセット。グループの完全なドメインパラメータセットがインラインで渡される場合、既知の適切なグループと直接一致しない限り、Dragonflyで使用しないでください。
It is RECOMMENDED that an implementation set the security parameter, k, to a value of at least forty (40) which will put the probability that more than forty iterations are needed in the order of one in one trillion (1:1,000,000,000,000).
実装では、セキュリティパラメータkを少なくとも40の値に設定することをお勧めします。これにより、40を超える反復が1兆分の1（1：1,000,000,000,000）のオーダーで必要になる確率が高くなります。
The technique used to obtain the Password Element in Section 3.2.1 addresses side-channel attacks in a manner deemed controversial by some reviewers in the CFRG. An alternate method, such as the one defined in [hash2ec], can be used to alleviate concerns.
セクション3.2.1でパスワード要素を取得するために使用される手法は、CFRGの一部のレビュアーによって論争の的と見なされる方法でサイドチャネル攻撃に対処します。 [hash2ec]で定義されているような別の方法を使用して、問題を軽減できます。
This key exchange protocol has received cryptanalysis in [clarkehao]. [lanskro] provides a security proof of Dragonfly in the random oracle model when both identities are included in the data sent in the Confirm Exchange (see Section 3.4).
この鍵交換プロトコルは[clarkehao]で解読されました。 [lanskro]は、確認交換（セクション3.4を参照）で送信されるデータに両方のIDが含まれている場合、ランダムオラクルモデルでDragonflyのセキュリティ証明を提供します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[clarkehao] Clarke, D. and F. Hao, "Cryptanalysis of the Dragonfly Key Exchange Protocol", IET Information Security, Volume 8, Issue 6, DOI 10.1049/iet-ifs.2013.0081, November 2014.
[clarkehao] Clarke、D。およびF. Hao、「Dragonfly Key Exchange Protocolの暗号解析」、IET情報セキュリティ、第8巻、第6号、DOI 10.1049 / iet-ifs.2013.0081、2014年11月。
[FIPS186-4] NIST, "Digital Signature Standard (DSS)", Federal Information Processing Standard (FIPS) 186-4, DOI 10.6028/NIST.FIPS.186-4, July 2013.
[FIPS186-4] NIST、「デジタル署名標準（DSS）」、連邦情報処理標準（FIPS）186-4、DOI 10.6028 / NIST.FIPS.186-4、2013年7月。
[hash2ec] Brier, E., Coron, J-S., Icart, T., Madore, D., Randriam, H., and M. Tibouchi, "Efficient Indifferentiable Hashing into Ordinary Elliptic Curves", Cryptology ePrint Archive Report 2009/340, 2009.
[hash2ec]ブライア、E。、コロン、JS、イカート、T。、マドール、D。、ランドリアム、H、およびM.ティボウチ、「通常の楕円曲線への効率的な微分不能ハッシュ」、暗号学ePrintアーカイブレポート2009/340 、2009。
[lanskro] Lancrenon, J. and M. Skrobot, "On the Provable Security of the Dragonfly Protocol", Proceedings of 18th International Information Security Conference (ISC 2015), pp 244-261, DOI 10.1007/978-3-319-23318-5_14, September 2015.
[lanskro] Lancrenon、J。およびM. Skrobot、「トンボプロトコルの証明可能なセキュリティについて」、第18回国際情報セキュリティ会議の議事録（ISC 2015）、pp 244-261、DOI 10.1007 / 978-3-319-23318 -5_14、2015年9月。
[RANDOR] Bellare, M. and P. Rogaway, "Random Oracles are Practical: A Paradigm for Designing Efficient Protocols", Proceedings of the 1st ACM Conference on Computer and Communication Security, ACM Press, DOI 10.1145/168588.168596, 1993.
[RANDOR] Bellare、M。、およびP. Rogaway、「ランダムなオラクルは実用的：効率的なプロトコルを設計するためのパラダイム」、第1回コンピュータおよび通信セキュリティに関するACM会議の議事録、ACM Press、DOI 10.1145 / 168588.168596、1993。
[RFC5433] Clancy, T. and H. Tschofenig, "Extensible Authentication Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method", RFC 5433, DOI 10.17487/RFC5433, February 2009, <http://www.rfc-editor.org/info/rfc5433>.
[RFC5433] Clancy、T。およびH. Tschofenig、「Extensible Authentication Protocol-Generalized Pre-Shared Key（EAP-GPSK）Method」、RFC 5433、DOI 10.17487 / RFC5433、2009年2月、<http：//www.rfc- editor.org/info/rfc5433>。
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic Curve Cryptography Algorithms", RFC 6090, DOI 10.17487/RFC6090, February 2011, <http://www.rfc-editor.org/info/rfc6090>.
[RFC6090] McGrew、D.、Igoe、K。、およびM. Salter、「Fundamental Elliptic Curve Cryptography Algorithms」、RFC 6090、DOI 10.17487 / RFC6090、2011年2月、<http://www.rfc-editor.org/ info / rfc6090>。
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, <http://www.rfc-editor.org/info/rfc7296>.
[RFC7296] Kaufman、C.、Hoffman、P.、Nir、Y.、Eronen、P。、およびT. Kivinen、「Internet Key Exchange Protocol Version 2（IKEv2）」、STD 79、RFC 7296、DOI 10.17487 / RFC7296 、2014年10月、<http://www.rfc-editor.org/info/rfc7296>。
[SP800-108] Chen, L., "Recommendation for Key Derivation Using Pseudorandom Functions", NIST Special Publication 800-108, October 2009.
[SP800-108]チェンL.、「擬似ランダム関数を使用した鍵導出の推奨」、NIST特別刊行物800-108、2009年10月。
[SP800-56A] Barker, E., Johnson, D., and M. Smid, "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography (Revised)", NIST Special Publication 800-56A, March 2007.
[SP800-56A] Barker、E.、Johnson、D。、およびM. Smid、「離散対数暗号を使用したペアワイズキー確立スキームの推奨（改訂）」、NIST特別刊行物800-56A、2007年3月。
Acknowledgements
謝辞
The author would like to thank Kevin Igoe and David McGrew, chairmen of the Crypto Forum Research Group (CFRG) for agreeing to accept this memo as a CFRG work item. Additional thanks go to Scott Fluhrer and Hideyuki Suzuki for discovering attacks against earlier versions of this key exchange and suggesting fixes to address them. Lily Chen provided helpful discussions on hashing into an elliptic curve. Rich Davis suggested the validation steps used on received elements to prevent a small subgroup attack. Dylan Clarke and Feng Hao discovered a dictionary attack against Dragonfly if those checks are not made and a group with a small subgroup is used. And finally, a very heartfelt thanks to Jean Lancrenon and Marjan Skrobot for developing a proof of the security of Dragonfly.
著者は、このメモをCFRG作業項目として受け入れることに同意してくれた、Crypto Forum Research Group（CFRG）の会長であるKevin IgoeとDavid McGrewに感謝します。この鍵交換の以前のバージョンに対する攻撃を発見し、それらに対処するための修正を提案してくれたScott FluhrerとHideyuki Suzukiにさらに感謝します。 Lily Chenは、楕円曲線へのハッシュに関する有益な議論を行いました。 Rich Davisは、小さなサブグループ攻撃を防ぐために、受信した要素で使用する検証手順を提案しました。 Dylan ClarkeとFeng Haoは、これらのチェックが行われず、小さなサブグループを持つグループが使用されている場合、Dragonflyに対する辞書攻撃を発見しました。そして最後に、Dragonflyのセキュリティの証明を開発してくれたJean LancrenonとMarjan Skrobotに心から感謝します。
The blinding scheme to prevent side-channel attacks when determining whether a value is a quadratic residue modulo a prime was suggested by Scott Fluhrer. Kevin Igoe suggested addition of the security parameter k to hide the amount of time taken hunting and pecking for the password element.
値が素数を法とする二次剰余であるかどうかを決定するときにサイドチャネル攻撃を防ぐためのブラインドスキームは、Scott Fluhrerによって提案されました。 Kevin Igoeさんは、セキュリティ要素kを追加して、パスワード要素のハンティングとペッキングにかかる時間を隠すことを提案しました。
Author's Address
著者のアドレス
Dan Harkins (editor) Aruba Networks 1322 Crossman Avenue Sunnyvale, CA 94089-1113 United States
Dan Harkins（編集者）Aruba Networks 1322 Crossman Avenue Sunnyvale、CA 94089-1113アメリカ合衆国
Email: dharkins@arubanetworks.com