I was looking for a means to perform a key exchange without relying on a PKI. I discovered Password Authenticated Key Exchange (PAKE) and after reading J-PAKE; I have the following questions:
- Do PAKE assumes that involved parties already have a shared message?
Some do, some don't. In general, there are two flavors of PAKEs; balanced (where both sides do know the password), and augmented (where only one side knows the password; the other side knows enough to recognize it).
J-PAKE is a balanced PAKE.
- in J-PAKE, they used an extension of Diffie-Hellman Key agreement to establish the shared message. However, I don't understand how they prevent Man-in-the-Middle attacks.
Going through it thoroughly would require going through a set of cases; however here's a nutshell: each side expects to receive (in successive messages) proof of knowledge of $x_2$ and $x_2 \cdot S$ (or $x_4$ and $x_4 \cdot S$); the MITM cannot fake both of those (without knowing $S$), and so those have to be forwarded untampered. The adversary is them limited with tampering with $x_1$ and $x_3$; we can show that that doesn't give him an advantage either.
In general, how does PAKE prevent Man-in-the-Middle attacks?
Well, with all PAKEs, if the attacker has a correct guess to the password, they can do MITM attacks or impersonation attacks (and because the password really is the only way the protocol has to perform authentication, we can't do better). What a PAKE does try to do is make sure that the attacker is forced to test only one password per attempt (either MITM or impersonation); if he wants to test ten passwords, he needs to interact with a legitimate party ten times (for example, MITM ten separate exchanges).
How they to that varies, of course. J-PAKE relies heavily on its proofs of knowledge; EKE encrypts the Diffie-Hellman keyshares (so that a MITM would need to guess a specific password for an attempt to work); CPACE uses a password-dependent DH base value (again, so you need to guess a specific password for an attempt to work); OPAQUE has the client and server do a multiparty computation on secrets that the client and the server has for the client to rederive the key needed to recover the private signature values (and the multiparty computation messages look completely random to a MITM).
It's fine that you're studying J-PAKE; just realize that other PAKEs work rather differently...
