4
$\begingroup$

So while discussing the issues of password-hashing off-loading in our chat I noticed that it's easy to extend OPAQUE (CFRG draft) to essentially be a better standard password based authentication when executed over TLS. Namely one could simply append a message $F_K(2)$ (for some pre-defined PRF $F$) from the client to the server and only if the client arrived at the correct shared secret $K$ the server will get the same PRF evaluation value and confirm the authentication.

Now my question is:
This protocol contains the full OPAQUE key-exchange, can it be optimized to remove heavy computations (such as exponentations) from either side without compromising security while keeping the number of sent messages or even lowering it?

To give a more concrete direction: Can we remove parts of the (or even the complete) key exchange and only rely on the OPRF (or a parallel instance)?


For your convenience, here is the overview of the protocol:

\begin{align} U\to S:&\ \text{username}, H'(\text{pw})^r, g^x\\ S\to U:&\ g^y, H'(\text{pw})^{rk}, c\\ U\to S:&\ F_K(2)\\ \end{align}

with $r$ being chosen uniformly at random for each protocol run by the user $U$, same with $x$, $y$ is chosen the same way by the server, $k$ is a static per-user server-side secret, $\text{Rwd}=H(\text{pw},H'(\text{pw})^k)$ and $c=\operatorname{Enc}_{\text{Rwd}}(p_u,P_u,P_s)$ where $P_x$ is $x$'s public key and $p_x$ is $x's$ private DH key. The server also retrieves $p_s$ based on the username (as well as $P_u,P_s$) and $K$ is the result of securely combining (HMQV) $(x,p_u,P_s,g^y)$ or $(y,p_s,P_u,g^x)$.

$\endgroup$
  • $\begingroup$ I'm now mildly sure that the entire key-exchange can be dropped as recovery of the OPRF output is equivalent to successfully being the client as then one can easily recover the private DH keys $\endgroup$ – SEJPM Dec 12 '18 at 9:00

Your Answer

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

Browse other questions tagged or ask your own question.