[要約] RFC 8236は、J-PAKE（Jugglingによるパスワード認証キー交換）に関する規格であり、パスワードを使用したセキュアな鍵交換プロトコルを提供することを目的としています。
Independent Submission F. Hao, Ed.
Request for Comments: 8236 Newcastle University (UK)
Category: Informational September 2017
ISSN: 2070-1721
J-PAKE: Password-Authenticated Key Exchange by Juggling
J-PAKE：ジャグリングによるパスワード認証の鍵交換
Abstract
概要
This document specifies a Password-Authenticated Key Exchange by Juggling (J-PAKE) protocol. This protocol allows the establishment of a secure end-to-end communication channel between two remote parties over an insecure network solely based on a shared password, without requiring a Public Key Infrastructure (PKI) or any trusted third party.
このドキュメントは、Juggling（J-PAKE）プロトコルによるパスワード認証鍵交換を規定しています。このプロトコルにより、公開パスワードインフラストラクチャ（PKI）や信頼できるサードパーティを必要とせずに、共有パスワードのみに基づいて、安全でないネットワークを介して2つのリモートパーティ間に安全なエンドツーエンド通信チャネルを確立できます。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 7841のセクション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/rfc8236.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8236で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 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 . . . . . . . . . . . . . . . . . . 3
1.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 3
2. J-PAKE over Finite Field . . . . . . . . . . . . . . . . . . 4
2.1. Protocol Setup . . . . . . . . . . . . . . . . . . . . . 4
2.2. Two-Round Key Exchange . . . . . . . . . . . . . . . . . 5
2.3. Computational Cost . . . . . . . . . . . . . . . . . . . 6
3. J-PAKE over Elliptic Curve . . . . . . . . . . . . . . . . . 7
3.1. Protocol Setup . . . . . . . . . . . . . . . . . . . . . 7
3.2. Two-Round Key Exchange . . . . . . . . . . . . . . . . . 7
3.3. Computational Cost . . . . . . . . . . . . . . . . . . . 8
4. Three-Pass Variant . . . . . . . . . . . . . . . . . . . . . 8
5. Key Confirmation . . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . 14
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
Password-Authenticated Key Exchange (PAKE) is a technique that aims to establish secure communication between two remote parties solely based on their shared password, without relying on a Public Key Infrastructure or any trusted third party [BM92]. The first PAKE protocol, called Encrypted Key Exchange (EKE), was proposed by Steven Bellovin and Michael Merrit in 1992 [BM92]. Other well-known PAKE protocols include Simple Password Exponential Key Exchange (SPEKE) by David Jablon in 1996 [Jab96] and Secure Remote Password (SRP) by Tom Wu in 1998 [Wu98]. SRP has been revised several times to address reported security and efficiency issues. In particular, the version 6 of SRP, commonly known as SRP-6, is specified in [RFC5054].
パスワード認証鍵交換（PAKE）は、公開鍵インフラストラクチャや信頼できるサードパーティに依存せずに、共有パスワードだけに基づいて2つのリモートパーティー間で安全な通信を確立することを目的とした手法です[BM92]。 Encrypted Key Exchange（EKE）と呼ばれる最初のPAKEプロトコルは、1992年にSteven BellovinとMichael Merritによって提案されました[BM92]。他のよく知られたPAKEプロトコルには、1996年のDavid JablonによるSimple Password Exponential Key Exchange（SPEKE）[Jab96]と1998年のTom WuによるSecure Remote Password（SRP）[Wu98]があります。報告されたセキュリティと効率の問題に対処するために、SRPは何度か改訂されました。特に、一般的にSRP-6として知られているバージョン6のSRPは、[RFC5054]で指定されています。
This document specifies a PAKE protocol called Password-Authenticated Key Exchange by Juggling (J-PAKE), which was designed by Feng Hao and Peter Ryan in 2008 [HR08]. There are a few factors that may be considered in favor of J-PAKE. First, J-PAKE has security proofs, while equivalent proofs are lacking in EKE, SPEKE and SRP-6. Second, J-PAKE follows a completely different design approach from all other PAKE protocols, and is built upon a well-established Zero Knowledge Proof (ZKP) primitive: Schnorr NIZK proof [RFC8235]. Third, J-PAKE adopts novel engineering techniques to optimize the use of ZKP so that overall the protocol is sufficiently efficient for practical use. Fourth, J-PAKE is designed to work generically in both the finite field and elliptic curve settings (i.e., DSA and ECDSA-like groups, respectively). Unlike SPEKE, it does not require any extra primitive to hash passwords onto a designated elliptic curve. Unlike SPAKE2 [AP05] and SESPAKE [SOAA15], it does not require a trusted setup (i.e., the so-called common reference model) to define a pair of generators whose discrete logarithm must be unknown. Finally, J-PAKE has been used in real-world applications at a relatively large scale, e.g., Firefox sync [MOZILLA], Pale moon sync [PALEMOON], and Google Nest products [ABM15]. It has been included into widely distributed open source libraries such as OpenSSL [BOINC], Network Security Services (NSS) [MOZILLA_NSS], and the Bouncy Castle [BOUNCY]. Since 2015, J-PAKE has been included in Thread [THREAD] as a standard key agreement mechanism for IoT (Internet of Things) applications, and also included in ISO/IEC 11770-4:2017 [ISO.11770-4].
このドキュメントは、2008年にFeng HaoとPeter Ryanによって設計されたJugglingによるパスワード認証キー交換（J-PAKE）と呼ばれるPAKEプロトコルを指定します[HR08]。 J-PAKEを支持するいくつかの要因があります。まず、J-PAKEにはセキュリティの証明がありますが、EKE、SPEKE、SRP-6には同等の証明がありません。第二に、J-PAKEは他のすべてのPAKEプロトコルとはまったく異なる設計アプローチに従い、定評のあるゼロ知識証明（ZKP）プリミティブであるSchnorr NIZK証明[RFC8235]に基づいて構築されています。第3に、J-PAKEはZKPの使用を最適化するために新しいエンジニアリング手法を採用しているため、プロトコル全体が実用に十分なほど効率的です。第4に、J-PAKEは、有限フィールドと楕円曲線の両方の設定（つまり、それぞれDSAとECDSAのようなグループ）で一般的に機能するように設計されています。 SPEKEとは異なり、指定された楕円曲線にパスワードをハッシュするための追加のプリミティブは必要ありません。 SPAKE2 [AP05]やSESPAKE [SOAA15]とは異なり、離散対数が不明でなければならない1組のジェネレーターを定義するために、信頼できる設定（いわゆる共通参照モデル）は必要ありません。最後に、J-PAKEは、Firefox Sync [MOZILLA]、Pale moon Sync [PALEMOON]、Google Nest製品[ABM15]など、比較的大規模な実際のアプリケーションで使用されています。 OpenSSL [BOINC]、ネットワークセキュリティサービス（NSS）[MOZILLA_NSS]、Bouncy Castle [BOUNCY]などの広く分散しているオープンソースライブラリに含まれています。 2015年以降、J-PAKEはIoT（モノのインターネット）アプリケーションの標準の鍵合意メカニズムとしてスレッド[スレッド]に含まれ、ISO / IEC 11770-4：2017 [ISO.11770-4]にも含まれています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
The following notation is used in this document:
このドキュメントでは、次の表記法を使用しています。
o Alice: the assumed identity of the prover in the protocol
o アリス：プロトコルにおける証明者の想定されるアイデンティティ
o Bob: the assumed identity of the verifier in the protocol
o Bob：プロトコルでの検証者の想定されるアイデンティティ
o s: a low-entropy secret shared between Alice and Bob
o s：アリスとボブが共有する低エントロピーの秘密
o a | b: a divides b
o a | b：aはbを分割します
o a || b: concatenation of a and b
o || b：aとbの連結
o [a, b]: the interval of integers between and including a and b
o [a、b]：aとbの間の整数の間隔
o H: a secure cryptographic hash function
o H：安全な暗号化ハッシュ関数
o p: a large prime
o p：大きな素数
o q: a large prime divisor of p-1, i.e., q | p-1
o q：p-1の大きな素数、つまりq | p-1
o Zp*: a multiplicative group of integers modulo p o Gq: a subgroup of Zp* with prime order q
o Zp *：pを法とする整数の乗法グループo Gq：素数次数qのZp *のサブグループ
o g: a generator of Gq
o g：Gqのジェネレーター
o g^d: g raised to the power of d
o g ^ d：gのd乗
o a mod b: a modulo b
o a mod b：a modulo b
o Fp: a finite field of p elements, where p is a prime
o Fp：p要素の有限体、pは素数
o E(Fp): an elliptic curve defined over Fp
o E（Fp）：Fpで定義された楕円曲線
o G: a generator of the subgroup over E(Fp) with prime order n
o G：素数次数がnのE（Fp）上のサブグループのジェネレーター
o n: the order of G
o n：Gの次数
o h: the cofactor of the subgroup generated by G, which is equal to the order of the elliptic curve divided by n
o h：Gによって生成されたサブグループの補因子。これは、楕円曲線の次数をnで割ったものに等しい
o P x [b]: multiplication of a point P with a scalar b over E(Fp)
o P x [b]：E（Fp）上の点Pとスカラーbの乗算
o KDF(a): Key Derivation Function with input a
o KDF（a）：入力aを持つ鍵導出関数
o MAC(MacKey, MacData): MAC function with MacKey as the key and MacData as the input data
o MAC（MacKey、MacData）：MacKeyをキー、MacDataを入力データとするMAC関数
When implemented over a finite field, J-PAKE may use the same group parameters as DSA [FIPS186-4]. Let p and q be two large primes such that q | p-1. Let Gq denote a subgroup of Zp* with prime order q. Let g be a generator for Gq. Any non-identity element in Gq can be a generator. The two communicating parties, Alice and Bob, both agree on (p, q, g), which can be hard-wired in the software code. They can also use the method in NIST FIPS 186-4, Appendix A [FIPS186-4] to generate (p, q, g). Here, DSA group parameters are used only as an example. Other multiplicative groups suitable for cryptography can also be used for the implementation, e.g., groups defined in [RFC4419]. A group setting that provides 128-bit security or above is recommended. The security proof of J-PAKE depends on the Decisional Diffie-Hellman (DDH) problem being intractable in the considered group.
有限フィールドで実装される場合、J-PAKEはDSA [FIPS186-4]と同じグループパラメータを使用する場合があります。 pとqを次のような2つの大きな素数とする| p-1。 Gqが素数次数qのZp *のサブグループを表すとします。 gをGqのジェネレーターとします。 Gqの非アイデンティティ要素はジェネレーターになることができます。 2つの通信相手、アリスとボブはどちらも（p、q、g）に同意します。これは、ソフトウェアコードにハードワイヤードできます。また、NIST FIPS 186-4、付録A [FIPS186-4]のメソッドを使用して（p、q、g）を生成することもできます。ここでは、DSAグループパラメータは例としてのみ使用されています。 [RFC4419]で定義されているグループなど、暗号化に適した他の乗法グループも実装に使用できます。 128ビット以上のセキュリティを提供するグループ設定をお勧めします。 J-PAKEのセキュリティ証明は、検討対象のグループでは扱いにくいDecisional Diffie-Hellman（DDH）問題に依存しています。
Let s be a secret value derived from a low-entropy password shared between Alice and Bob. The value of s is REQUIRED to fall within the range of [1, q-1]. (Note that s must not be 0 for any non-empty secret.) This range is defined as a necessary condition in [HR08] for proving the "on-line dictionary attack resistance", since s, s+q, s+2q, ..., are all considered equivalent values as far as the protocol specification is concerned. In a practical implementation, one may obtain s by taking a cryptographic hash of the password and wrapping the result with respect to modulo q. Alternatively, one may simply treat the password as an octet string and convert the string to an integer modulo q by following the method defined in Section 2.3.8 of [SEC1]. In either case, one MUST ensure s is not equal to 0 modulo q.
sを、AliceとBobの間で共有される低エントロピーパスワードから派生した秘密値とする。 sの値は、[1、q-1]の範囲内にあることが必要です。 （sが空でないシークレットの場合、sは0であってはならないことに注意してください。）この範囲は、[HR08]で「オンライン辞書攻撃耐性」を証明するための必要条件として定義されています。s、s + q、s + 2q 、...、プロトコル仕様に関する限り、すべて同等の値と見なされます。実際の実装では、パスワードの暗号ハッシュを取得し、qを法として結果をラップすることにより、sを取得できます。あるいは、パスワードをオクテット文字列として扱い、[SEC1]のセクション2.3.8で定義されている方法に従って、文字列をqを法とする整数に変換することもできます。どちらの場合でも、sが0を法とするqに等しくないことを保証しなければなりません（MUST）。
Round 1: Alice selects an ephemeral private key x1 uniformly at random from [0, q-1] and another ephemeral private key x2 uniformly at random from [1, q-1]. Similarly, Bob selects an ephemeral private key x3 uniformly at random from [0, q-1] and another ephemeral private key x4 uniformly at random from [1, q-1].
ラウンド1：アリスは[0、q-1]からランダムに一律にエフェメラル秘密鍵x1を選択し、[1、q-1]からランダムに一律に別のエフェメラル秘密鍵x2を選択します。同様に、ボブは[0、q-1]からランダムに一律にエフェメラル秘密鍵x3を選択し、[1、q-1]からランダムに一律に別のエフェメラル秘密鍵x4を選択します。
o Alice -> Bob: g1 = g^x1 mod p, g2 = g^x2 mod p and ZKPs for x1 and x2
o アリス->ボブ：g1 = g ^ x1 mod p、g2 = g ^ x2 mod p、およびx1とx2のZKP
o Bob -> Alice: g3 = g^x3 mod p, g4 = g^x4 mod p and ZKPs for x3 and x4
o ボブ->アリス：g3 = g ^ x3 mod p、g4 = g ^ x4 mod pおよびx3およびx4のZKP
In this round, the sender must send zero knowledge proofs to demonstrate the knowledge of the ephemeral private keys. A suitable technique is to use the Schnorr NIZK proof [RFC8235]. As an example, suppose one wishes to prove the knowledge of the exponent for D = g^d mod p. The generated Schnorr NIZK proof will contain: {UserID, V = g^v mod p, r = v - d * c mod q}, where UserID is the unique identifier for the prover, v is a number chosen uniformly at random from [0, q-1] and c = H(g || V || D || UserID). The "uniqueness" of UserID is defined from the user's perspective -- for example, if Alice communicates with several parties, she shall associate a unique identity with each party. Upon receiving a Schnorr NIZK proof, Alice shall check the prover's UserID is a valid identity and is different from her own identity. During the key exchange process using J-PAKE, each party shall ensure that the other party has been consistently using the same identity throughout the protocol execution. Details about the Schnorr NIZK proof, including the generation and the verification procedures, can be found in [RFC8235].
このラウンドでは、一時的な秘密鍵の知識を実証するために、送信者は知識証明を送信する必要があります。適切な手法は、Schnorr NIZKプルーフ[RFC8235]を使用することです。例として、D = g ^ d mod pの指数の知識を証明したいとします。生成されたSchnorr NIZK証明には、{UserID、V = g ^ v mod p、r = v-d * c mod q}が含まれます。ここで、UserIDは証明者の一意の識別子、vは[ 0、q-1]およびc = H（g || V || D || UserID）。 UserIDの「一意性」は、ユーザーの観点から定義されます。たとえば、アリスが複数のパーティと通信する場合、アリスは各パーティに一意のIDを関連付けます。 Schnorr NIZKの証明を受け取ったら、アリスは証明者のUserIDが有効なIDであり、自分のIDとは異なることを確認します。 J-PAKEを使用した鍵交換プロセス中、各当事者は、プロトコルの実行全体を通じて、他の当事者が一貫して同じIDを使用していることを確認する必要があります。生成や検証の手順を含む、Schnorr NIZK証明の詳細は、[RFC8235]にあります。
When this round finishes, Alice verifies the received ZKPs as specified in [RFC8235] and also checks that g4 != 1 mod p. Similarly, Bob verifies the received ZKPs and also checks that g2 != 1 mod p. If any of these checks fails, this session should be aborted.
このラウンドが終了すると、アリスは[RFC8235]で指定されているように受信したZKPを確認し、g4！= 1 mod pであることも確認します。同様に、ボブは受信したZKPを検証し、g2！= 1 mod pであることも確認します。これらのチェックのいずれかが失敗した場合、このセッションは中止されます。
Round 2:
ラウンド2：
o Alice -> Bob: A = (g1*g3*g4)^(x2*s) mod p and a ZKP for x2*s
o アリス->ボブ：A =（g1 * g3 * g4）^（x2 * s）mod pとx2 * sのZKP
o Bob -> Alice: B = (g1*g2*g3)^(x4*s) mod p and a ZKP for x4*s
o ボブ->アリス：B =（g1 * g2 * g3）^（x4 * s）mod pとx4 * sのZKP
In this round, the Schnorr NIZK proof is computed in the same way as in the previous round except that the generator is different. For Alice, the generator used is (g1*g3*g4) instead of g; for Bob, the generator is (g1*g2*g3) instead of g. Since any non-identity element in Gq can be used as a generator, Alice and Bob just need to ensure g1*g3*g4 != 1 mod p and g1*g2*g3 != 1 mod p. With overwhelming probability, these inequalities are statistically guaranteed even when the user is communicating with an adversary (i.e., in an active attack). Nonetheless, for absolute guarantee, the receiving party shall explicitly check if these inequalities hold, and abort the session in case such a check fails.
このラウンドでは、シュノーラーNIZK証明は、ジェネレーターが異なることを除いて、前のラウンドと同じ方法で計算されます。 Aliceの場合、使用されるジェネレーターはgではなく（g1 * g3 * g4）です。ボブの場合、ジェネレータはgではなく（g1 * g2 * g3）です。 Gqの非アイデンティティ要素はジェネレータとして使用できるため、アリスとボブはg1 * g3 * g4！= 1 mod pとg1 * g2 * g3！= 1 mod pを確認するだけで済みます。圧倒的な確率で、これらの不等式は、ユーザーが敵と通信しているとき（つまり、アクティブな攻撃中）であっても統計的に保証されます。それにもかかわらず、絶対的な保証のために、受信側はこれらの不等式が成立するかどうかを明示的にチェックし、そのようなチェックが失敗した場合はセッションを中止するものとします。
When the second round finishes, Alice and Bob verify the received ZKPs. If the verification fails, the session is aborted. Otherwise, the two parties compute the common key material as follows:
2番目のラウンドが終了すると、アリスとボブは受信したZKPを確認します。検証が失敗した場合、セッションは中止されます。それ以外の場合、両者は次のように共通の鍵素材を計算します。
o Alice computes Ka = (B/g4^(x2*s))^x2 mod p
o アリスはKa =（B / g4 ^（x2 * s））^ x2 mod pを計算します
o Bob computes Kb = (A/g2^(x4*s))^x4 mod p
o BobはKb =（A / g2 ^（x4 * s））^ x4 mod pを計算します
Here, Ka = Kb = g^((x1+x3)*x2*x4*s) mod p. Let K denote the same key material held by both parties. Using K as input, Alice and Bob then apply a Key Derivation Function (KDF) to derive a common session key k. If the subsequent secure communication uses a symmetric cipher in an authenticated mode (say AES-GCM), then one key is sufficient, i.e., k = KDF(K). Otherwise, the session key should comprise an encryption key (for confidentiality) and a MAC key (for integrity), i.e., k = k_enc || k_mac, where k_enc = KDF(K || "JPAKE_ENC") and k_mac = KDF(K || "JPAKE_MAC"). The exact choice of the KDF is left to specific applications to define.
ここで、Ka = Kb = g ^（（x1 + x3）* x2 * x4 * s）mod p。 Kが両方の当事者が保持する同じ鍵の資料を示すものとします。 Kを入力として使用して、アリスとボブはキー導出関数（KDF）を適用し、共通のセッションキーkを導出します。後続の安全な通信で認証モード（AES-GCMなど）で対称暗号を使用する場合、1つの鍵で十分です（つまり、k = KDF（K））。それ以外の場合、セッションキーは暗号化キー（機密性のため）とMACキー（整合性のため）を含む必要があります。つまり、k = k_enc ||です。 k_mac、ここでk_enc = KDF（K || "JPAKE_ENC"）およびk_mac = KDF（K || "JPAKE_MAC"）。 KDFの正確な選択は、定義する特定のアプリケーションに任されています。
The computational cost is estimated based on counting the number of modular exponentiations since they are the predominant cost factors. Note that it takes one exponentiation to generate a Schnorr NIZK proof and two to verify it [RFC8235]. For Alice, she needs to perform 8 exponentiations in the first round, 4 in the second round, and 2 in the final computation of the session key. Hence, that is 14 modular exponentiations in total. Based on the symmetry, the computational cost for Bob is exactly the same.
計算コストは、主なコスト要因であるため、べき乗の数を数えることに基づいて推定されます。 Schnorr NIZK証明を生成するには1つのべき乗が必要であり、それを検証するには2つのべき乗が必要であることに注意してください[RFC8235]。アリスの場合、彼女は、第1ラウンドで8の累乗、第2ラウンドで4の累乗、セッションキーの最終計算で2の累乗を実行する必要があります。したがって、これは合計で14のモジュラ累乗です。対称性に基づいて、ボブの計算コストはまったく同じです。
The J-PAKE protocol works basically the same in the elliptic curve (EC) setting, except that the underlying multiplicative group over a finite field is replaced by an additive group over an elliptic curve. Nonetheless, the EC version of J-PAKE is specified here for completeness.
J-PAKEプロトコルは、基本的には楕円曲線（EC）設定でも同じですが、有限体上の基になる乗法群が楕円曲線上の加法群に置き換わります。それでも、完全を期すために、J-PAKEのECバージョンをここで指定します。
When implemented over an elliptic curve, J-PAKE may use the same EC parameters as ECDSA [FIPS186-4]. The FIPS 186-4 standard [FIPS186-4] defines three types of curves suitable for ECDSA: pseudorandom curves over prime fields, pseudorandom curves over binary fields, and special curves over binary fields called Koblitz curves or anomalous binary curves. All these curves that are suitable for ECDSA can also be used to implement J-PAKE. However, for illustration purposes, only curves over prime fields are described in this document. Typically, such curves include NIST P-256, P-384, and P-521. When choosing a curve, a level of 128-bit security or above is recommended. Let E(Fp) be an elliptic curve defined over a finite field Fp, where p is a large prime. Let G be a generator for the subgroup over E(Fp) of prime order n. Here, the NIST curves are used only as an example. Other secure curves such as Curve25519 are also suitable for implementation. The security proof of J-PAKE relies on the assumption that the DDH problem is intractable in the considered group.
楕円曲線上に実装すると、J-PAKEはECDSA [FIPS186-4]と同じECパラメータを使用できます。 FIPS 186-4標準[FIPS186-4]は、ECDSAに適した3種類の曲線を定義します。素数フィールド上の疑似ランダム曲線、バイナリフィールド上の疑似ランダム曲線、およびコブリッツ曲線または異常バイナリ曲線と呼ばれるバイナリフィールド上の特別な曲線。 ECDSAに適したこれらすべての曲線は、J-PAKEの実装にも使用できます。ただし、説明のために、このドキュメントでは素体上の曲線のみを説明します。通常、このような曲線にはNIST P-256、P-384、およびP-521が含まれます。曲線を選択するときは、128ビット以上のセキュリティレベルが推奨されます。 E（Fp）を有限体Fpで定義される楕円曲線とします。ここで、pは大きな素数です。 Gを素数次数nのE（Fp）上のサブグループのジェネレーターとします。ここでは、NIST曲線は例としてのみ使用されています。 Curve25519などの他の安全な曲線も実装に適しています。 J-PAKEのセキュリティ証明は、検討対象のグループではDDH問題が扱いにくいという前提に基づいています。
As before, let s denote the shared secret between Alice and Bob. The value of s falls within [1, n-1]. In particular, note that s MUST not be equal to 0 mod n.
前と同じように、アリスとボブの間の共有秘密を示しましょう。 sの値は[1、n-1]の範囲内です。特に、sは0 mod nに等しくてはならないことに注意してください。
Round 1: Alice selects ephemeral private keys x1 and x2 uniformly at random from [1, n-1]. Similarly, Bob selects ephemeral private keys x3 and x4 uniformly at random from [1, n-1].
ラウンド1：アリスは、一時的な秘密鍵x1とx2を[1、n-1]からランダムに均一に選択します。同様に、Bobは[1、n-1]からランダムに一時的な秘密鍵x3とx4をランダムに選択します。
o Alice -> Bob: G1 = G x [x1], G2 = G x [x2] and ZKPs for x1 and x2
o アリス->ボブ：G1 = G x [x1]、G2 = G x [x2]、x1とx2のZKP
o Bob -> Alice: G3 = G x [x3], G4 = G x [x4] and ZKPs for x3 and x4
o ボブ->アリス：G3 = G x [x3]、G4 = G x [x4]、x3およびx4のZKP
When this round finishes, Alice and Bob verify the received ZKPs as specified in [RFC8235]. As an example, to prove the knowledge of the discrete logarithm of D = G x [d] with respect to the base point G, the ZKP contains: {UserID, V = G x [v], r = v - d * c mod n}, where UserID is the unique identifier for the prover, v is a number chosen uniformly at random from [1, n-1] and c = H(G || V || D || UserID).
このラウンドが終了すると、アリスとボブは[RFC8235]で指定されているように受信したZKPを確認します。例として、基点Gに関するD = G x [d]の離散対数の知識を証明するために、ZKPには次のものが含まれます：{UserID、V = G x [v]、r = v-d * cここで、UserIDは証明者の一意の識別子、vは[1、n-1]およびc = H（G || V || D || UserID）からランダムに一様に選択された数値です。
The verifier shall check the prover's UserID is a valid identity and is different from its own identity. If the verification of the ZKP fails, the session is aborted.
検証者は、証明者のUserIDが有効なIDであり、自身のIDとは異なることを確認します。 ZKPの検証が失敗した場合、セッションは中止されます。
Round 2:
ラウンド2：
o Alice -> Bob: A = (G1 + G3 + G4) x [x2*s] and a ZKP for x2*s
o アリス->ボブ：A =（G1 + G3 + G4）x [x2 * s]およびx2 * sのZKP
o Bob -> Alice: B = (G1 + G2 + G3) x [x4*s] and a ZKP for x4*s
o ボブ->アリス：B =（G1 + G2 + G3）x [x4 * s]およびx4 * sのZKP
When the second round finishes, Alice and Bob verify the received ZKPs. The ZKPs are computed in the same way as in the previous round except that the generator is different. For Alice, the new generator is G1 + G3 + G4; for Bob, it is G1 + G2 + G3. Alice and Bob shall check that these new generators are not points at infinity. If any of these checks fails, the session is aborted. Otherwise, the two parties compute the common key material as follows:
2番目のラウンドが終了すると、アリスとボブは受信したZKPを確認します。 ZKPは、ジェネレーターが異なることを除いて、前のラウンドと同じ方法で計算されます。 Aliceの場合、新しいジェネレーターはG1 + G3 + G4です。ボブの場合、G1 + G2 + G3です。アリスとボブは、これらの新しいジェネレータが無限遠点ではないことを確認します。これらのチェックのいずれかが失敗した場合、セッションは中止されます。それ以外の場合、両者は次のように共通の鍵素材を計算します。
o Alice computes Ka = (B - (G4 x [x2*s])) x [x2]
o アリスはKa =（B-（G4 x [x2 * s]））x [x2]を計算します
o Bob computes Kb = (A - (G2 x [x4*s])) x [x4]
o ボブはKb =（A-（G2 x [x4 * s]））x [x4]を計算します
Here, Ka = Kb = G x [(x1+x3)*(x2*x4*s)]. Let K denote the same key material held by both parties. Using K as input, Alice and Bob then apply a Key Derivation Function (KDF) to derive a common session key k.
ここで、Ka = Kb = G x [（x1 + x3）*（x2 * x4 * s）]。 Kが両方の当事者が保持する同じ鍵の資料を示すものとします。 Kを入力として使用して、アリスとボブはキー導出関数（KDF）を適用し、共通のセッションキーkを導出します。
In the EC setting, the computational cost of J-PAKE is estimated based on counting the number of scalar multiplications over the elliptic curve. Note that it takes one multiplication to generate a Schnorr NIZK proof and one to verify it [RFC8235]. For Alice, she has to perform 6 multiplications in the first round, 3 in the second round, and 2 in the final computation of the session key. Hence, that is 11 multiplications in total. Based on the symmetry, the computational cost for Bob is exactly the same.
EC設定では、J-PAKEの計算コストは、楕円曲線上のスカラー倍数のカウントに基づいて推定されます。 Schnorr NIZKプルーフを生成するために1つの乗算が必要であり、それを検証するために1つの乗算が必要であることに注意してください[RFC8235]。アリスの場合、彼女は最初のラウンドで6つの乗算、2番目のラウンドで3つの乗算、およびセッションキーの最終計算で2つの乗算を実行する必要があります。したがって、これは合計で11の乗算です。対称性に基づいて、ボブの計算コストはまったく同じです。
The two-round J-PAKE protocol is completely symmetric, which significantly simplifies the security analysis. In practice, one party normally initiates the communication and the other party responds. In that case, the protocol will be completed in three passes instead of two rounds. The two-round J-PAKE protocol can be trivially changed to three passes without losing security. Take the finite field setting as an example, and assume Alice initiates the key exchange. The three-pass variant works as follows: 1. Alice -> Bob: g1 = g^x1 mod p, g2 = g^x2 mod p, ZKPs for x1 and x2.
2ラウンドのJ-PAKEプロトコルは完全に対称であり、セキュリティ分析を大幅に簡素化します。実際には、通常、一方の当事者が通信を開始し、もう一方の当事者が応答します。その場合、プロトコルは2ラウンドではなく3パスで完了します。 2ラウンドのJ-PAKEプロトコルは、セキュリティを失うことなく3パスに簡単に変更できます。有限フィールド設定を例に取り、アリスがキー交換を開始すると仮定します。 3パスバリアントは次のように機能します。1.アリス->ボブ：g1 = g ^ x1 mod p、g2 = g ^ x2 mod p、x1およびx2のZKP。
2. Bob -> Alice: g3 = g^x3 mod p, g4 = g^x4 mod p, B = (g1*g2*g3)^(x4*s) mod p, ZKPs for x3, x4, and x4*s.
2. ボブ->アリス：g3 = g ^ x3 mod p、g4 = g ^ x4 mod p、B =（g1 * g2 * g3）^（x4 * s）mod p、x3、x4、およびx4 * sのZKP。
3. Alice -> Bob: A = (g1*g3*g4)^(x2*s) mod p and a ZKP for x2*s.
3. アリス->ボブ：A =（g1 * g3 * g4）^（x2 * s）mod pとx2 * sのZKP。
Both parties compute the session keys in exactly the same way as before.
どちらのパーティも、以前とまったく同じ方法でセッションキーを計算します。
The two-round J-PAKE protocol (or the three-pass variant) provides cryptographic guarantee that only the authenticated party who used the same password at the other end is able to compute the same session key. So far, the authentication is only implicit. The key confirmation is also implicit [Stinson06]. The two parties may use the derived key straight away to start secure communication by encrypting messages in an authenticated mode. Only the party with the same derived session key will be able to decrypt and read those messages.
2ラウンドJ-PAKEプロトコル（または3パスバリアント）は、暗号化された保証を提供し、反対側で同じパスワードを使用した認証済みの当事者のみが同じセッションキーを計算できるようにします。これまでのところ、認証は暗黙的です。キーの確認も暗黙的です[Stinson06]。 2つのパーティは、すぐに派生キーを使用して、認証モードでメッセージを暗号化することにより、安全な通信を開始できます。同じ派生セッションキーを持つ当事者のみが、これらのメッセージを復号化して読み取ることができます。
For achieving explicit authentication, an additional key confirmation procedure should be performed. This provides explicit assurance that the other party has actually derived the same key. In this case, the key confirmation is explicit [Stinson06].
明示的な認証を実現するには、追加のキー確認手順を実行する必要があります。これにより、相手が実際に同じ鍵を導出したことが明示的に保証されます。この場合、鍵の確認は明示的です[Stinson06]。
In J-PAKE, explicit key confirmation is recommended whenever the network bandwidth allows it. It has the benefit of providing explicit and immediate confirmation if the two parties have derived the same key and hence are authenticated to each other. This allows a practical implementation of J-PAKE to effectively detect online dictionary attacks (if any), and stop them accordingly by setting a threshold for the consecutively failed connection attempts.
J-PAKEでは、ネットワーク帯域幅で許可されている場合は常に、明示的なキー確認をお勧めします。これには、2つのパーティが同じ鍵を導出したために相互に認証された場合に、明示的かつ即座に確認できるという利点があります。これにより、J-PAKEの実用的な実装により、オンライン辞書攻撃（存在する場合）を効果的に検出し、連続して失敗した接続試行のしきい値を設定することで、それに応じて攻撃を停止できます。
To achieve explicit key confirmation, there are several methods available. They are generically applicable to all key exchange protocols, not just J-PAKE. In general, it is recommended that a different key from the session key be used for key confirmation -- say, k' = KDF(K || "JPAKE_KC"). The advantage of using a different key for key confirmation is that the session key remains indistinguishable from random after the key confirmation process. (However, this perceived advantage is actually subtle and only theoretical.) Two explicit key confirmation methods are presented here.
明示的な鍵の確認を行うには、いくつかの方法があります。これらは、J-PAKEだけでなく、すべてのキー交換プロトコルに一般的に適用できます。一般に、セッション鍵とは異なる鍵を鍵の確認に使用することをお勧めします-たとえば、k '= KDF（K || "JPAKE_KC"）。鍵の確認に別の鍵を使用する利点は、鍵の確認プロセス後もセッション鍵がランダムと区別がつかないことです。 （ただし、この認識された利点は実際には微妙で理論的なものにすぎません。）ここでは、2つの明示的な鍵確認方法を示します。
The first method is based on the one used in the SPEKE protocol [Jab96]. Suppose Alice initiates the key confirmation. Alice sends to Bob H(H(k')), which Bob will verify. If the verification is successful, Bob sends back to Alice H(k'), which Alice will verify. This key confirmation procedure needs to be completed in two rounds, as shown below.
最初の方法は、SPEKEプロトコル[Jab96]で使用されている方法に基づいています。アリスが鍵の確認を開始するとします。アリスは、ボブが検証するH（H（k '））に送信します。検証が成功した場合、ボブはアリスH（k '）に送り返します。これはアリスが検証します。この鍵の確認手順は、以下に示すように、2つのラウンドで完了する必要があります。
1. Alice -> Bob: H(H(k'))
1. アリス->ボブ：H（H（k '））
2. Bob -> Alice: H(k')
2. ボブ->アリス：H（k '）
The above procedure requires two rounds instead of one, because the second message depends on the first. If both parties attempt to send the first message at the same time without an agreed order, they cannot tell if the message that they receive is a genuine challenge or a replayed message, and consequently may enter a deadlock.
2番目のメッセージは最初のメッセージに依存するため、上記の手順では、1ラウンドではなく2ラウンドが必要です。両方の当事者が合意された順序なしで最初のメッセージを同時に送信しようとした場合、受信したメッセージが本物のチャレンジであるか再生されたメッセージであるかを区別できず、結果としてデッドロックに入る可能性があります。
The second method is based on the unilateral key confirmation scheme specified in NIST SP 800-56A Revision 1 [BJS07]. Alice and Bob send to each other a MAC tag, which they will verify accordingly. This key confirmation procedure can be completed in one round.
2番目の方法は、NIST SP 800-56Aリビジョン1 [BJS07]で指定されている一方的な鍵の確認方式に基づいています。アリスとボブはお互いにMACタグを送信し、それに応じて確認します。この鍵の確認手続きは1回で完了できます。
In the finite field setting, it works as follows.
有限フィールド設定では、次のように機能します。
o Alice -> Bob: MacTagAlice = MAC(k', "KC_1_U" || Alice || Bob || g1 || g2 || g3 || g4)
o アリス->ボブ：MacTagAlice = MAC（k '、 "KC_1_U" ||アリス||ボブ|| g1 || g2 || g3 || g4）
o Bob -> Alice: MacTagBob = MAC(k', "KC_1_U" || Bob || Alice || g3 || g4 || g1 || g2)
o ボブ->アリス：MacTagBob = MAC（k '、 "KC_1_U" ||ボブ||アリス|| g3 || g4 || g1 || g2）
In the EC setting, the key confirmation works basically the same.
EC設定では、キー確認は基本的に同じように機能します。
o Alice -> Bob: MacTagAlice = MAC(k', "KC_1_U" || Alice || Bob || G1 || G2 || G3 || G4)
o アリス->ボブ：MacTagAlice = MAC（k '、 "KC_1_U" ||アリス||ボブ|| G1 || G2 || G3 || G4）
o Bob -> Alice: MacTagBob = MAC(k', "KC_1_U" || Bob || Alice || G3 || G4 || G1 || G2)
o ボブ->アリス：MacTagBob = MAC（k '、 "KC_1_U" ||ボブ||アリス|| G3 || G4 || G1 || G2）
The second method assumes an additional secure MAC function (e.g., one may use HMAC) and is slightly more complex than the first method. However, it can be completed within one round and it preserves the overall symmetry of the protocol implementation. For this reason, the second method is RECOMMENDED.
2番目の方法は、追加のセキュアMAC関数（たとえば、HMACを使用できる）を想定しており、最初の方法よりも少し複雑です。ただし、1回のラウンドで完了することができ、プロトコル実装の全体的な対称性が維持されます。このため、2番目の方法をお勧めします。
A PAKE protocol is designed to provide two functions in one protocol execution. The first one is to provide zero-knowledge authentication of a password. It is called "zero knowledge" because at the end of the protocol, the two communicating parties will learn nothing more than one bit information: whether the passwords supplied at two ends are equal. Therefore, a PAKE protocol is naturally resistant against phishing attacks. The second function is to provide session key establishment if the two passwords are equal. The session key will be used to protect the confidentiality and integrity of the subsequent communication.
PAKEプロトコルは、1回のプロトコル実行で2つの機能を提供するように設計されています。 1つ目は、パスワードのゼロ知識認証を提供することです。プロトコルの最後で、2つの通信する当事者は1ビットの情報しか学習しないため、「ゼロナレッジ」と呼ばれます。つまり、両端で提供されるパスワードが等しいかどうかを学習します。したがって、PAKEプロトコルは、フィッシング攻撃に対して自然に耐性があります。 2つ目の機能は、2つのパスワードが等しい場合にセッションキーを確立することです。セッションキーは、後続の通信の機密性と整合性を保護するために使用されます。
More concretely, a secure PAKE protocol shall satisfy the following security requirements [HR10].
より具体的には、セキュアなPAKEプロトコルは、次のセキュリティ要件[HR10]を満たします。
1. Offline dictionary attack resistance: It does not leak any information that allows a passive/active attacker to perform offline exhaustive search of the password.
1. オフライン辞書攻撃への耐性：パッシブ/アクティブ攻撃者がオフラインでパスワードを徹底的に検索できるようにする情報を漏らしません。
2. Forward secrecy: It produces session keys that remain secure even when the password is later disclosed.
2. Forward secrecy：パスワードが後で開示されても安全なままのセッションキーを生成します。
3. Known-key security: It prevents a disclosed session key from affecting the security of other sessions.
3. 既知のキーのセキュリティ：公開されたセッションキーが他のセッションのセキュリティに影響するのを防ぎます。
4. Online dictionary attack resistance: It limits an active attacker to test only one password per protocol execution.
4. オンライン辞書攻撃に対する耐性：アクティブな攻撃者がプロトコル実行ごとに1つのパスワードのみをテストすることを制限します。
First, a PAKE protocol must resist offline dictionary attacks. A password is inherently weak. Typically, it has only about 20-30 bits entropy. This level of security is subject to exhaustive search. Therefore, in the PAKE protocol, the communication must not reveal any data that allows an attacker to learn the password through offline exhaustive search.
まず、PAKEプロトコルはオフライン辞書攻撃に耐えなければなりません。パスワードは本質的に脆弱です。通常、エントロピーは20〜30ビット程度です。このレベルのセキュリティは、徹底的な検索の対象となります。したがって、PAKEプロトコルでは、通信は、攻撃者がオフラインの徹底的な検索を通じてパスワードを知ることを可能にするデータを明らかにしてはなりません。
Second, a PAKE protocol must provide forward secrecy. The key exchange is authenticated based on a shared password. However, there is no guarantee on the long-term secrecy of the password. A secure PAKE scheme shall protect past session keys even when the password is later disclosed. This property also implies that if an attacker knows the password but only passively observes the key exchange, he cannot learn the session key.
第2に、PAKEプロトコルは転送秘密を提供する必要があります。鍵交換は、共有パスワードに基づいて認証されます。ただし、パスワードの長期的な機密性は保証されません。安全なPAKEスキームは、パスワードが後で開示された場合でも、過去のセッションキーを保護します。この特性は、攻撃者がパスワードを知っているが、受動的にキー交換を観察するだけの場合、セッションキーを知ることができないことも意味します。
Third, a PAKE protocol must provide known key security. A session key lasts throughout the session. An exposed session key must not cause any global impact on the system, affecting the security of other sessions.
3番目に、PAKEプロトコルは既知のキーセキュリティを提供する必要があります。セッションキーはセッション全体を通じて持続します。公開されたセッションキーは、システムにグローバルな影響を与えてはならず、他のセッションのセキュリティに影響を与えてはなりません。
Finally, a PAKE protocol must resist online dictionary attacks. If the attacker is directly engaging in the key exchange, there is no way to prevent such an attacker trying a random guess of the password. However, a secure PAKE scheme should minimize the effect of the online attack. In the best case, the attacker can only guess exactly one password per impersonation attempt. Consecutively failed attempts can be easily detected, and the subsequent attempts shall be thwarted accordingly. It is recommended that the false authentication counter be handled in such a way that any error (which causes the session to fail during the key exchange or key confirmation) leads to incrementing the false authentication counter.
最後に、PAKEプロトコルはオンライン辞書攻撃に耐えなければなりません。攻撃者が直接鍵交換を行っている場合、そのような攻撃者がランダムなパスワード推測を試みるのを防ぐ方法はありません。ただし、安全なPAKEスキームは、オンライン攻撃の影響を最小限に抑える必要があります。最良のケースでは、攻撃者は偽装の試行ごとに1つのパスワードしか推測できません。連続して失敗した試行は簡単に検出でき、その後の試行はそれに応じて阻止されます。誤った認証カウンターは、エラー（鍵交換または鍵の確認中にセッションが失敗する原因）によって誤った認証カウンターが増加するような方法で処理することをお勧めします。
It has been proven in [HR10] that J-PAKE satisfies all of the four requirements based on the assumptions that the Decisional Diffie-Hellman problem is intractable and the underlying Schnorr NIZK proof is secure. An independent study that proves security of J-PAKE in a model with algebraic adversaries and random oracles can be found in [ABM15]. By comparison, it has been known that EKE has the problem of leaking partial information about the password to a passive attacker, hence not satisfying the first requirement [Jas96]. For SPEKE and SRP-6, an attacker may be able to test more than one password in one online dictionary attack (see [Zha04] and [Hao10]), hence they do not satisfy the fourth requirement in the strict theoretical sense. Furthermore, SPEKE is found vulnerable to an impersonation attack and a key-malleability attack [HS14]. These two attacks affect the SPEKE protocol specified in Jablon's original 1996 paper [Jab96] as well in the D26 draft of IEEE P1363.2 and the ISO/ IEC 11770-4:2006 standard. As a result, the specification of SPEKE in ISO/IEC 11770-4:2006 has been revised to address the identified problems.
[HR10]で、J-PAKEが決定的Diffie-Hellman問題は扱いにくく、基礎となるSchnorr NIZK証明が安全であるという仮定に基づいて、4つの要件すべてを満たしていることが証明されています。代数的敵とランダムなオラクルのモデルでJ-PAKEのセキュリティを証明する独立した研究は[ABM15]にあります。それとは対照的に、EKEにはパスワードに関する部分的な情報がパッシブな攻撃者に漏洩するという問題があることが知られており、最初の要件を満たしていません[Jas96]。 SPEKEおよびSRP-6の場合、攻撃者は1回のオンライン辞書攻撃（[Zha04]および[Hao10]を参照）で複数のパスワードをテストできる可能性があるため、厳密な理論的意味での4番目の要件を満たしません。さらに、SPEKEはなりすまし攻撃および鍵の柔軟性攻撃[HS14]に対して脆弱であることが判明しています。これら2つの攻撃は、Jablonの最初の1996年の論文[Jab96]と、IEEE P1363.2のD26ドラフトおよびISO / IEC 11770-4：2006標準で指定されているSPEKEプロトコルに影響を与えます。その結果、ISO / IEC 11770-4：2006のSPEKEの仕様は、特定された問題に対処するために改訂されました。
This document does not require any IANA actions.
このドキュメントでは、IANAアクションは必要ありません。
[ABM15] Abdalla, M., Benhamouda, F., and P. MacKenzie, "Security of the J-PAKE Password-Authenticated Key Exchange Protocol", 2015 IEEE Symposium on Security and Privacy, DOI 10.1109/sp.2015.41, May 2015.
[ABM15] Abdalla、M.、Benhamouda、F。、およびP. MacKenzie、「Security of the J-PAKE Password-Authenticated Key Exchange Protocol」、2015 IEEE Symposium on Security and Privacy、DOI 10.1109 / sp.2015.41、May 2015 。
[BM92] Bellovin, S. and M. Merrit, "Encrypted Key Exchange: Password-based Protocols Secure against Dictionary Attacks", IEEE Symposium on Security and Privacy, DOI 10.1109/risp.1992.213269, May 1992.
[BM92] Bellovin、S。およびM. Merrit、「暗号化鍵交換：辞書攻撃に対して安全なパスワードベースのプロトコル」、セキュリティとプライバシーに関するIEEEシンポジウム、DOI 10.1109 / risp.1992.213269、1992年5月。
[HR08] Hao, F. and P. Ryan, "Password Authenticated Key Exchange by Juggling", Lecture Notes in Computer Science, pp. 159-171, from 16th Security Protocols Workshop (SPW '08), DOI 10.1007/978-3-642-22137-8_23, 2011.
[HR08] Hao、F。およびP. Ryan、「ジャグリングによるパスワード認証鍵交換」、コンピュータサイエンスの講義ノート、159〜171ページ、第16回セキュリティプロトコルワークショップ（SPW '08）、DOI 10.1007 / 978-3 -642-22137-8_23、2011。
[HR10] Hao, F. and P. Ryan, "J-PAKE: Authenticated Key Exchange Without PKI", Transactions on Computational Science XI, pp. 192-206, DOI 10.1007/978-3-642-17697-5_10, 2010.
[HR10] Hao、F。、およびP. Ryan、「J-PAKE：Authenticated Key Exchange without PKI」、Computational Science XIのトランザクション、pp。192-206、DOI 10.1007 / 978-3-642-17697-5_10、2010 。
[HS14] Hao, F. and S. Shahandashti, "The SPEKE Protocol Revisited", Security Standardisation Research, pp. 26-38, DOI 10.1007/978-3-319-14054-4_2, December 2014.
[HS14] Hao、F。、およびS. Shahandashti、「The SPEKE Protocol Revisited」、セキュリティ標準化研究、26-38ページ、DOI 10.1007 / 978-3-319-14054-4_2、2014年12月。
[Jab96] Jablon, D., "Strong Password-Only Authenticated Key Exchange", ACM SIGCOMM Computer Communication Review, Vol. 26, pp. 5-26, DOI 10.1145/242896.242897, October 1996.
[Jab96] Jablon、D。、「強力なパスワードのみの認証済み鍵交換」、ACM SIGCOMM Computer Communication Review、Vol。 26、pp.5-26、DOI 10.1145 / 242896.242897、1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC5054] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin, "Using the Secure Remote Password (SRP) Protocol for TLS Authentication", RFC 5054, DOI 10.17487/RFC5054, November 2007, <https://www.rfc-editor.org/info/rfc5054>.
[RFC5054] Taylor、D.、Wu、T.、Mavrogiannopoulos、N。、およびT. Perrin、「Using the Secure Remote Password（SRP）Protocol for TLS Authentication」、RFC 5054、DOI 10.17487 / RFC5054、2007年11月、< https://www.rfc-editor.org/info/rfc5054>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC8235] Hao, F., Ed., "Schnorr Non-interactive Zero Knowledge Proof", RFC 8235, DOI 10.17487/RFC8235, September 2017, <https://www.rfc-editor.org/info/rfc8235>.
[RFC8235] Hao、F。、編、「Schnorr Non-interactive Zero Knowledge Proof」、RFC 8235、DOI 10.17487 / RFC8235、2017年9月、<https://www.rfc-editor.org/info/rfc8235>。
[SEC1] "Standards for Efficient Cryptography. SEC 1: Elliptic Curve Cryptography", SECG SEC1-v2, May 2009, <http://www.secg.org/sec1-v2.pdf>.
[SEC1]「効率的な暗号化の標準。SEC1：楕円曲線暗号化」、SECG SEC1-v2、2009年5月、<http://www.secg.org/sec1-v2.pdf>。
[Stinson06] Stinson, D., "Cryptography: Theory and Practice", 3rd Edition, CRC, 2006.
[Stinson06] Stinson、D。、「Cryptography：Theory and Practice」、第3版、CRC、2006年。
[Wu98] Wu, T., "The Secure Remote Password Protocol", Internet Society Symposium on Network and Distributed System Security, March 1998.
[Wu98] Wu、T.、 "The Secure Remote Password Protocol"、Internet Society Symposium on Network and Distributed System Security、1998年3月。
[AP05] Abdalla, M. and D. Pointcheval, "Simple Password-Based Encrypted Key Exchange Protocols", Topics in Cryptology CT-RSA, DOI 10.1007/978-3-540-30574-3_14, 2005.
[AP05] Abdalla、M。およびD. Pointcheval、「Simple Password-Based Encrypted Key Exchange Protocols」、Cryptology CT-RSAのトピック、DOI 10.1007 / 978-3-540-30574-3_14、2005。
[BJS07] 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, <http://csrc.nist.gov/publications/nistpubs/800-56A/ SP800-56A_Revision1_Mar08-2007.pdf>.
[BJS07] Barker、E.、Johnson、D。、およびM. Smid、「離散対数暗号化を使用したペアワイズキー確立スキームの推奨（改訂）」、NIST Special Publication 800-56A、2007年3月、<http：/ /csrc.nist.gov/publications/nistpubs/800-56A/ SP800-56A_Revision1_Mar08-2007.pdf>。
[BOINC] BOINC, "Index of /android-boinc/libssl/crypto/jpake", February 2011, <http://boinc.berkeley.edu/ android-boinc/libssl/crypto/jpake/>.
[BOINC] BOINC、「/ android-boinc / libssl / crypto / jpakeのインデックス」、2011年2月、<http://boinc.berkeley.edu/ android-boinc / libssl / crypto / jpake />。
[BOUNCY] Bouncy Castle Cryptography Library, "org.bouncycastle.crypto.agreement.jpake (Bouncy Castle Library 1.57 API Specification)", May 2017, <https://www.bouncycastle.org/docs/docs1.5on/org/ bouncycastle/crypto/agreement/jpake/package-summary.html>.
[BOUNCY] Bouncy Castle暗号化ライブラリ、「org.bouncycastle.crypto.agreement.jpake（Bouncy Castle Library 1.57 API仕様）」、2017年5月、<https://www.bouncycastle.org/docs/docs1.5on/org/ bouncycastle / crypto / agreement / jpake / package-summary.html>。
[FIPS186-4] National Institute of Standards and Technology, "Digital Signature Standard (DSS)", FIPS PUB 186-4, DOI 10.6028/NIST.FIPS.186-4, July 2013, <http://nvlpubs.nist.gov/nistpubs/FIPS/ NIST.FIPS.186-4.pdf>.
[FIPS186-4]米国国立標準技術研究所、「デジタル署名標準（DSS）」、FIPS PUB 186-4、DOI 10.6028 / NIST.FIPS.186-4、2013年7月、<http：//nvlpubs.nist。 gov / nistpubs / FIPS / NIST.FIPS.186-4.pdf>。
[Hao10] Hao, F., "On Small Subgroup Non-Confinement Attacks", IEEE Conference on Computer and Information Technology, DOI 10.1109/CIT.2010.187, 2010.
[Hao10] Hao、F。、「On On Small Subgroup Non-Confinement Attacks」、IEEE Conference on Computer and Information Technology、DOI 10.1109 / CIT.2010.187、2010。
[ISO.11770-4] ISO/IEC, "Information technology -- Security techniques -- Key management -- Part 4: Mechanisms based on weak secrets", (under development), July 2017, <https://www.iso.org/standard/67933.html>.
[ISO.11770-4] ISO / IEC、「情報技術-セキュリティ技術-鍵管理-パート4：弱い秘密に基づくメカニズム」、（開発中）、2017年7月、<https：//www.iso .org / standard / 67933.html>。
[Jas96] Jaspan, B., "Dual-Workfactor Encrypted Key Exchange: Efficiently Preventing Password Chaining and Dictionary Attacks", USENIX Symposium on Security, July 1996.
[Jas96] Jaspan、B。、「Dual-Workfactor Encrypted Key Exchange：Efficiently Preventing Password Chaining and Dictionary Attacks」、USENIX Symposium on Security、1996年7月。
[MOZILLA] Mozilla Wiki, "Services/KeyExchange", August 2011, <https://wiki.mozilla.org/index.php?title=Services/ KeyExchange&oldid=343704>.
[モジラ] Mozilla Wiki、「Services / KeyExchange」、2011年8月、<https://wiki.mozilla.org/index.php?title=Services/ KeyExchange＆oldid = 343704>。
[MOZILLA_NSS] Mozilla Central, "jpake.c - DXR", August 2016, <https://dxr.mozilla.org/mozilla-central/source/ security/nss/lib/freebl/jpake.c>.
[MOZILLA_NSS] Mozilla Central、「jpake.c-DXR」、2016年8月、<https://dxr.mozilla.org/mozilla-central/source/security/nss/lib/freebl/jpake.c>。
[PALEMOON] Moonchild Productions, "Pale Moon Sync", <https://www.palemoon.org/sync/>.
[PALEMOON] Moonchild Productions、「Pale Moon Sync」、<https://www.palemoon.org/sync/>。
[RFC4419] Friedl, M., Provos, N., and W. Simpson, "Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol", RFC 4419, DOI 10.17487/RFC4419, March 2006, <https://www.rfc-editor.org/info/rfc4419>.
[RFC4419] Friedl、M.、Provos、N。、およびW. Simpson、「Diffie-Hellman Group Exchange for the Secure Shell（SSH）Transport Layer Protocol」、RFC 4419、DOI 10.17487 / RFC4419、2006年3月、<https： //www.rfc-editor.org/info/rfc4419>。
[SOAA15] Smyshlyaev, S., Oshkin, I., Alekseev, E., and L. Ahmetzyanova, "On the Security of One Password Authenticated Key Exchange Protocol", 2015, <http://eprint.iacr.org/2015/1237.pdf>.
[SOAA15] Smyshlyaev、S.、Oshkin、I.、Alekseev、E。、およびL. Ahmetzyanova、「One Password Authenticated Key Exchange Protocolのセキュリティについて」、2015年、<http://eprint.iacr.org/2015 /1237.pdf>。
[THREAD] Thread, "Thread Commissioning", White Paper, July 2015, <https://portal.threadgroup.org/DesktopModules/ Inventures_Document/FileDownload.aspx?ContentID=658>.
[スレッド]スレッド、「スレッドコミッショニング」、ホワイトペーパー、2015年7月、<https://portal.threadgroup.org/DesktopModules/ Inventures_Document / FileDownload.aspx？ContentID = 658>。
[Zha04] Zhang, M., "Analysis of the SPEKE Password-Authenticated Key Exchange Protocol", IEEE Communications Letters, Vol. 8, pp. 63-65, DOI 10.1109/lcomm.2003.822506, January 2004.
[Zha04] Zhang、M。、「SPEKEパスワード認証鍵交換プロトコルの分析」、IEEE Communications Letters、Vol。 8、63-65ページ、DOI 10.1109 / lcomm.2003.822506、2004年1月。
Acknowledgements
謝辞
The editor would like to thank Dylan Clarke, Siamak Shahandashti, Robert Cragie, Stanislav Smyshlyaev, and Russ Housley for many useful comments. This work is supported by EPSRC First Grant (EP/J011541/1) and ERC Starting Grant (No. 306994).
編集者は、多くの有用なコメントをしてくれたDylan Clarke、Siamak Shahandashti、Robert Cragie、Stanislav Smyshlyaev、およびRuss Housleyに感謝します。この作品は、EPSRC First Grant（EP / J011541 / 1）およびERC Starting Grant（No. 306994）によってサポートされています。
Author's Address
著者のアドレス
Feng Hao (editor) Newcastle University (UK) Urban Sciences Building, School of Computing, Newcastle University Newcastle Upon Tyne United Kingdom
Feng Hao（編集者）ニューカッスル大学（イギリス）ニューカッスル大学スクールオブコンピューティング、ニューカッスルアポンタインイギリス
Phone: +44 (0)191-208-6384
Email: feng.hao@ncl.ac.uk