[Crypto-panel] Stage 5 of PAKE selection process

[Russ Housley <[e-mail]>]

Reviewer: Russ Housley
Review Date: 24 October 2019

CFRG is looking for a PAKE to support TLS 1.3 and IKEv2.  TLS 1.3 has
a very rigid handshake in terms of the number of messages that are
exchanged.  IKEv2 has mechanisms to accomodate the exchange os many
messages as part of authentication.  As a result, I focus on TLS 1.3.
Any PAKE that will work with TLS 1.3 will also work with IKEv2.

RECOMMENDATION: OPAQUE


Observations about each of the candidates follow.


J-PAKE

J-PAKE requires significant computation, even when elliptic curve is
used.

J-PAKE has big messages, even when elliptic curve is used.

J-PAKE is a two round (or three round) protocol, so it does not easily
fit into the TLS handshake.


CPace

CPAKE requires two elliptic curve operations by each party, one to
compute an ephemeral public value from the ephemeral random (private)
value and one to compute the shared secret.

CPake requires the pre-establishment of an session identifier (sid).
Perhaps this is done when the password is established, but the
requirements are not clear to me.  The sid is sent by both the initiator
and the responder.  Assuming the sid is not bigger than an ephemeral
public value, the message sizes seem reasonable.

CPAKE is a one round protocol, so it easily fits into the TLS handshake.

CPake requires a check that the "point order is sufficient for
security parameter 2k".  I could not figure out the check to be
performed.  Maybe I did not spend enough time searching for it ...


AuCPace

AuCPAKE requires two elliptic curve operations by each party, one to
compute an ephemeral public value from the ephemeral random (private)
value and one to compute the shared secret.

AuCPake requires the pre-establishment of an session identifier (sid).
Perhaps this is done when the password is established, but the
requirements are not clear to me.  It also requires a sub-session
identifier (ssid) that can be a concatenation of the nonces from the
TLS handshake or computed from them.  Assuming the sid is not bigger
than an ephemeral public value, the message sizes seem reasonable.

AuCPAKE requires more than one round trip, so it does not easily fits
into the TLS handshake.

AuCPake requires a check that the "point order is sufficient for
security parameter 2k".  I could not figure out the check to be
performed.  Maybe I did not spend enough time searching for it ...


OPAQUE

OPAQUE computational cost is determined by OPRF, Diffie-Hellman, and
authentication.  The OPRF requires two elliptic curve operations for the
client and one for the server.  The Diffie-Hellman requires two elliptic
curve operations for each party.  If authentication uses signature, then
each party will have to generate and verify one signature.

OPAQUE requires two private key operations by each party during
registration, and then just one private key operation by each party
to compute the shared secret.

OPAQUE is a one round protocol; it easily fits into the TLS handshake.

If one is willing to employ an extra round trip, OPAQUE can provide
confidentiality of the user's name by encrypting it in the TLS
handshake key.  It seems like this could be implemented as TLS-in-TLS.

OPAQUE needs an AEAD that includes "key committing".  AES-GCM mode does
not provide this property, but I think that AES-KEY-WRAP mode does.  It
seems straightforward to enhance an AEAD to get this property by adding
a all-zero block to the plaintext and checking it on decryption.


SPAKE2

SPAKE2 computational cost is four elliptic curve operations for each
party after the pre-provisioning takes place.

SPAKE2 is a two round protocol, but the pre-provisioning will take place
prior to any handshake, so it easily fits into the TLS handshake.  That
said, if the point associated with the system-wide elements M and N
become known, then an offline dictionary attack becomes possible.

I found this part odd:

           TT = len(A) || A || len(B) || B || len(S) || S
             || len(T) || T || len(K) || K || len(w) || w

   If an identity is absent, it is omitted from the transcript entirely.

So, if A or B is absent, the inputs quite similar:

           TT = len(B) || B || len(S) || S || len(T) || T
             || len(K) || K || len(w) || w

           TT = len(A) || A || len(S) || S || len(T) || T
             || len(K) || K || len(w) || w

Somehow, using a zero length for the missing identity seems safer:

           TT = len(nil)    || len(B) || B || len(S) || S
             || len(T) || T || len(K) || K || len(w) || w

           TT = len(A) || A || len(nil)    || len(S) || S
             || len(T) || T || len(K) || K || len(w) || w


SPEKE

SPEKE computational cost is two elliptic curve operations for each
party.

SPEKE is a one round protocol, so it easily fits into the TLS
handshake.  Also, the TLS 1.3 Finished message provides the
optional key confirmation.  Finally, identity and session-unique
values are easily accommodated by the client and server Hello
messages.


VTBPEKE

VTBPEKE computational cost is four elliptic curve operations for each
party.

VTBPEKE is not a one round protocol, cannot be accommodated by the
TLS 1.3 handshake.

VTBPEKE offers forward secrecy.  However, if the points associated with
the system-wide element U and V become known, then an offline dictionary
attack becomes possible.


BSPAKE

BSPAKE computational cost is five elliptic curve operations for the
client and four elliptic curve operations for the server.

BSPAKE requires two-round trips in the protocol, so it cannot be
accommodated by the TLS 1.3 handshake.