My intuition for the security a symmetric PAKE is supposed to provide comes from the example of a login page. Both the user and the server know the password (assuming unhashed passwords), and the purpose of the protocol is to authenticate both the user and the server to each other using this fact, while simultaneously generating a session key known only to them and avoiding any man-in-the-middle attacks. Specifically, I thought that one of the key properties of a PAKE is that the user and the server would get different keys if they provide different passwords, so a malicious party attempting to log in would be thwarted if it does not know the password. However, this does not seem to be the case according to the security definition.

The standard UC functionality for symmetric PAKE comes from Canetti et al.

Symmetric PAKE ideal functionality

Notice (top bullet under the $\textsf{NewKey}$ query) that if one of the parties is corrupted then the adversary gets to choose the session key $sk$, regardless of whether the two parties provided the same password. By using two queries to $\textsf{NewKey}$, the adversary can set both parties' session keys to be the same. Why would the definition be chosen to allow this? If the passwords differ, the functionality could instead have been written to give the adversary the power to choose only the compromised party's key, and not the honest party's key.


The paper contains text that explains why this is OK. I quote:

The main idea behind the FKE functionality is as follows: If both participating parties are not corrupted, then they receive the same uniformly-distributed session key, and the adversary learns nothing about the key except that it was generated. However, if one of the parties is corrupted, then the adversary is given the power to fully determine the session key. The rationale for this is that the aim of key exchange is to enable honest parties to generate a key that is unknown to an external adversary. If one of the participating parties is corrupted, then the adversary will learn the generated key (because it is one of the participants), and so the security requirement is meaningless. In such a case, there is nothing lost by allowing the adversary to determine the key.

However, from your question, I think I understand what you are worried about. If the adversary $P_k$ can set the value of its key with $P_i$ and with $P_j$ then it could seemingly behave like a man-in-the-middle between $P_i$ and $P_j$. However, this is not the case. Specifically, $P_i$ knows that its key with $P_k$ is $sk$, and when communicating with this key, it knows that the communication is with $P_k$ and not with $P_j$ (and vice versa). When $P_i$ wants to communicate with $P_j$, it has a different session key.

Bottom line, the reason that this doesn't matter is that the identity of the other party is given together with the key.

One more note: it may not be absolutely necessary to allow this, but there's no reason to disallow it. Disallowing it may rule out protocols that are perfectly fine. Therefore, it's better to allow it if there's no reason not to.

  • $\begingroup$ That quote make sense in the context of KE, but I thought that PAKE was supposed to provide an additional guarantee that if there was no man-in-the-middle attack then the two parties get different keys if they provide different passwords. Otherwise the typical use case of a login page is insecure. That is, I'm concerned about the case where there are only two parties, $P_i$ and $P_j$, where $P_i$ is honest and knows the password while $P_j$ is malicious but does not know the password. According to the PAKE functionality, it seems that it is allowed for them to get the same key at the end. $\endgroup$ – qbt937 Apr 4 at 20:46
  • $\begingroup$ I don't see why the login page scenario is insecure. If the server is corrupted, then anything $P_i$ tells the server is known to the adversary. If the server is not corrupted, then $P_i$ and the server will share an unknown key, and $P_j$ and the server will have a key set by $P_j$ (but it will be different since $P_j$ doesn't know the key that $P_i$ has). I'm not sure if this answers your question, so please tell me. $\endgroup$ – Yehuda Lindell Apr 5 at 7:32
  • $\begingroup$ In the scenario I'm worried about, there are only two parties: $P_i$ is the honest server and $P_j$ is the corrupted user. There is no honest user. $P_j$ is trying to log in to an account that it does not have the password to. If $P_i$'s password choice is unknown to $P_j$ then $P_j$ should not be allowed to successfully log in, meaning that $P_i$'s session key should look uniformly random to $P_j$ if $P_j$'s password guess is incorrect. But it seems that the ideal functionality allows the session key to be chosen by $P_j$. I hope that this clarifies my question. $\endgroup$ – qbt937 Apr 5 at 19:19

The question is essentially why the line

If this record is compromised, or either $P_i$ or $P_j$ is corrupted, then output $(sid, sk)$ to player $P_i$.

is used in the ideal functionality, rather than

If this record is compromised, $P_i$ is corrupted, or $P_j$ is corrupted and there is a record $(P_j, P_i, pw')$ with $pw' = pw$, then output $(sid, sk)$ to player $P_i$.

This change would make it clear that a malicious user $P_j$ cannot successfully run this protocol to log in to an honest server $P_i$ if it makes an incorrect password guess, even when there is no man-in-the-middle (MITM) attack. I still do not know the reason for the current ideal functionality, but I do know that it is equivalent to the proposed modification when the underlying communication ideal functionality allows MITM attacks. In particular, I will assume that the PAKE, like every PAKE I know of, is based on the unauthenticated channel functionality, where the adversary is allowed to view all of the messages and modify them arbitrarily.

Let $\newcommand\oldfunc{\mathcal{F}}\oldfunc$ be Canetti et al.'s ideal functionality, $\newcommand\newfunc{\mathcal{F}'}\newfunc$ be the modified ideal functionality, and $\newcommand\commfunc{\mathcal{F}_{UA}}\commfunc$ be the unauthenticated channel functionality. Assume there is a protocol $\newcommand\prot{\mathcal{P}}\prot$ that realizes $\oldfunc$ in the $\commfunc$-hybrid model, using a simulator $\newcommand\oldsim{\mathcal{S}}\oldsim$. Then there is a simulator $\newcommand\newsim{\mathcal{S}'}\newsim$ that shows that $\prot$ realizes $\newfunc$ in the $\commfunc$-hybrid model. If both $P_i$ and $P_j$ are corrupted, or neither are, then $\newfunc$ behaves identically to $\oldfunc$, so $\newsim$ can behave exactly the same as $\oldsim$ in this case.

If there is one honest party $\newcommand\honP{P_i}\honP$ and one corrupted party $\newcommand\corP{P_j}\corP$, then $\newsim$ imagines a scenario where $\honP$ is still present, but also there is a second honest party $\newcommand\imagP{P_k}\imagP$ and a MITM attacker $\newcommand\mitmP{P_j'}\mitmP$. Specifically, $\imagP$ inputs a uniformly random string in $\{0,1\}^\kappa$ as its password, and the MITM attacker $\mitmP$ drops and ignores all messages from $\imagP$, instead sending all messages from $\honP$ to the original dishonest party $\corP$ and vice versa. $\newsim$ asks $\oldsim$ to simulate the environment's view for this scenario. It then forwards $\oldsim$'s queries to the ideal functionality, except that all queries mentioning the imagined honest party $\imagP$ are ignored, replaced with replies of "wrong guess" in the case of $\newcommand{\ucsymbol}[1]{\textsf{#1}}\ucsymbol{TestPwd}$ queries.

For the proof of indistinguishability (in the case of one honest party and one malicious party) between the real protocol $\prot$ that uses the communication functionality $\commfunc$, and the ideal functionality $\newfunc$ composed with the simulator $\newsim$, consider the following hybrids, starting from the real world.

  • Introduce a new party $\imagP$ that runs the real protocol with $\honP$ honestly, using a password sampled uniformly randomly from $\{0,1\}^\kappa$, though all of its messages are blocked in both directions. This is indistinguishable because this new party has no interaction with anything at all.
  • Reinterpret this interaction as being the execution of $\prot$ between two honest parties, but with a MITM attacker $\mitmP$ blocking the messages and behaving as described in $\newsim$. This is just a change of perspective, nothing actually changed.
  • Use the security of $\prot$ as an implementation of $\oldfunc$ between the parties $\honP$ and $\imagP$ to switch from the real protocol to the ideal world, where there is a simulator $\oldsim$ composed with an ideal functionality $\oldfunc$.
  • Swap ideal functionalities from $\oldfunc$ to $\newfunc$. This change is indistinguishable because the modification to the ideal functionality is only in the case where one party is compromised, and neither $\honP$ nor $\imagP$ is compromised.
  • Delete the imagined honest party $\imagP$. This eliminates a record from the ideal functionality, so $\oldsim$'s corresponding $\ucsymbol{TestPwd}$ queries should be handled by replying "wrong guess", and similarly any corresponding $\ucsymbol{NewKey}$ queries should be ignored. This is indistinguishable because $\oldsim$ has negligible chance of guessing $\imagP$'s password as it was sampled uniformly at random, and the output of a $(\ucsymbol{NewKey}, sid, \imagP, sk)$ query only goes to $\imagP$, which is being deleted. The only other way this might affect the execution is during a $(\ucsymbol{NewKey}, sid, \honP, sk)$ query, but again this would require $\imagP$'s password to be guessed.
  • Relabel $\imagP$ with $\corP$. Since $\imagP$ is only mentioned when $(\ucsymbol{NewSession}, sid, \honP, \imagP, pw, role)$ is queried by $\honP$, this change is purely internal to the honest party and the ideal functionality, and cannot be distinguished.

After these hybrids, we are now at the ideal world where the simulator $\newsim$ is composed with the ideal functionality $\newfunc$ in order to generate the view of the environment.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.