├── Reviews
├── dgotrik.pdf
└── YaronSheffer.html
├── Candidates
├── .DS_Store
├── J-PAKE.pdf
├── SPEKE.pdf
├── VTBPEKE.pdf
├── CPace and AuCPace - addendum.pdf
├── CPace and AuCPace - corrigendum.pdf
├── simulatorCode_CPace_AuCPace_StrongAuCPace.ods
├── BSPAKE info.md
├── SPAKE2.md
├── BSPAKE.md
└── OPAQUE.md
└── README.md
/Reviews/dgotrik.pdf:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/cfrg/pake-selection/HEAD/Reviews/dgotrik.pdf
--------------------------------------------------------------------------------
/Candidates/.DS_Store:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/cfrg/pake-selection/HEAD/Candidates/.DS_Store
--------------------------------------------------------------------------------
/Candidates/J-PAKE.pdf:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/cfrg/pake-selection/HEAD/Candidates/J-PAKE.pdf
--------------------------------------------------------------------------------
/Candidates/SPEKE.pdf:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/cfrg/pake-selection/HEAD/Candidates/SPEKE.pdf
--------------------------------------------------------------------------------
/Candidates/VTBPEKE.pdf:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/cfrg/pake-selection/HEAD/Candidates/VTBPEKE.pdf
--------------------------------------------------------------------------------
/Candidates/CPace and AuCPace - addendum.pdf:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/cfrg/pake-selection/HEAD/Candidates/CPace and AuCPace - addendum.pdf
--------------------------------------------------------------------------------
/Candidates/CPace and AuCPace - corrigendum.pdf:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/cfrg/pake-selection/HEAD/Candidates/CPace and AuCPace - corrigendum.pdf
--------------------------------------------------------------------------------
/Candidates/simulatorCode_CPace_AuCPace_StrongAuCPace.ods:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/cfrg/pake-selection/HEAD/Candidates/simulatorCode_CPace_AuCPace_StrongAuCPace.ods
--------------------------------------------------------------------------------
/Candidates/BSPAKE info.md:
--------------------------------------------------------------------------------
1 | PAKE nominated: BSPAKE
2 |
3 | Balanced/augmented: augmented
4 |
5 | Nominated by: Steve Thomas
6 |
7 | Reference to the description of the PAKE: https://mailarchive.ietf.org/arch/msg/cfrg/dtf91cmavpzT47U3AVxrVGNB5UM
8 |
9 | Comment: For an easier read that glosses over a few details (implementation specific things around "H()"):
10 | https://gist.github.com/Sc00bz/09b5836923ad986921b905723b0d0c02
11 |
12 | For an explicit description with all optional features and implementation ways explicitly pointed out: https://gist.github.com/Sc00bz/ef0951ab98e8e1bac4810f65a42eab1a
--------------------------------------------------------------------------------
/Candidates/SPAKE2.md:
--------------------------------------------------------------------------------
1 | First the auxiliary questions:
2 |
3 | SPAKE2 is a balanced PAKE. Both peers could initiate at the same time
4 | but must distinguish their roles somehow. It can be integrated into
5 | IKEv2 or the TLS handshake. There are per-group parameters: this is
6 | not a barrier to agility as a method for their generation is
7 | specified. There is no limit on applicability. The security model is
8 | not unusual and there are no problems with the proof. As for the
9 | security with common password entropy the standard security
10 | requirement for PAKE requires online guessing attempts equal in number
11 | to the number of passwords guessed. Clearly no scheme can do better,
12 | and as SPAKE2 has this property it is only as unsafe for common
13 | passwords as any scheme would have to be.
14 |
15 | SPAKE2 does not have a trusted setup: it does have two system
16 | parameters which are points of which of the discrete logs would lead
17 | to a security issue for any exchanges in the future. Any such
18 | computation would cast significant doubt on the difficulty of the
19 | discrete logarithm problem in the group. The protocol is 1 round.
20 | Password hashing guidance does not seem to differentiate PAKE
21 | protocols. It could of course be included in any document. The same
22 | for blocking user enumeration: the obvious trick is to use a random
23 | string as password and continue the PAKE.
24 |
25 | Now the main ones:
26 |
27 | * R1: It is a balanced PAKE
28 |
29 | * R2:
30 | There is a security proof in
31 | Abdalla, M. and D. Pointcheval, "Simple Password-Based
32 | Encrypted Key Exchange Protocols.", Feb 2005.
33 | Appears in A. Menezes, editor. Topics in Cryptography-
34 | CT-RSA 2005, Volume 3376 of Lecture Notes in Computer
35 | Science, pages 191-208, San Francisco, CA, US. Springer-
36 | Verlag, Berlin, Germany.
37 |
38 | in the ROM.
39 |
40 | * R3: There are no operations that pose any difficulty in rendering
41 | constant time implementations
42 |
43 | * R4: Irrelevant: there is no map in the scheme of the type discussed in RFC 8125.
44 |
45 | * R5:
46 | Each party conducts 4 point multiplications in the course of the
47 | protocol. Note that two of the multiplications may be combined into
48 | one computation of x*A+y*B which is moderately more efficient.
49 |
50 | * R6:
51 | I am not sure I understand what R6 is supposed to mean.
52 |
53 | * R7:
54 | Shielding identities is a difficult topic and very protocol specific.
55 |
56 | * R8: I am unaware of any patents that bear on SPAKE2.
57 |
58 |
--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
1 | This repository includes the source material for the CFRG PAKE selection process (summer of 2019), and a summary of the published reviews of the 8 candidates.
2 |
3 |
4 | # PAKE Candidates
5 |
6 | ## Balanced Algorithms
7 |
8 | | Name | Submitters | Round 2 | Authoritative Source | Additional Content | Comments |
9 | | ------ | --------------------------- | ----- |------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ |
10 | | SPAKE2 | Benjamin Kaduk, Watson Ladd |✓| [draft-irtf-cfrg-spake2-09](https://tools.ietf.org/html/draft-irtf-cfrg-spake2-09) (updated) | [Requirements](Candidates/SPAKE2.md) | |
11 | | J-PAKE | Feng Hao || [RFC8236](https://tools.ietf.org/html/rfc8236) | [Requirements](Candidates/J-PAKE.pdf) | |
12 | | SPEKE | Dan Harkins || https://eprint.iacr.org/2014/585 | [Requirements](Candidates/SPEKE.pdf) | Submitter note: The only thing to add is that when SPEKE is used with ECC a hash-to-curve method from the RFC that comes out of the CFRG (when it comes out of the CFRG) is necessary to produce the secret generator that SPEKE requires. |
13 | | CPace | Björn Haase |✓| https://eprint.iacr.org/2018/286 (updated) | [Addendum](Candidates/CPace%20and%20AuCPace%20-%20addendum.pdf) [Corrigendum](Candidates/CPace%20and%20AuCPace%20-%20corrigendum.pdf) [Simulator Code](Candidates/simulatorCode_CPace_AuCPace_StrongAuCPace.ods)| |
14 |
15 |
16 |
17 | ## Augmented Algorithms
18 |
19 | | Name | Submitters | Round 2 | Authoritative Source | Additional Content | Comments |
20 | | ------- | ------------- | ------- | ------------------------------------------------------------ | ------------------------------------------------------------ | -------- |
21 | | OPAQUE | Hugo Krawczyk |✓| [draft-krawczyk-cfrg-opaque-03](https://tools.ietf.org/html/draft-krawczyk-cfrg-opaque-03) | [Requirements](Candidates/OPAQUE.md) | |
22 | | AuCPace | Björn Haase |✓| https://eprint.iacr.org/2018/286 (updated) | [Addendum](Candidates/CPace%20and%20AuCPace%20-%20addendum.pdf) [Corrigendum](Candidates/CPace%20and%20AuCPace%20-%20corrigendum.pdf) [Simulator Code](Candidates/simulatorCode_CPace_AuCPace_StrongAuCPace.ods)| |
23 | | VTBPEKE | Guilin Wang || https://www.di.ens.fr/david.pointcheval/Documents/Papers/2017_asiaccsB.pdf | [Requirements](Candidates/VTBPEKE.pdf) | |
24 | | BSPAKE | Steve Thomas || | [Information](Candidates/BSPAKE%20info.md) [Requirements](Candidates/BSPAKE.md) | |
25 |
26 |
27 |
28 | # Summary of Reviews
29 |
30 | The table below lists all reviews submitted to the CFRG mailing list. We mention only the first message of each mail thread. Reviewers who feel the initial does not reflect their latest position are requested to provide feedback (see below), preferably with a single message/file that covers their entire review.
31 |
32 | | Author | Algorithms Covered | Link |
33 | | -------------------- | ----------------------------------- | ------------------------------------------------------------ |
34 | | Scott Fluhrer | All balanced | https://mailarchive.ietf.org/arch/msg/cfrg/HssFKRoUdM2kyVt4T9j_KPZqAmE Re-review: https://mailarchive.ietf.org/arch/msg/cfrg/MZ-L7qSTDZEtC9hjhPNyGOhXUlQ |
35 | | Bill Cox | OPAQUE | https://mailarchive.ietf.org/arch/msg/cfrg/-B16hIOerRsHgoIxiln05TiJ17o |
36 | | Valery Smyslov | All candidates, for IKEv2 | https://tools.ietf.org/html/draft-smyslov-ikev2-pake-00 |
37 | | Yoav Nir | All candidates, for IKEv2 | https://mailarchive.ietf.org/arch/msg/cfrg/PWhIOQKBHapZ1Rpbd7Brr_JFIg8 |
38 | | Kevin Lewi | All augmented | https://mailarchive.ietf.org/arch/msg/cfrg/9E1owZANyjCEZW44IWj0u1Lze2I |
39 | | Jonathan Hoyland | All augmented, for TLS | https://mailarchive.ietf.org/arch/msg/cfrg/FaY_3w5lWtygha0DTY5hJ9Yy7WU |
40 | | Bjoern Tackmann | All augmented (preliminary) | https://mailarchive.ietf.org/arch/msg/cfrg/euWBn5Nku0WFGKQ6qcITaCKVM-k |
41 | | Brian Warner | All balanced, for Magic-Wormhole | https://mailarchive.ietf.org/arch/msg/cfrg/BBQ2gwCECu5ouTJjE_CE6d9Rg-0 |
42 | | Karthik Bhargavan | All balanced, for TLS 1.3 | https://mailarchive.ietf.org/arch/msg/cfrg/5VhZLYGpzU8MWPlbMr2cf4Uc-nI |
43 | | Steve Thomas | All augmented | https://mailarchive.ietf.org/arch/msg/cfrg/AQtLrLSfATpOKxdjAakacnp2cBo |
44 | | Thyla van der Merwe | All candidates | https://docs.google.com/document/d/114t9rTk-d4nkTJZbEwwAn83uRy0ru2dm5qwOj0AMFaw/edit?usp=sharing |
45 | | Stanislav Smyshlyaev | All balanced | https://docs.google.com/document/d/1czsluXWzGNnlzJDChcULAB_sqFaUWHzGMKjkjZDBMok/edit?usp=sharing |
46 | | David Gotrik | All candidates, for constrained IoT | [review](Reviews/dgotrik.pdf) |
47 | | Tibor Jager | All augmented | https://docs.google.com/document/d/1jAQm4lCUSJO73vyS14hF8Cl__grsOTF-Jj_CCStJDuU/edit?usp=sharing
48 |
49 |
50 | # Overall Reviews by Crypto Review Panel
51 |
52 | The table below lists all overall reviews submitted by the Crypto Review Panel members during Stage 5 of the PAKE selection process.
53 |
54 | | Author | Link |
55 | | -------------------- | ------------------------------------------------------------ |
56 | | Bjoern Tackmann | https://mailarchive.ietf.org/arch/msg/cfrg/1sNu9USxo1lnFdzCL5msUFKBjzM |
57 | | Stanislav Smyshlyaev | https://docs.google.com/document/d/1-vzeCtSrm7zfoolr1JQdNqtp6KrtVEjitkH0OmjKapc/edit?usp=sharing |
58 | | Russ Housley | https://docs.google.com/document/d/1L6lqueEB70C4QptEnjfWx-bhBdg6cT73ymmmm9WUAR0/edit?usp=sharing |
59 | | Yaron Sheffer | [review](https://tools.ietf.org/html/draft-sheffer-cfrg-pake-review-00) |
60 |
61 | # Questions for Round 2
62 |
63 | 1) (to SPAKE2): Can you propose a modification of SPAKE2 (preserving all existing good properties of PAKE2) with a correspondingly updated security proof, addressing the issue of a single discrete log relationship necessary for the security of all sessions (e.g., solution based on using M=hash2curve(A|B), N=hash2curve(B|A))?
64 | 2) (to CPace and AuCPace): Can you propose a modification of CPace and AuCPace (preserving all existing good properties of these PAKEs) with a correspondingly updated security proof (maybe, in some other security models), addressing the issue of requiring the establishment of a session identifier (sid) during each call of the protocol for the cost of one additional message?
65 | 3) (to all 4 remaining PAKEs) : Can the nominators/developers of the protocols please re-evaluate possible IPR conflicts between their candidates protocols and own and foreign patents? Specifically, can you discuss the impact of U.S. Patent 7,047,408 (expected expiration 10th of march 2023) on free use of SPAKE2 and the impact of EP1847062B1 (HMQV, expected expiration October 2026) on the free use of the RFC-drafts for OPAQUE?
66 | 4) (to all 4 remaining PAKEs) What can be said about the property of "quantum annoyance" (an attacker with a quantum computer needs to solve [one or more] DLP per password guess) of the PAKE?
67 | 5) (to all 4 remaining PAKEs) What can be said about "post-quantum preparedness" of the PAKE?
68 |
69 | # Answers on Round 2
70 |
71 | | Protocol | Link |
72 | | -------------------- | ------------------------------------------------------------ |
73 | | CPace and AuCPace | https://mailarchive.ietf.org/arch/msg/cfrg/eRNe0SYH3lwHifwZkmqHRy4pdNE |
74 | | SPAKE2 | https://mailarchive.ietf.org/arch/msg/cfrg/senXefqczpUZo26B35ekz8d3iLo |
75 | | OPAQUE | https://mailarchive.ietf.org/arch/msg/cfrg/EJnaKEh_RamzghcjAik5v9_Fwf8 |
76 |
77 | Related information on IPR (SPAKE2): https://datatracker.ietf.org/ipr/4018/
78 |
79 | # Reviews by Crypto Review Panel, Round 2
80 |
81 | The table below lists all overall reviews submitted by the Crypto Review Panel members during Stage 5 of the PAKE selection process.
82 |
83 | | Author | Link |
84 | | -------------------- | ------------------------------------------------------------ |
85 | | Bjoern Tackmann | https://mailarchive.ietf.org/arch/msg/cfrg/eo8O6JYPmWY6L9TlcIXStFy5gNQ/ |
86 | | Julia Hesse | https://mailarchive.ietf.org/arch/msg/cfrg/47pnOSsrVS8uozXbAuM-alEk0-s/ |
87 | | Russ Housley | https://mailarchive.ietf.org/arch/msg/crypto-panel/r3ktVcmPA-POVMNjVBmY84lTOHA/ |
88 | | Scott Fluhrer | https://mailarchive.ietf.org/arch/msg/cfrg/JwBPf_71G6JcfUttFw9MbvnIDCU/ |
89 |
90 | # Providing Feedback
91 |
92 | To update the base material for a PAKE candidate or any of the reviews, please open an issue or, better yet, submit a pull request. Any substantial change should be reported to the [CFRG mailing list](https://mailarchive.ietf.org/arch/browse/cfrg/). Please include a link to the mailing list post.
93 |
94 |
--------------------------------------------------------------------------------
/Candidates/BSPAKE.md:
--------------------------------------------------------------------------------
1 | ## REQ1: A PAKE scheme MUST clearly state its features regarding balanced/augmented versions.
2 | Augmented PAKE
3 |
4 | ## REQ2: A PAKE scheme SHOULD come with a security proof and clearly state its assumptions and models.
5 |
6 | This is based off SPAKE2 which has a security proof in Abdalla, M. and D. Pointcheval, "Simple
7 | Password-Based Encrypted Key Exchange Protocols.", Feb 2005.
8 | SPAKE2+ adds one term to the end hash of SPAKE2 (b*v*G). b is the server's ephemeral
9 | private key and v is derived from the password. Server stores v*G it is assumed that solving the
10 | DLP to get v is hard. It is assumed a proper KDF is used and it is not possible to generate v
11 | from the other server data. Client generates v from the password and applies that to b*G. Thus
12 | SPAKE2+ is a secure aPAKE.
13 |
14 | SPAKE2+EE changes the blinding terms from H(pw, N)*N and H(pw, M)*M to
15 | hashToPoint(H(pw, N)) and hashToPoint(H(pw, M)) where hashToPoint is Elligator or Shallue-
16 | Woestijne-Ulas (SWU). Most assume hash to point to be a random oracle. The only issue is
17 | with uneven distribution from field P to cyclical group size Q. If someone determines this to be a
18 | problem which I don't think it is, we can fix it by multiplying the point generated from the hash to
19 | point algorithm by another key based off the password: "H(pw, N2)*hashToPoint(H(pw, N))".
20 | This only adds two multiplies to the client side and server can do these once (or be given the
21 | points during registration) and store the points. Since the client is doing a password KDF this
22 | change should not affect runtime by much.
23 |
24 | BSPAKE adds blind salt to SPAKE2+EE which should be able to use OPQAUE's security proof
25 | of blind salt. There's also security analysis of blind salt in this
26 | paper https://eprint.iacr.org/2015/644.pdf. Also note that blind salt only adds precomputation
27 | security.
28 |
29 | ## REQ3: The authors SHOULD show how to protect their PAKE scheme
30 |
31 | implementation in hostile environments, particularly, how to
32 | implement their scheme in constant time to prevent timing
33 | attacks.
34 |
35 | Elligator or Shallue-Woestijne-Ulas (SWU) can be done in constant time. The only thing is in the
36 | hash to point. There is an if statement while doing the square root, this should use a conditional
37 | move to prevent timing attacks. Everything else is standard ECC operations, finite field
38 | operations, or hashing. Well besides the password KDF but that's pick one without timing
39 | attacks.
40 |
41 | ## REQ4: If the PAKE scheme is intended to be used with ECC, the
42 |
43 | authors SHOULD discuss their requirements for a potential
44 | mapping or define a mapping to be used with the scheme.
45 | Elligator and Shallue-Woestijne-Ulas (SWU) are good choices. Other hash to point algorithms
46 | that don't rely on a loop and are constant time should also be fine.
47 |
48 | ## REQ5: The authors of a PAKE scheme MAY discuss its design choice with regard to performance, i.e., its optimization goals.
49 |
50 | Server can store the blinding points "N" and "M" to minimize computations or store a key that is
51 | expanded to those and "k3". So either store N, M, k3, and v*G or "k" and v*G. Then with "k"
52 | derive keys necessary for N, M, and k3.
53 | Client side the initial blind salt calculation "r*H(pw, serverId, clientId)*G" can be done x=r*H(pw,
54 | serverId, clientId) (mod cyclical group size) then do one scalar multiply x*G. Also if using
55 | Ed25519 generate r as 1/(8*random()). This way when you unblind by multiplying by 1/r it is a
56 | multiple of 8.
57 |
58 | For minimizing RTT, the client can start encrypting after 2 messages (client->server, server- client) and the server after 3 messages (client->server, server->client, client->server). Note, which applies to all PAKEs, either party can encrypt a message with a random key and send that key in their "first" encrypted message to decrease latency due to bandwidth.
59 |
60 | ## REQ6: The authors of a scheme MAY discuss variations of their scheme that allow the use in special application scenarios. In particular, techniques that facilitate long-term (public) key agreement are encouraged.
61 |
62 | Like all PAKEs you end up hashing a bunch of stuff to get a key. From that key you derive
63 | verifiers and session keys. The session keys can be used long-term. I may have misunderstood
64 | the question. Also I'm not technically an author unless you call adding blind salt to SPAKE2+EE
65 | being an author.
66 |
67 | ## REQ7: Authors of a scheme MAY discuss special ideas and solutions on privacy protection of its users.
68 |
69 | If user is not found, one could use default values for N, M, k3, and v*G (or k and v*G) because
70 | there's no way to determine if the same values are used every time. Also the default values
71 | should be generated from random as to not make a successful exchange.
72 |
73 | ## REQ8: The authors MUST follow the IRTF IPR policy .
74 |
75 | I am unaware of any patents on BSPAKE.
76 |
77 | * How does it meet the "SHOULD" requirements of RFC 8125? See above.
78 | * Does it meet "crypto agility" requirements, not fixing any particular primitives and/or
79 | parameters?
80 | Works with any ECC curve that works with Elligator and Shallue-Woestijne-Ulas (SWU). For example it works with all NIST P curve but P-224 because its field is not 3 modulo 4.
81 |
82 | * What setting is the PAKE suitable for, which applications does it have?
83 | + "Peer communication" (where both ends share the same password) or "client-server" (where
84 | the server does not store the password but only a one-way function of the password)?
85 | Client-server, but technically all client-server PAKEs can be used as peer communication. It's
86 | just less efficient.
87 | + A nomination should specify for which use-cases the protocol is recommended ("PAKE as a
88 | more-secure replacement for a PSK on a machine-2-machine interface" or "PAKE for securely
89 | accessing a remote HMI interface server (e.g. a web server) without configured WEB-PKI
90 | certificates").
91 | "PAKE for securely accessing a remote HMI interface server (e.g. a web server) without
92 | configured WEB-PKI certificates."
93 | + Can two communicating parties initiate the key exchange process at the same time, or must it
94 | always be the case that only one party can initiate the process?
95 | Client initiates the process.
96 | + Is it suitable to be considered as a standalone scheme? Yes?
97 | + Can it be integrated into IKEv2? TLS Handshake? Any other protocols?
98 | * Is there a publicly available security proof? If yes, Sort of, see REQ2.
99 | + Are there known problems with the proof? Yes, it's not a legit proof.
100 | Yes. Only requirement is that the protocol let's you add the aPAKE's session key(s) to the
101 | protocol's session key(s).
102 | + Is the considered security model relevant for all applications that PAKE is intended for (e.g., if
103 | a PAKE is to be used in TLS Handshake, it is important that the TLS adversary model is
104 | considered for the PAKE)?
105 | No. It's assumed everyone is malicious and have access to a "slow" quantum computer. If the
106 | attacker observed a successful PAKE exchange, can solve a DLP in about a minute, and the password is not in the top 10,000 passwords, then it will take over a year to crack the password.
107 | Also depending on rate limiting you can probably guess 10,000 passwords in under a year by
108 | just acting like a user. Note most other PAKEs get offline classical computer password cracking
109 | if you solve just one or two DLPs.
110 | + Does it allow to be sure in sufficient level of security for common values of password lengths?
111 | Yes? Like all aPAKEs it depends on weather rate limiting is used and if the server's data is
112 | taken, then the password KDF. Active attackers can just make online password guesses or stop
113 | exchanges. PQ attackers need to observe a successful exchange and solve a DLP per
114 | password guess. Most other PAKEs it's solve one or two DLPs and get offline classical
115 | computer password cracking. In the case of OPAQUE a PQ attacker doesn't need to observe a
116 | successful exchange as all the information is given during a normal wrong password guess.
117 | * Security assessment.
118 | + Does its security depend on any nontrivial implementation properties? Are they clearly stated
119 | in the document?
120 | Hash to point is the only issue. I believe the main issue is with uneven distribution of hash to
121 | point. There is a remedy in REQ2 (part 3).
122 | + Does the PAKE have precomputation security (for augmented PAKEs)? Yes.
123 | No.
124 | + If the PAKE relies on the assumption of a trusted setup - more specifically, the discrete
125 | logarithm relationship between the two group elements in the system setup MUST be unknown -
126 | in anticipation of the worst but not impossible scenario, the authors should clearly state the
127 | security implications when the discrete logarithm relationship becomes known, and the
128 | subsequent mitigation measures.
129 | * Performance assessment.
130 | + What's with the “round efficiency” of the PAKE? In a standard two/multi-party secure
131 | computation setting, the “round” is defined as a step in which all parties can complete
132 | operations at the same time without depending on each other. In practice, a 2-round protocol
133 | could be implemented as 2 flows or 3 flows depending on the application context, but that’s
134 | more the implementation detail.
135 | Only 4 messages/"flows" are sent to verify both parties (client->server, server->client, client-server, server->client). The client can start encrypting after 2 messages (client->server, server-
136 | client) and the server after 3 messages (client->server, server->client, client->server). Server
137 | verifies the client after 3 messages and client verifies the server after 4 messages.
138 | + How many operations of each type (scalar multiplications, inversions in finite fields, hash
139 | calculations etc.) are made by each side?
140 |
141 | Client: 5 scalar multiplications, 6 finite field inversions, 2 point adds, 2 from data to point, 1 finite
142 | field multiply, 2 hash to point, 1 password KDF, 8 hashes (one of which is ~4 blocks)
143 | Server: 4 scalar multiplications, 4 finite field inversions, 2 point adds, 2 from data to point, 0
144 | finite field multiply, 0 hash to point, 0 password KDF, 4 hashes (one of which is ~4 blocks and
145 | one is optional)
146 | When the server stores v*G and "k" (vs N, M, k3, and v*G) it adds 2 hash to point, 3 hashes
147 | (one is optional) to the server.
148 | * Which recommendations for secure usage can be given?
149 | + Is it defined how the explicit key confirmation is performed/must be performed externally? Are
150 | there clear statements whether this procedure is optional or mandatory?
151 | Either but you save on RTT if it's done during. It is not clear, but to make it clear: it is optional
152 | but the client should be the first to verify or send encrypt data (with AEAD so the server can
153 | verify). This is to not let a malicious client from gaining data that they can use for an offline PQ
154 | attacker.
155 | + Can any recommendations on using iterated hashing (e.g., with Scrypt) with the PAKE be
156 | given?
157 | Argon2 is probably the one to go with. If a good cache hard password KDF comes out, that
158 | would probably be ideal. This is because cache hard algorithms are harder for GPUs at shorter
159 | runtimes than memory hard algorithms like Argon2 and scrypt. Also memory hard algorithms
160 | aren't good for lightweight computers such as wireless routers.
161 | PBKDF2 should be avoided unless required to be use because of NIST or other regulatory
162 | requirements. If you do use PBKDF2, be mindful of its footgun. Or use its footgun to make a
163 | better password KDF ("Parallel PBKDF2").
164 | + Can any recommendations to avoid a user enumeration attack be given? See REQ7.
165 |
--------------------------------------------------------------------------------
/Candidates/OPAQUE.md:
--------------------------------------------------------------------------------
1 | Below are responses to the list of requirements from RFC 8125 as well as answers to the questions in your email from July 5th as they apply to OPAQUE. I have also posted a new version of the OPAQUE draft https://tools.ietf.org/html/draft-krawczyk-cfrg-opaque-02
2 | From RFC 8125:
3 |
4 | ## REQ1: A PAKE scheme MUST clearly state its features regarding balanced/augmented versions.
5 |
6 | OPAQUE is an augmented PAKE (aPAKE) with security against pre-computation attacks.
7 |
8 | ## REQ2: A PAKE scheme SHOULD come with a security proof and clearly state its assumptions and models.
9 |
10 | A detailed security analysis is presented in the paper (Eurocrypt'2018): https://eprint.iacr.org/2018/163.pdf
11 | Analysis is carried in the Universally Composable model under a stronger security definition that covers pre-computation attacks.
12 | The analysis is carried in the random oracle model under the One-More Diffie-Hellman assumption.
13 |
14 | ## REQ3: The authors SHOULD show how to protect their PAKE scheme implementation in hostile environments, particularly, how to implement their scheme in constant time to prevent timing attacks.
15 |
16 | OPAQUE combines an Oblivious PRF (OPRF) with any KCI-secure key exchange. The implementation of the latter would follow best implementation practices as relate to that particular protocol.
17 | For the OPRF defined in the OPAQUE draft, namely, based on elliptic curves, an operation mapping the password into the curve is needed. This is the most tricky aspect for implementation in terms of choosing the right transform into the curve and avoiding timing attacks.
18 | Fortunately, these aspects are now being documented in the CFRG document draft-sullivan-cfrg-voprf.
19 |
20 | ## REQ4: If the PAKE scheme is intended to be used with ECC, the authors SHOULD discuss their requirements for a potential mapping or define a mapping to be used with the scheme.
21 |
22 | See response to REQ3.
23 |
24 | ## REQ5: The authors of a PAKE scheme MAY discuss its design choice with regard to performance, i.e., its optimization goals.
25 |
26 | The key exchange part of OPAQUE can be chosen depending on different practical criteria such as performance, code availability,
27 | compatibility with an existing protocol (e.g., TLS, IKE), etc.
28 | The OPRF part can be optimized by the choice of elliptic curve and a
29 |
30 | corresponding mapping into the curve. The OPAQUE draft is written
31 | with multiplicative blinding which improves performance in some cases (as discussed in the draft). Hardening, e.g., via iterated hashing, is offloaded to the client, a significant performance gain for servers in
32 | many cases. (See more on these aspects in questions Q13, Q14 and Q17 below.)
33 |
34 | ## REQ6: The authors of a scheme MAY discuss variations of their scheme that allow the use in special application scenarios. In particular, techniques that facilitate long-term (public) key agreement are encouraged.
35 |
36 | ## REQ7: Authors of a scheme MAY discuss special ideas and solutions on privacy protection of its users.
37 |
38 | The OPAQUE draft explicitly discusses this issue, particularly in the
39 | context of TLS 1.3 where different mechanisms may be used to provide protection to user information. These include techniques that do not
40 | incur additional messages, e.g., using resumed sessions or a mechanism similar to ESNI draft-ietf-tls-esni, as well as use of TLS 1.3 full
41 | handshake augmented with two OPAQUE messages. This is described in the OPAQUE draft and further elaborated in draft-sullivan-tls-opaque.
42 |
43 | ## REQ8: The authors MUST follow the IRTF IPR policy .
44 |
45 | The only patent I know of that covers an element discussed in the OPAQUE draft is IBM's patent on HMQV. Using HMQV with OPAQUE is completely optional. It is described in the draft as the most
46 | efficient key-exchange protocol with which OPAQUE can be integrated, but many other protocols (as also described in the draft) can be used.
47 | If there is interest in standardizing OPAQUE with HMQV one can check if a free license of the HMQV patent could be provided for such use.
48 | Additional questions from cfrg email (by Stanislav V. Smyshlyaev) on 7/5/2019:
49 | Note: Questions are in the same order as in the original email but the numbering is mine.
50 |
51 | Q1: How does it meet the "SHOULD" requirements of RFC 8125? See above.
52 |
53 | Q2: Does it meet "crypto agility" requirements, not fixing any particular primitives and/or parameters?
54 | OPAQUE is fully modular: It uses any OPRF and any KCI-secure key exchange.
55 |
56 | Q3: What setting is the PAKE suitable for, which applications does it have? OPAQUE is an asymmetric/augmented PAKE targeted to the client-server setting. The ultimate goal would be to replace password-over-TLS with the much more secure OPAQUE. In the first stages of deployment, one should target applications that have full control of the user-side ending as opposed to relying on generic web-browser environment. Phone-based and some enterprise applications seem good candidates for deployment (but I am a non-expert in actual deployment of such technology - others will
57 | know better).
58 |
59 | Q4: Can two communicating parties initiate the key exchange process at the same time, or must it always be the case that only one party can initiate the process?
60 | This question is relevant to symmetric PAKE not aPAKE where the client is the one to initiate the exchange.
61 |
62 | Q5: Is it suitable to be considered as a standalone scheme?
63 | The instantiations with SIGMA and HMQV illustrated in the draft are
64 | a basis for stand-alone schemes. However, if user's account information is to be protected from eavesdroppers then an additional mechanism for accomplishing that is needed.
65 |
66 | Q6: Can it be integrated into IKEv2? TLS Handshake? Any other protocols?
67 | Yes! This is one of the attractive properties of OPAQUE. Given its modularity, it can be adapted to work with different key exchange protocols. The OPAQUE draft illustrates this feature for the case of TLS 1.3, with a more extensive treatment in draft-sullivan-tls-opaque. Integration with IKE should not be too hard, particularly given that IKE follows the SIGMA protocol which is well suited for integration.
68 |
69 | Q7: Is there a publicly available security proof? If yes, Are there known problems with the proof?
70 | Yes. See answer to REQ2 above. No known problems with the proof.
71 | Two observations for the expert: First, as noted in the paper, the 2-message case (without explicit client authentication) requires a slight relaxation of the UC SaPAKE functionality (without diminishing security against pre-computation attacks). Second, as noted in the paper using multiplicative blinding raises some technical issues which we are still studying (paper should be available shortly). The current OPAQUE draft obviates these technicalities by including the value vU under the OPRF hash. One aspect of the analysis that can be improved is that the current model assumes static corruptions. Moving away from the random oracle model (with its known limitations when implementing it with actual hash functions) would be good, but improbable at this time.
72 | The OPAQUE draft includes a discussion (under security consideratrions) about the applicability to OPAQUE of the Brown and Gallant [BG04] and Cheon [Cheon06] attacks on the one-more DH assumption. The conclusion is that this attack is not practical in the OPAQUE setting.
73 |
74 | Q8: Is the considered security model relevant for all applications that PAKE is intended for (e.g., if a PAKE is to be used in TLS Handshake, it is important that the TLS adversary model is considered for the PAKE)?
75 | OPAQUE assumes composition with a secure key-exchange protocol which is resistant to KCI attacks. Any such protocol can be used with OPAQUE.
76 | TLS 1.3 offers such security as analyzed in different papers and by
77 | different methods. As always, the security of actually deployed
78 | protocols is more complex than their underlying theoretical design and analysis. But as long as one uses and implements correctly the OPRF part of OPAQUE, if native TLS 1.3 mechanisms are used for the rest of the protocol then OPAQUE would be no less secure than TLS (and much more secure in comparison to the password-over-TLS application).
79 |
80 | Q9: Does it allow to be sure in sufficient level of security for common values of password lengths?
81 | Password length makes no difference to the security analysis of OPAQUE. Obviously, a low entropy password facilitates only and offline attacks.
82 |
83 | Q10: Does its security depend on any nontrivial implementation properties? Are they clearly stated in the document?
84 | Note that the OPAQUE draft is not intended as a full detailed specification but as a general description that explains the different components of the protocol, their interaction, and functionality.
85 | A precise specification from which interoperable implementations can developed will be produced when consensus is reached into the best way to instantiate OPAQUE pieces. Yet, the draft already highlights issues of implementation; it also refers to draft-irtf-cfrg-hash-to-curve and draft-sullivan-cfrg-voprf for the more subtle issues surrounding OPRF implementation.
86 |
87 | Q11: Does the PAKE have precomputation security (for augmented PAKEs)?
88 | Yes.
89 |
90 | Q12: Does the PAKE relies on the assumption of a trusted setup
91 | No. It doesn't.
92 |
93 | Q13: What's with the "round efficiency" of the PAKE?
94 | I am not sure I understand your definition of "round". I prefer to talk
95 | in terms of number of messages (i.e., flows or flights in TLS
96 | terminology). OPAQUE costs two messages for computing the OPRF and any number of messages as defined for the key exchange in use. In many
97 | cases, e.g., SIGMA, HMQV, these messages can be parallelized resulting
98 | in 2 or 3 messages for the whole protocol (3 is always needed if
99 | explicit client authentication is required). Protecting user account
100 | information can add up to two messages depending the setting.
101 |
102 | Q14: How many operations of each type (scalar multiplications, inversions in finite fields, hash calculations etc.) are made by each side?
103 | From the OPAQUE draft:
104 | The computational cost of OPAQUE is determined by the cost of the OPRF, the cost of a regular Diffie-Hellman exchange, and the cost of authenticating such exchange. In our elliptic-curve implementation of
105 | the OPRF, the cost for the client is two exponentiations (one or two of which can be fixed base!) and one hashing-into-curve operation;
106 | for the server, it is just one exponentiation. The cost of a DH exchange
107 | is as usual two exponentiations per party (one of which is fixed-base). Finally, the cost of authentication per party depends on the specific KE
108 | protocol: it is just 1/6 of an exponentiation with HMQV and it is one signature in the case of SIGMA and TLS 1.3. These instantiations preserve the number of messages (two or three) in the underlying KE protocol except in one of the TLS instantiations where user privacy requires an additional round trip (this can be saved if using a mechanism similar to the proposed ESNI extension {{I-D.ietf-tls-esni}}).
109 |
110 | Q15: Which recommendations for secure usage can be given?
111 | Not sure what this refers to. If the above answers do not address this, please let me know.
112 |
113 | Q16: Is it defined how the explicit key confirmation is performed/must be performed externally? Are there clear statements whether this procedure is optional or mandatory?
114 | Performing key confirmation is a design choice that may depend on the chosen key exchange protocol and desired properties. The security of OPAQUE as an aPAKE does not depend on a key confirmation step (except if one re-defines aPAKE to necessarily include such step). All the instantiations discussed in the draft (HMQV, SIGMA, TLS 1.3) already provide or can be augmented to provide key confirmation.
115 |
116 | Q17: Can any recommendations on using iterated hashing (e.g., with Scrypt) with the PAKE be given?
117 | The OPAQUE draft touches on this issue (sections 2.1 and 3.4). The hardening operations are performed by the client. This has the advantage of freeing busy servers from doing this purposely-expensive operation. While most clients would have no difficulty in running such hardening operations, there may be legacy clients whose limited computational power may limit their ability to run a large number of iterations (or whatever operations the hardening scheme requires).
118 |
119 | Q18: Can any recommendations to avoid a user enumeration attack be given?
120 | Yes. The OPAQUE draft (Section 5) discusses this issue and mitigation measures in quite detail.
--------------------------------------------------------------------------------
/Reviews/YaronSheffer.html:
--------------------------------------------------------------------------------
1 |
3 |
4 |
5 |
6 |
7 |
8 | Review of the CFRG PAKE Proposals
9 |
10 |
375 |
376 |
377 |
378 |
379 |
380 |
381 |
382 |
383 |
384 |
385 |
386 |
387 |
388 |
389 |
390 |
391 |
392 |
393 |
394 |
395 |
396 |
397 |
398 |
399 |
400 |
401 |
402 |
403 |
404 |
405 |
406 |
407 |
408 |
409 |
410 |
411 |
412 |
413 |
414 |
415 |
416 |
417 |
418 |
Crypto Forum Research Group
419 |
Y. Sheffer
420 |
421 |
422 |
Internet-Draft
423 |
Intuit
424 |
425 |
426 |
Intended status: Informational
427 |
October 25, 2019
428 |
429 |
430 |
Expires: April 27, 2020
431 |
432 |
433 |
434 |
435 |
436 |
437 |
438 |
Review of the CFRG PAKE Proposals
439 | draft-sheffer-cfrg-pake-review
This draft consists of the author’s review of the password-authenticated key exchange (PAKE) protocols, as submitted to the IRTF’s CFRG. All opinions here are the author’s alone.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
445 |
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
446 |
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
447 |
This Internet-Draft will expire on April 27, 2020.
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
450 |
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
The CFRG took upon itself to review multiple proposed PAKE algorithms and select zero or more of them as suitable for general use in IETF protocols. Eight protocols were submitted for consideration, and they are listed on the CFRG GitHub repository: https://github.com/cfrg/pake-selection.
509 |
Over the last few months multiple reviews were submitted to the CFRG, evaluating the protocols’ cryptographic quality as well as their engineering properties. As the last stage of this process, members of the CFRG Crypto Review Panel were asked to provide summary reviews, and this document is the author’s contribution as a Panel member.
The author is not a cryptographer. Specifically, I do not have the skills to prove security of such protocols, nor even to evaluate the quality of such proofs. I do, however, possess a reasonable amount of experience in integrating cryptography into protocols, including PAKE-based algorithms [RFC6124][RFC6631].
CFRG has published in the past some protocols in enough detail that they can be implemented by a non-expert developer. A good example is [RFC7748]. Of the eight PAKE submissions, in my opinion only one comes close to this level of rigor. Whatever protocols are selected, CFRG must make it clear that such selection is conditional on the algorithms being republished in a detailed format. CFRG must not leave this task to the IETF working groups, because that would both duplicate work and introduce a major risk of inadvertent errors that invariably manifest themselves as vulnerabilities.
526 |
Ironically, I can quote the abstract of one of the submissions to support this position: “We observe that the original SPEKE specification is subtly different from those defined in the ISO/IEC 11770-4 and IEEE 1363.2 standards. We show that those differences have critical security implications by presenting two new attacks on SPEKE: an impersonation attack and a key-malleability attack.” In other words, an under-specified protocol resulted in two different standards, both of them vulnerable. This is ironic because the paper from which this is quoted is not itself a rigorous description of the protocol that it attempts to fix.
527 |
I would propose that each of the selected protocols be published as an RFC, containing:
528 |
529 |
530 |
531 |
A detailed description of the protocol, to a level that can be implemented by developers who are not security experts.
532 |
Test vectors to ensure interoperability.
533 |
Recommendations on integrating with higher-level protocols: supported identity fields and recommendations on how they should be protected, session ID and “exporter” integration, secure capability and parameter negotiation, conditions on whether and how “optional” protocol exchanges can be eliminated.
534 |
Mandated auxiliary primitives, such as hash-to-curve and memory-hard iterated hashing.
The IPsec/IKE community has always been interested in PAKE as a component, both for remote access and for peer-to-peer VPN deployments. This to me justifies the selection of both a balanced and an augmented PAKE, assuming good candidates exist. It also means that the integration of such protocols into IKEv2 is relatively straightforward.
540 |
On the other hand, the TLS community has been less receptive to PAKE solutions, and as a result, the properties required from the protocol for proper integration are not as clear. It is possible that the most common deployment will be a combination of TLS, PAKE and OAuth. Arguably we should take the combination into account when defining the PAKE portion of the protocol, and resist the temptation to only consider the narrow integration of a PAKE protocol into TLS 1.3.
This protocol is the best documented of all the candidates. On the down side, it relies on a set of parameters that present a high value target for factorization once a quantum computer is available to an adversary, and that would break all instances of this protocol.
This algorithm is an outlier in its complexity, which also implies a significant performance penalty. For this reason I don’t think it would be a realistic selection.
SPEKE has been around for a long time, which is an advantage. But the quoted paper describes several attacks on concrete specifications/implementations, and Karthik’s review casts doubts about the validity of the security proof presented for this protocol. As far as I can tell, the mailing list discussion has not fully clarified which exact version of the protocol is proposed and which published security proof applies to it. Specifically, does [Hao2018] apply?
CPace is not specified as a stand-alone protocol, but rather needs to be extracted out of the AuCPace specification. Moreover, it adds a mandatory (though trivial) message round to establish a session ID. This extra round may or may not be subsumed by the higher-level protocol. Having said that, it comes with an actual security proof and no magic parameters.
OPAQUE is described as a generic framework, with two instantiations, and will have to be narrowed down when standardized. The protocol is secure against pre-computation attacks. This is a good thing of course, however I am not sure how serious this attack is in practice: while servers are often breached with attackers gaining bulk access to hashed passwords, I don’t think it is common for attackers to record multiple salt exchanges and use them in a follow-on attack. OPAQUE comes with a security proof. OPAQUE is well documented, with a separate draft [I-D.sullivan-tls-opaque] on its integration into TLS.
The protocol has two versions, the main paper and Appendix C (“Strong AuCPace”), which is resistant to pre-computation attacks. It is unclear which one is nominated.
This 2017 paper extends SPEKE into a balanced PEKE that can be proven even for elliptic curves, and then again into a verifier-based (i.e., augmented) PAKE named VTBPEKE. It has a few “magic” constants which are potentially of concern - I didn’t see any mention of how they should be generated.
This protocol is somewhat loosely specified, with no security proof (or even security justification/intuition) provided. So it is hard to be convinced of its fit for purpose.
As noted, I think the Research Group should recommend one balanced and one augmented algorithm.
587 |
Before presenting my conclusions, I would like to clarify my view about quantum resistance in this context. Steve Thomas defines “quantum annoying” as: an attacker with a quantum computer needs to solve a DLP per password guess. IMO this is too high of a bar, and once we get to the point where this is a real risk we will need to migrate to PQC for these protocols. However I think that even now, a protocol where a single DLP solve would break all instances of the protocol, is too risky to adopt.
588 |
Of the balanced algorithms, I would recommend CPace. I think the extra round trip is a reasonable price to pay for a formally proven protocol. To me the potential quantum vulnerability of the SPAKE2 parameters is a showstopper.
589 |
Of the augmented algorithms, I will follow the Mozilla report and recommend OPAQUE, which appears to be the best fit into TLS, and is also a good fit into IKEv2.