[Cfrg] A revision of OPAQUE paper was posted to eprint 2018 163

[Hugo Krawczyk <[e-mail]>]

We posted a revision of the OPAQUE paper to eprint.iacr.org/2018/163. This
version improves significantly on the formal aspects of the UC
functionalities
underlying our analysis and provides more detailed rationale for the
security
requirements and related definitional choices. It also updates the proofs to
satisfy the modified UC functionalities. In particular, we address feedback
from our reviewers, especially those of Bjorn Tackmann and Julia Hesse, to
whom
we are indebted for their comments.

The refined functionalities and proofs *did not lead to changes in the
protocol*
but did add an explicit requirement for the AKE component to provide full
forward secrecy (FS). So for OPAQUE, FS is not only a very desirable
property
but a requirement from the underlying AKE. The practical consequence is that
instantiations of OPAQUE must have at least 3 messages (*).
Such a third message is needed whenever explicit user authentication is
provided
so this entails no change in most password authentication settings.
In particular, there is no change in the proposed integration of OPAQUE
with
TLS 1.3 and IKEv2 which already provide full FS and a third message. As a
consequence, the OPAQUE analysis done by the CFRG teams with respect to TLS
1.3
and IKEv2 remains as valid as before (same for
draft-sullivan-tls-opaque-00).

(*) A third message is necessary since in order to achieve FS (against
active
attackers) at least one of the client messages in the AKE protocol must
depend
on the user's private key and this key is only learned by the client after
receiving the encrypted envelope from the server. So at the minimum one
needs a
first message from the client with user account information, followed by a
message from the server with the corresponding user's envelope, and a third
message from the client that depends on the user's private key.

On the formal side, the main changes are:

- The authenticated encryption used to create the "envelope" that contains
the
  user's private key needs to be modeled as an "equivocable encryption".
  Informally, equivocability means that given a ciphertext c and a message m
  (from the right distributions), one can find a key k such that c=Enc_k(m).
  Regular AuthEnc modes satisfy this property under the random oracle or
ideal
  cipher models. It is also possible to dispense with this modeling issue by
  eliminating the encryption altogether and deriving the user's private key
  directly from RwdU (the internet draft now describes this option).

- We changed the Strong aPAKE (SaPAKE) functionality underlying our
definition
  of security so that an attacker that learns the user's password is
allowed to
  compromise sessions that were open (not completed) at the time the
password
  was compromised, but only if the attacker actively intervened in the
session
  prior to the password compromise. We also eliminated the special
relaxation
  we had for the case that the server sends the last message in the
protocol.
  This case is now handled under the SaPAKE functionality via a postponed
  password test.

- We expanded the OPRF functionality to output a "binder" that binds
between the
  OPRF and AKE sub-sessions that comprise an OPAQUE session. In the DH-OPRF
  scheme, this binder is defined as the first user message (denoted a or
alpha).
  The OPAQUE description in Fig. 12 includes this binder mechanism via
session
  id ssid'.

There is still room for improvement but we wanted to post this revised
version
particularly for those looking at the theoretical foundation of OPAQUE.
(Note: Section 4 has not yet been revised to adapt it to the modified
SaPAKE
and OPRF functionalities but this section is unrelated to OPAQUE.)

We will be happy to answer any questions and receive more enlightening
comments.

S, H, J.