[Cfrg] Review of PAKE protocols (for Magic-Wormhole)

Brian Warner <warner@lothar.com> Mon, 16 September 2019 05:59 UTC

Return-Path: <warner@lothar.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43E311200F7 for <cfrg@ietfa.amsl.com>; Sun, 15 Sep 2019 22:59:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y1FNDLtZwoiF for <cfrg@ietfa.amsl.com>; Sun, 15 Sep 2019 22:58:59 -0700 (PDT)
Received: from smtp.lothar.com (smtp.lothar.com [204.246.122.77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE5E81200B8 for <cfrg@irtf.org>; Sun, 15 Sep 2019 22:58:58 -0700 (PDT)
Received: from [10.0.2.174] (99-124-154-248.lightspeed.sntcca.sbcglobal.net [99.124.154.248]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: warner) by smtp.lothar.com (Postfix) with ESMTPSA id 4D4DF78118 for <cfrg@irtf.org>; Sun, 15 Sep 2019 22:58:55 -0700 (PDT)
To: cfrg@irtf.org
From: Brian Warner <warner@lothar.com>
Openpgp: preference=signencrypt
Autocrypt: addr=warner@lothar.com; prefer-encrypt=mutual; keydata= mQINBFNK1VsBEADMrGiCKsx/d0bO13WpMb1xNDTiGs/cCBZK7vRUqZFCfApBrcmjBtnW9F0K PHY71ys9fJYV+YGX3Z/zX9+OIo5ssGdX5Uas46wDci7LHFwdbBBV6pyZep3yJlaTRUf/D4F3 9niXSTXPIMDlaP4RmyycbrortvaF5/X5EMXS6/KvakRsBygftqzqx6nAkqMPPsY6ouuLk9g1 zSu9tByT7hqzIsbKyFO/3fhVNy8Y03PY8eC0kr9mZ3+BonKu8Vp+f0mp9zCaunby8A5ci9ba By+b0JZATZlAPpQLLkz+pettwPNSC87o1xuxs7WTwlgnH9H8eRK/qSbR9rlRmjxK+ufsi5qs E/WZI0jc51OI26WDQnpvXSqluCAZ/Ge5BoPYcf9KmBNF3MJlEfdhM2iXYatNlwxJP00uAuWi ds00ZZBFxy4l2/ITVoLSZemQtlcj1j8Rh7969fIVM7gAgp9KFaLusq5WEwrIVAbV2zk5v5T+ ISJ4MtFyrKF9de7bQnJlcTJcnUvV1EcFlmkVR/METXvEt7fhPeYIq9OIRQAGaUIREsP22lhr E5v077QLiXCoc6hSMl5iDQk2YYYZ0i71vIt4ULru2yrSWRbjy/ukvfy3clAeb9RzVhz2kNnh KvQxLPStJkjm5fY4HzQSFKBhEANsFFyaWXdLGNg7fTLR6rEbQQARAQABtChCcmlhbiBXYXJu ZXIgKGVtYWlsKSA8d2FybmVyQGxvdGhhci5jb20+iQI4BBMBAgAiBQJTStVbAhsDBgsJCAcD AgYVCAIJCgsEFgIDAQIeAQIXgAAKCRADhugbEcqgejEBD/0di4Y4OrD94WaUvTkp0D1+DkRY souttQ6TfBp5gfsBVkR2lkIjDK3gJwAeIu9QxkIiV8RjTRI8SKLat8XcW1keLALBYo6Gt0ip UumUHHa+graskB2rRqb/PnXeZcaDFks2uDB5j5oy4Rn2IS/P9TG81GpXNfpzCOJPpdgH9+fE Sj3OyB4+/oV4KsEk0r8k23BEWPjlw1boemZBQLJg6YveIDgWJQ2FxXrHzF+cg2tQQFpPMEc/ pU27mnquLqs8kmYTHmVlGYfw4tSg8VZng0f2QuRLN/lgHpESnzVNIk+lY0z4ckgTWMTUHjj+ bhh6SEfE7I6LDNntyKjHXa/m11RhOaM/Z7bjbKAyOeJlqA0/SUOti6T8RrFNKKvr+UiBz0Ws ZYc74AQvwddty45EQsxsBNoq8OKWkNmE8vylkYdLcExJ6vzHkWLzzQDawxPdP8qm1LaxrIYh bD4m5CZvc9ZvsfAI3Kemo8omWyEsXBR4y1wI4VVCkbZnmzo1M9p1tLjx/VAcm9aQqOgJ+X3Z 2+S2cNDoQagr6+dknLVqo2dZ98MvzbS/t1/K/QWelGI0xY7xyWjHvLcb9SR3c3JSQDTY9hTJ NNq5yv/hakdqwanbiAjOFs0fErViuTrXeTpwrz0TdSY90bZf4c0muoNswWLXgfnaSg/cnTNh w4uP+rMsQ7kCDQRTStVbARAAx7GYFLqau7Nx+hZUL7pq39XsV+JvAt0kgyy20RwuwqkOb30/ Ra2LkJkqBLU7/EicJ5nE66KwsSdoloehv2Hc8XPb5lynbshfjMCbPYnnNekWzI8wyqtEB9tt AOs+44phnSWjP/Z8xWT2BDLKuEWvKkOU+AldY8s9K1nzy71HW0rxnsYqBUBj4KTlKU/q98S5 piiiEZjMHt8sqL7Q98axMVhpWahUoAVzYs8ksbJslP9UH7QAMAt1eqU41oJXk2hZIvpY3eaQ K4ic3fhfE/Dd/ex3sSiAjI5YcC2sVAFBSNeJxDOLN0giC7aXeAaUEi1LkXP8wLUcFtljP+Gf FpVbJUCLd2mKwzKVfBJcE/9k1rQlNGgP9X5YtOdcRodk3PfzIQ2btpOes585UsG/fS62ayu2 nJt4vWIqWd0q1eCD3FyaPO/a5wM16QGDiPDmZnrKNdy7B0lzcjl3iaaFYgBD19JA7ETpLFpL 1r6jWP5wm/EcFGrESKvRV7iGLq6bV4tJTu0f6faj7AyODf1JnXLOtE4Aeld7FSHqUUqA8ijn UG1+YjEnvfZsi1pYzty2tlO4GdSQftmyEGh43VGzl1S6OFbOcQ4NUHasLCDnVtaPDLgAbgAj HNfMWJrXMaie/Dtwgvz+G4SkdaMxb0RxvFIRsrDcJrdmDEaPHVdYXT8AWvEAEQEAAYkCHwQY AQIACQUCU0rVWwIbDAAKCRADhugbEcqgepcJD/9DWVNiLB31+HYbwSd3XMH/kejR4EnsT8R/ dC/esadiHza4xSQbiXPmk0t9N5VHlcp4I7gI0P/AKnshZJmZL3QTPUBy9QX7caJu+vOHJHot u9p4zwS/FHUwVqZV7W5UpYyPAkRngIEDubYGLcknxzgyaBHULPs247U5X1X5te6LJ0QgXJAd qvnIoH23puKbPF7AWkmyF4nhEnXEfopUndsnDupM+RoFpZ6nIt6cogFzhvQxgqk5Ejti9Vw3 6RjtpJ5QI0NXVi31YfnOJASsW+85SHxq25bXhgszHT5pB0DoJBJwjrphFgIqe400BnTz3CGe SQhK5T0Cq6maxq3Z8Fez70/CvDdrrGqI3K41Zvzd0d067iGiNYMgeLvB2tavQMW+wsxbHEL0 ZzK2nQfW5YRsVBnU+qgZ+G7u3K2DuNhMVsKwYwQJucltRO4JZIrFLI5PxWhKXyH7+4gdMulx 4GOhfq/33dsvW4meP4w+TTCbz6ZU2Ub2OuJ7bboQTqTDkj8EdpH34xcy0rOlhavuaxq82k/P VdmkDDNOWEJITQHZ+hPNw0YfKnzqsiQT0K0e0azq35toIGI0dkGZB6/KuGhDNCIHt80M23+0 bqDpP4RIcl8nbFrBD2yvEGyL9n1Lu6Z6M0Iav4dWUkkjP4Ghpohm8dun+oQrFCi3Dqe3H09B bQ==
Message-ID: <de0d0cae-72ba-3b8c-627c-ab6b555cbdad@lothar.com>
Date: Sun, 15 Sep 2019 22:58:54 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/BBQ2gwCECu5ouTJjE_CE6d9Rg-0>
Subject: [Cfrg] Review of PAKE protocols (for Magic-Wormhole)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Sep 2019 05:59:03 -0000

I was asked to review the balanced PAKE proposals, with an eye towards
their suitability for my "Magic Wormhole" application. Here is my
report.

First, some background on my use case. Magic Wormhole
(http://magic-wormhole.io) is a PAKE-based provisioning library and
file-transfer application. As a library, it helps two humans introduce
their computers to each other securely, for example to exchange
long-term public keys for a private chat application (think Signal or
Wire), or to provision a mobile client for some service from an existing
desktop client. As an application, it provides a command-line tool for
sending a file, directory, or short message, by having the sender
dictate a random single-use "wormhole code" like "4-purple-sausages" to
the receiver. The sending human runs "wormhole send FILENAME" which
prints out the code, and the receiving human runs "wormhole receive" and
types in the code. The numeric part of the code is used to access a
"mailbox" on a shared central server, and the words are used as the PAKE
secret. The PAKE messages are pushed to the mailbox, where they can be
read by the other side to continue the protocol. My implementation uses
SPAKE2 over an Ed25519 group to derive a secret shared session key, and
then encrypts everything else under that key. Small messages are
encrypted and sent through the mailbox server. For large transfers, the
two sides use the mailbox channel to negotiate a direct TCP connection,
and derive a separate key to protect that connection.

This leverages an existing low-bandwidth short-term secure-enough
channel between the two humans, such as two people standing next to each
other, or talking on the phone. They might have a secure high-bandwidth
channel already, but one that is ill-suited for transferring files (I
constantly wormhole files from the other end of an ssh connection,
because it's easier than remembering and re-typing whatever directory
I'm using into a new "scp" command). Or they might have a channel that
isn't exactly secure (SMS, IRC, twitter direct messages) but the
attacker's temporal window is narrow.

Magic-Wormhole was inspired by my work at Mozilla on Firefox Sync in
2010, for which I was the proponent of using J-PAKE in a similar scheme
to transfer one browser's local-data encryption key to a new browser.
Sync encrypts all bookmarks, open tabs, history, and password manager
entries with this local key before uploading the ciphertext, so the
Mozilla servers cannot read this data, and we used a randomly-generated
transfer code to get this key from one machine to another when the user
attaches a new browser to their account. J-PAKE was the first PAKE I had
ever heard about. After we implemented the system, I had an opportunity
to speak with Dan Boneh, who recommended SPAKE2 (known as "PAKE2" in his
https://toc.cryptobook.us/) over J-PAKE, hence its use in
Magic-Wormhole.

In 2014, I built the protocol which replaced PAKE in Firefox Sync. I
presented our reasons for abandoning PAKE at Real World Cryptography
2014, with details at http://www.lothar.com/presentations/fxa-rwc2014/ ,
but in short we failed to provide an adequate user experience for a
purely transfer-based protection mechanism: users wanted to recover
their data with a password, even after their last browser key had been
lost, and our approach could not make that easy.

## Review Criteria

I'm not a cryptographer, and I'm not qualified to evaluate proofs of the
various candidate algorithms. My review criteria are related to how well
the protocols fit the needs of my application, and how well I think I
(or some other self-taught cryptographic engineer) could implement them
safely. In particular, my goals are:

* minimize round trips
* avoid "sidedness" which requires symmetry-breaking additions
* minimize complexity for the implementor
* maximize concreteness of the specification

All applications want to reduce roundtrips. For Magic-Wormhole, the
worst case is to be deployed as a secure-messaging introduction step
between a pair of laptops or mobile phones, that spend most of their
lives asleep. The clients will get network connectivity only briefly,
while the phone application is running, or when the laptop is open. The
two clients may never be online at the same time, so each time the app
is activated, it might only be able to fetch one message, and submit one
new message. The number of roundtrips the PAKE protocol requires tells
you the number of wake-up-the-laptop cycles it takes to compete the
introduction. For two users in different timezones who only open the app
during lunchtime, each roundtrip could take a full day.

Magic-Wormhole has an "offline codes" mode, in which the two humans meet
without their computers, and decide upon a secret code manually (perhaps
by rolling dice, or counting passing birds, or something). Then they
return to their computers, and each type in the shared code. We don't
know which person will type in their code first, and a symmetric
application protocol (like populating address books in a messaging
program) doesn't give us any automatic way to distinguish one side from
the other. So a PAKE protocol with "sides" (like SPAKE2, or any
augmented PAKE) is slightly awkward. We need some other mechanism to
break the symmetry: an exchange of random numbers (higher number plays
Alice, lower number plays Bob). This either costs an extra roundtrip, or
requires both parties run two copies of the protocol in parallel, and
throw one of them out after they learn which role they should play
(https://github.com/warner/magic-wormhole/issues/348, 3rd comment).

Lacking a well-specified off-the-shelf library in my preferred language,
I had to implement it myself. Minimal complexity helped. I could
tolerate a more complex protocol if someone else writes the
implementation (at Mozilla we had Brian Smith to write our J-PAKE code;
I would have been lost trying to write that myself, and even he missed
some important checks the first time through).

While writing the Python SPAKE2 implementation, I lacked a byte-level
specification to match. This was terrifying. There are plenty of options
that must be settled (choice of curve, point representation, transcript
representation, transcript hash). Most aren't significant for security,
but are vital for compatibility, and I did not know which of my casual
"works for me" choices would become difficult, annoying, or embarrassing
in an actual spec. There are now four somewhat-compatible
implementations (Python, Rust, Go, and Haskell), and each had to match
my perhaps-idiosyncratic choices. The string-to-(unknown-dlog)-point
function was the worst.

My non-goals are:

* augmentation or password-stretching
* identity binding
* timing-channel resistance
* message size, within reason, or super high performance
* well-defined key-confirmation messages

Unlike passwords, the "wormhole codes" we use are randomly-generated and
single-use. The distribution of possible codes is uniform. An attacker
who successfully managed to guess a single code early enough could
intercept the data transferred during that one operation (via an active
MitM attack), but that gives them no advantage over the next transfer.
The wormhole code is used as the PAKE password, but it is not stored
anywhere, and is discarded as soon as the session key is generated.
Consequently I have no need for an Augmented PAKE, and in fact the
additional setup step these require would make my protocol completely
unworkable. And since the code/password is not stored anywhere, I do not
need a mechanism to slow down online guessing attacks, or to protect
against "server" compromise by storing something other than the
password.

Magic-Wormhole has no notion of "identity": each instance of the
protocol is driven by two humans introducing their computers to each
other. The wormhole code is the only identifier: Computer A generates
it, the humans transcribe it, and Computer B accepts it. Computer A only
knows about the human that reads the codes it displays. Computer B only
knows about the human who controls the keyboard over which codes are
entered. So the protocol has no need for features which bind a server
name, or account name, into the generated key.

Constant time operation is always better, but I think Magic-Wormhole is
less threatened by timing attacks than other protocols which might use
long-lived passwords. Each client performs the PAKE computations just
once for any particular wormhole code, and many of those computations
take place before any messages are sent, limiting an attackers potential
observations. My current implementation uses a pure-python Ed25519
library, which is not constant-time at all.

Magic-Wormhole protocol messages are delivered over WebSockets to the
mailbox server, which enables more portability (to different languages,
operating systems, and potentially even web-browser -based clients). As
a result, we are not particularly sensitive to the size of the messages,
and they certainly don't need to fit in a single ethernet frame. I very
much prefer ECC groups over integer/MODP ones, but the protocol would
not suffer terrible inefficiencies even if the messages were several
kilobytes in length. The protocol assumes human interaction (and it
wouldn't make much sense to automate it: if you have two computers that
can securely exchange the wormhole code, then you already have a secure
channel for everything else). So the rate of execution is limited to
human conversation speeds.

Most of the CPU time spent in the PAKE operations is on the "long pole"
of user experience, so keeping it reasonable is helpful. However the
majority of the time is spent waiting for a human to transcribe a
wormhole code, and connections are initiated by humans, not machine, so
100ms or even 500ms might not be a problem. The PAKE operations are only
computed on the two client machines (the server relays the messages but
does not interpret or generate them), so there is no
multiplication/bottleneck factor to worry about.

Many PAKE use-cases are about proving control over an account to
authorize some action (i.e. establish a TLS connection, then run PAKE
inside it to demonstrate knowledge of a password, creating a login
protocol that's better than plaintext-password-inside-TLS but still
vulnerable to CA compromise). Magic-Wormhole starts with PAKE and
creates the connection from that. Consequently, "key verification" is
expressed by using the PAKE-derived session key as a transport
encryption key (AEAD or just AE) for the subsequent tunnel. The receipt
of the first message inside this tunnel is the indication that PAKE
succeeded, and the failure of a MAC on the AE cipher is indication that
it failed (or an attacker has injected a message into the transport
layer, which is another kind of failure).

So my protocol doesn't have much use for a specification of how
key-verification steps should work (i.e. "send H(H(key)) in one
direction, wait for it to arrive, then send H(key) back"). These steps
assume that the success of the PAKE exchange is interesting by itself,
whereas I believe the correct thing to care about is the session key
alone, and its binding to subsequent messages. Learning that PAKE
succeeded without actually using the session key is like learning the
user's plaintext password was correct without binding it to the channel.
An attacker who uses a fake/compromised CA certificate to fool the end
user into connecting to the attacker, rather than the real server, can
run an MitM attack (sitting in between the user's TLS connection to the
attacker, and a separate TLS connection from the attacker to the
server), forward the PAKE handshake until completion, then drop the
user's connection and impersonate them to the server. This is the same
problem as sending plaintext passwords over TLS, except the attacker
doesn't learn the password to make it easier to impersonate them again
in the future.

## Minimizing roundtrips

J-PAKE and CPace require two pairs of messages to be exchanged before a
shared key is available. In contrast, SPAKE2 and SPEKE need only one.

In the worst-case never-simultaneous execution scenario described
earlier, with SPAKE2 and SPEKE, Magic-Wormhole would require five
activations to get one secure message from A to B and from B to A with
acks of both (i.e. Alice runs, then Bob, then Alice, then Bob, then
Alice). For J-PAKE and CPace, this would require seven activations.

This depends upon what exactly is used as a UserID, how the symmetry is
broken (see below), and whether key confirmation is verified before
sending a payload. But in general, the extra commitments of J-PAKE and
the session ID agreement of CPace induce an extra pair of messages.
While this non-simultaneous scenario might not be the most common, I'd
still prefer a protocol that needs fewer roundtrips.

Good: SPAKE2, SPEKE
Bad: J-PAKE, CPace

## Avoiding asymmetry

SPAKE2 was the second PAKE function I ever learned about. I decided to
use a symmetric form of it, in which the two blinding factors are set
equal to each other, which I'm told is probably safe but would prefer to
replace with something proven. As described above, I know how to work
around this without incurring an extra roundtrip, but it'd be better if
I didn't have to.

J-PAKE includes a UserID in the NIZKs, and RFC8236 says the verifier
shall check that it differs from their own identity (presumably to
defend against reflection). To achieve my symmetry goals, I would want
these UserIDs to be constant for all users (removing that check), and I
don't know if this breaks the security properties.

SPEKE, as described in "SPEKE Protocol Revisited" paper, appears to
value symmetry in the way needed for Magic-Wormhole. However it is not
clear to me what exactly would be included in a specification based on
the recommendations therein. The "alternative solution" in section
5.3(2), namely s=H(pw+Min(idA,idB)+Min(idA,idB)), would be ideal, as my
protocol could simply leave idA/idB empty. I don't see anything that
suggests SPEKE implementations would have to explicitly check user IDs,
which sounds good for Magic-Wormhole.

The CPace "ssid agreement step" is defined as hashing 's' and 't' in a
particular order that implies an asymmetry, but I believe this could be
replaced by sorting the two contributions without affecting security. If
that is true, perhaps the spec could be updated to remove an unnecessary
asymmetry.

CPace is defined with UserIDs that are folded into the ephemeral
generator (figure 5, g' = H1(sid+Pi+Pj+pw). Again, these would need to
both be empty or the same constant value, to obtain the symmetry I'm
looking for. I don't see any protocol steps that require checking for
distinct identities.

Good: SPEKE, maybe CPace
Maybe Bad: J-PAKE
Bad: SPAKE2

## Minimzing Complexity, Maximizing Concreteness

To this amateur implementor, SPAKE2 is the simplest of the candidates
(assuming ECC rather than MODP). It took me a while to get code that
performs both scalar multiplication and point addition in the Ed25519
group (starting from djb's papers and the code in NaCl), but everything
else about SPAKE2 is straightforward (to me).

SPEKE is similar, assuming a well-defined hash-to-curve rule. I could
probably implement it. I know this is the nature of cryptographic papers
(as opposed to proper specifications), but it felt like the SPEKE papers
were more of a collection of good ideas, rather than instructions for
building a protocol. I have to imagine specification that might result
from following those recommendations, and hope that this hypothetical
complete spec might include things like ECC and hashing a full
transcript of the conversation. SPEKE was written a while ago, when
perhaps protocols were more casual about mixing scalars and group
elements (something that always bothered me about SRP), specifically in
the password-to-generator function. Having a clearer distinction between
scalars and elements in the SPAKE2 definitions made it easier for me to
understand.

CPace feels very much like what SPEKE would be in an ECC group, except
with the extra pass to agree on a session ID. Again, assuming
hash-to-curve being specified, I could imagine implementing it.

J-PAKE feels like the most complex of the candidates. Each message must
include zero-knowledge proofs along with the normal DH parameters. As an
amateur implementor, this is a level of complexity I would rather avoid.
I think I understand the basic group math involved in all the other
protocols (SPAKE2 is just DH with blinding applied to the ephemeral
keys, SPEKE is DH with a secret generator derived from the password, and
CPace is the same but with a roundtrip to salt the password with a fresh
session ID). But J-PAKE's multiple scalars don't map to my understanding
of DH, and the correctness of a ZKP construction is slightly beyond me,
so I'd feel far more comfortable implementing one of the others. That
said, if someone else is writing the code, I could tolerate more
complexity.

Most of these protocols (but not J-PAKE) require a function to convert a
string (the password, plus maybe other stuff) into a group element for
which nobody knows the discrete log. SPAKE2 uses it for the shared
blinding factors, CPace needs it each time to build the secret shared
generator, and SPEKE would need one if it were defined over a
non-integer group. This requires some extra specification, and
frequently gets left up to the implementor, resuting in
incompatibilities. I'm hopeful that the final specification will define
this function clearly so implementations will be compatible.

SPAKE2 only needs this function to be run once, during the specification
process. When I implemented SPAKE2 in python for magic-wormhole, I
picked an approach that seemed natural, but subsequent implementations
by other people (e.g. the SPAKE2 patch for SJCL) chose other approaches
that were not compatible. However if my approach was sound, those other
implementations could simply copy the value directly rather than
re-implementing the full function. The appearance of a large magic
number in a protocol implementation is not very satisfying, nor in a
protocol specification document, and both ask the reader to manually
verify that the number was generated in the claimed way.

Good (complexity): SPAKE2, SPEKE, CPace
Bad: J-PAKE

Good (string-to-point): J-PAKE
Somewhat Bad: SPAKE2
Bad: SPEKE (ECC), CPace


## Conclusions

It's a mixed bag. For Magic-Wormhole, I still prefer SPAKE2. I can
imagine an ECC-based SPEKE specification that could work. I'm reluctant
to take on the extra roundtrips of J-PAKE or CPace, or the NIZK
complexity of J-PAKE, but if someone convinced me that they were more
secure (and published test vectors for the ZK proofs), I could imagine
implementing them.

My ideal construction would probably be "SPAKE2 Elligator Edition", in
which the blinding factor is just the Elligator2 mapping of the
password. This would be symmetric, one-round-trip, and pretty simple (of
course by pushing the complexity into somebody else's Elligator
implementation). It's conceivable that one of the candidates, when
implemented over an Elligator-capable curve, could look like this.

I hope my use case helps the group with the selection process. My
apologies if I've misunderstood any of the candidates or was unfair in
my assessment. Please let me know if I've committed such errors and I'll
endeavor to update my review.

cheers,
 -Brian