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

[Brian Warner <[e-mail]>]

On 9/16/19 5:51 AM, Hao, Feng wrote:

> [FH] If you set the two blinding factors equal (M=N), that will effectively turn it into a different protocol, which is very similar to Kobara-Imai's Pretty-Simple Password-Authenticated Key Exchange at https://eprint.iacr.org/2003/038.

Thank you! I've been looking for literature about the M==N case without
success. I'll read that paper.

In my SPAKE2 variant, I include a check that the inbound message is not
the same as the outbound message, but I'm not sure how effective that is
at preventing the reflection attack (i.e. I compare bytes, but maybe the
attacker could transform the outbound message into a different
representation of the same point, which would pass the check but still
result in one side unknowingly talking to themselves).

>     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.
> 
> [FH] In J-PAKE, the identities are used as the basis for each communicating party to retrieve the shared password. Hence, a party can use an arbitrary identity as long as when the two parties engage in a PAKE session, they know which shared password to retrieve from their respective databases. This should be the same for all PAKEs. I don't think you can remove the check that the two identities in a session should be different (which is a natural thing to check, and necessary to prevent the ZKP being replayed back to the sender).

Got it. So I think for J-PAKE (and several of the others), I *must* find
a way to agree upon (different) identities ahead of time. The identities
could be random and ephemeral, but they must be different.

I will take a another look at each candidate and see if the peer's
identity must be known before the first outgoing message is generated.
If not, Magic-Wormhole could just use random ones without incurring an
extra roundtrip.

For SPAKE2, I could even imagine setting M=hash_to_point(randomIdA) and
N=hash_to_point(randomIdB), using new values for each session, and just
including the ID in the first message. I think that would get me back to
the original protocol, without adding a roundtrip, at the cost of
requiring the hash_to_point() function at runtime.

thanks,
 -Brian