Subject: Re: [CFRG] Tracking OPAQUE changes

From: Christopher Wood <[email-masked]>
Date: Tue, 8 Feb 2022 17:09:35 -0800

Hi folks,

Following up on this message we previously sent to the list, I'd like to call your attention to this section in the draft:

   https://cfrg.github.io/draft-irtf-cfrg-opaque/draft-irtf-cfrg-opaque.html#name-notable-design-differences
   
We'll include this in the next published version of the document, which is coming soon! The list is also copied at the end of this message for convenience. References such as [JKX18] and others can be found in the document.

The editors will maintain this list going forward to ensure that all notable differences between the original paper and this evolving specification are tracked and justified. Of course, please let us know -- either here or on GitHub -- if you have any questions or comments!

Thanks,
Chris, on behalf of the OPAQUE team

~~~
   The specification as written here differs from the original
   cryptographic design in [JKX18] and the corresponding CFRG document
   [I-D.krawczyk-cfrg-opaque-03], both of which were used as input to
   the CFRG PAKE competition.  This section describes these differences,
   including their motivation and explanation as to why they preserve
   the provable security of OPAQUE based on [JKX18].

   The following list enumerates important functional differences that
   were made as part of the protocol specification process to address
   application or implementation considerations.

   *  Clients construct envelope contents without revealing the password
      to the server, as described in Section 5, whereas the servers
      construct envelopes in [JKX18].  This change adds to the security
      of the protocol.  [JKX18] considered the case where the envelope
      was constructed by the server for reasons of compatibility with
      previous UC modeling.  An upcoming paper analyzes the registration
      phase as specified in this document.  This change was made to
      support registration flows where the client chooses the password
      and wishes to keep it secret from the server, and it is compatible
      with the variant in [JKX18] that was originally analyzed.

   *  Envelopes do not contain encrypted credentials.  Instead,
      envelopes contain information used to derive client private key
      material for the AKE.  This variant is also analyzed in the new
      paper referred to in the previous item.  This change improves the
      assumption behind the protocol by getting rid of equivocability
      and random key robustness for the encryption function.  The latter
      property is only required for authentication and achieved by a
      collision-resistant MAC.  This change was made for two reasons.
      First, it reduces the number of bytes stored in envelopes, which
      is an helpful improvement for large applications of OPAQUE with
      many registered users.  Second, it removes the need for client
      applications to generate authentication keys during registration.
      Instead, this responsibility is handled by OPAQUE, thereby
      simplifying the client interface to the protocol.

   *  Envelopes are masked with a per-user masking key as a way of
      preventing client enumeration attacks.  See Section 10.9 for more
      details.  This extension is not needed for the security of OPAQUE
      as an aPAKE but only used to provide a defense against enumeration
      attacks.  In the analysis, the masking key can be simulated as a
      (pseudo) random key.  This change was made to support real-world
      use cases where client or user enumeration is a security (or
      privacy) risk.

   *  Per-user OPRF keys are derived from a client identity and cross-
      user PRF seed as a mitigation against client enumeration attacks.
      See Section 10.9 for more details.  The analysis of OPAQUE assumes
      OPRF keys of different users are independently random or
      pseudorandom.  Deriving these keys via a single PRF (i.e., with a
      single cross-user key) applied to users' identities satisfies this
      assumption.  This change was made to support real-world use cases
      where client or user enumeration is a security (or privacy) risk.

   *  The protocol outputs an export key for the client in addition to
      shared session key that can be used for application-specific
      purposes.  This key is a pseudorandom value independent of other
      values in the protocol and has no influence in the security
      analysis (it can be simulated with a random output).  This change
      was made to support more application use cases for OPAQUE, such as
      use of OPAQUE for end-to-end encrypted backups; see [WhatsAppE2E].

   *  The protocol admits optional application-layer client and server
      identities.  In the absence of these identities, client and server
      are authenticated against their public keys.  Binding
      authentication to identities is part of the AKE part of OPAQUE.
      The type of identities and their semantics are application
      dependent and independent of the protocol analysis.  This change
      was made to simplify client and server interfaces to the protocol
      by removing the need to specify additional identities alongside
      their corresponding public authentication keys when not needed.

   *  The protocol admits application-specific context information
      configured out-of-band in the AKE transcript.  This allows domain
      separation between different application uses of OPAQUE.  This is
      a mechanism for the AKE component and is best practice as for
      domain separation between different applications of the protocol.
      This change was made to allow different applications to use OPAQUE
      without risk of cross-protocol attacks.

   *  Servers use a separate identifier for computing OPRF evaluations
      and indexing into the password file storage, called the
      credential_identifier.  This allows clients to change their
      application-layer identity (client_identity) without inducing
      server-side changes, e.g., by changing an email address associated
      with a given account.  This mechanism is part of the derivation of
      OPRF keys via a single PRF.  As long as the derivation of
      different OPRF keys from a single OPRF have different PRF inputs,
      the protocol is secure.  The choice of such inputs is up to the
      application.

   The following list enumerates notable differences and refinements
   from the original cryptographic design in [JKX18] and the
   corresponding CFRG document [I-D.krawczyk-cfrg-opaque-03] that were
   made to make this specification suitable for interoperable
   implementations.

   *  [JKX18] used a generic prime-order group for the DH-OPRF and HMQV
      operations, and includes necessary prime-order subgroup checks
      when receiving attacker-controlled values over the wire.  This
      specification instantiates the prime-order group using for 3DH
      using prime-order groups based on elliptic curves, as described in
      [I-D.irtf-cfrg-voprf], Section 2.1.  This specification also
      delegates OPRF group choice and operations to
      [I-D.irtf-cfrg-voprf].  As such, the prime-order group as used in
      the OPRF and 3DH as specified in this document both adhere to the
      requirements as [JKX18].

   *  [JKX18] specified DH-OPRF (see Appendix B) to instantiate the OPRF
      functionality in the protocol.  A critical part of DH-OPRF is the
      hash-to-group operation, which was not instantiated in the
      original analysis.  However, the requirements for this operation
      were included.  This specification instantiates the OPRF
      functionality based on the [I-D.irtf-cfrg-voprf], which is
      identical to the DH-OPRF functionality in [JKX18] and, concretely,
      uses the hash-to-curve functions in [I-D.irtf-cfrg-hash-to-curve].
      All hash-to-curve methods in [I-D.irtf-cfrg-hash-to-curve] are
      compliant with the requirement in [JKX18], namely, that the output
      be a member of the prime-order group.

   *  [JKX18] and [I-D.krawczyk-cfrg-opaque-03] both used HMQV as the
      AKE for the protocol.  However, this document fully specifies 3DH
      instead of HMQV (though a sketch for how to instantiate OPAQUE
      using HMQV is included in Appendix C.1).  Since 3DH satisfies the
      essential requirements for the AKE as described in [JKX18] and
      [I-D.krawczyk-cfrg-opaque-03], as recalled in Section 10.2, this
      change preserves the overall security of the protocol. 3DH was
      chosen for its simplicity and ease of implementation.

   *  The DH-OPRF and HMQV instantiation of OPAQUE in [JKX18], Figure 12
      uses a different transcript than that which is described in this
      specification.  In particular, the key exchange transcript
      specified in Section 6.4 is a superset of the transcript as
      defined in [JKX18].  This was done to align with best practices,
      such as is done for key exchange protocols like TLS 1.3 [RFC8446].

   *  Neither [JKX18] nor [I-D.krawczyk-cfrg-opaque-03] included wire
      format details for the protocol, which is essential for
      interoperability.  This specification fills this gap by including
      such wire format details and corresponding test vectors; see
      Appendix D.
~~~

> On Dec 20, 2021, at 7:01 AM, Christopher Wood <[email-masked]> wrote:
> 
> Hi folks,
> 
> We were asked to document noteworthy changes made to the OPAQUE specification that differentiate it from the original paper [1]. To that end, we started compiling a list of changes in [2]. Moving forward, we'll keep this list updated as new versions are published. Please do not hesitate to ask for additional clarification on any item listed.
> 
> Best,
> Chris
> 
> P.S. If you're interested in tracking changes to the editor's version of the specification, you can subscribe to notifications from GitHub. See https://docs.github.com/en/account-and-profile/managing-subscriptions-and-notifications-on-github/setting-up-notifications/configuring-notifications for more details.
> 
> [1] https://eprint.iacr.org/2018/163
> [2] https://cfrg.github.io/draft-irtf-cfrg-opaque/draft-irtf-cfrg-opaque.html#name-notable-design-differences
> 
> _______________________________________________
> CFRG mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg