3

If the server is honest-but-curious, it can attempt to guess the user’s password $\mathsf{pw}$ by computing $\mathsf{rw} = H(\mathsf{pw}, H'(\mathsf{pw})^s)$,where $s$ is the server's OPRF key. Then, with this guessed value of $\mathsf{rw}$, the server can decrypt the envelope $c$ and check whether the decrypted message $m' = \mathsf{AuthDec}_{\mathsf{rw}}(c)$ contains the user’s public key $P_u$. This would allow the server to verify if the guessed password is correct, even without directly deviating from the protocol.

Let me first ask if I'm missing something here; otherwise, my question is

Is the role of the OPRF in OPAQUE merely to prevent the server from storing plaintext information to avoid precomputation attacks, but not to ensure that the server cannot learn the user's password?

frost.crystal
  • 75
  • 4

1 Answers1

4

What you describe is correct. It's important to understand that the server can always test guesses for the client's password, in any asymmetric PAKE protocol -- this is an inevitable consequence of PAKE syntax. To test a password guess, the server can simply imagine an execution of the authentication protocol between itself and an imagined client, and see whether it succeeds. This is always possible because the assumption of PAKE is that the password is the only thing necessary to run as the client.

The goal of OPAQUE and other saPAKE protocols is that nothing worse than this attack is possible. In particular, if it takes $n$ effort to brute-force one user's password, then it should take $2n$ effort to brute-force two users' passwords. The OPRF in OPAQUE is related to this property. Each user has their own OPRF secret $s$, so every evaluation of the OPRF $H(\textsf{pw}, H'(\textsf{pw})^s)$ represents effort directed at a particular user, and is useless to attack a different user.

Mikero
  • 14,908
  • 2
  • 35
  • 58