Re: [CFRG] [Crypto-panel] Request for review: OPAQUE

[Julia Hesse <[e-mail]>]

Hi,

this is my review of draft-irtf-cfrg-opaque-11. Disclaimer: I have 
recently published a paper with two of the authors (Hugo, Chris) on a 
related topic, which is also mentioned in the draft.

Overall the draft seems pretty mature to me. I have a few presentational 
comments and some comments regarding the security proof of the specified 
version of OPAQUE. I did not attempt to implement from the draft, and I 
did not verify any test vectors.

Editorial:
- Sec 2.1, DeriveKeyPair: maybe assign names to the output of this API? 
It is also unclear what happens with the public key. Is that needed 
anywhere else?
- Sec 3.1, "The server can use this single pair of keys with multiple 
clients and can opt to use multiple seeds (so long as they are kept 
consistent for each client)." - WhatsApp's usage of OPAQUE is one 
example where *reusing* a key among several clients is devastating for 
the security of the overall scheme. It should be made super clear in 
this draft that *individual* keys have to be used per client. There are 
other parts in the draft where this is actually taken care of, but the 
cited paragraph here is too ambiguous, imo. What is a "client"? And is 
it really okay to use the same key and same seed for many clients?
- I had a hard time following the modularization of the protocol. In 
Section 3, the phases are described as Setup, Offline registration, and 
online AKE. That is decoupled from 4, which describes client credential 
storage and key recovery. This touches both offline registration and 
online AKE phases. I do not want to suggest to do any large changes, but 
2-3 clarifying sentences about the structure of the 
sections/explanations of the different protocol phases could be added.

Security:
- The export key export_key is (if I understood correctly), 
deterministically derived from PRF_K(pw). I simplify a bit here. This 
means the server can brute-force export_key. export_key is *not* as 
secure as a key that is, e.g., generated by the client running some 
keygen locally. This should be made super clear in the draft, imo. In 
particular, 10.1 states that export_key is a "pseudorandom value 
independent of other values in the protocol", and 10.5 says that it can 
be used to encrypt client secrets and store them on the server. The 
latter I find particularly alarming: the server can run long-term 
password guessing attempts against this encryption key, so I would 
specifically recommend to *not* use export_key as an encryption key when 
storing things on the server. Not sure if I'm too careful here, but 
people do tend to choose weak passwords...
- Sec 4, "Future variants of OPAQUE may use different key recovery 
mechanisms. See Section 4.1 for details." - Section 4.1 does not specify 
any framework/constraints on what such mechanism need to fulfill, and I 
would downtone this "invitation" to design one's own recovery mechanism.
- Sec 10.1, first bullet. The "upcoming paper" is here: 
https://eprint.iacr.org/2023/220
- Sec 10.1, second bullet. It is not true that this variant is analyzed 
in "the new paper", i.e., the paper mentioned in the first bullet. I 
have discussed this already with Hugo and he agrees.
- Sec 10.2 Security Analysis. This section mentions that the security of 
OPAQUE was proven in [JKX18]. However, the protocol proven there differs 
in many ways from the protocol specified in this draft. As a starting 
point, https://eprint.iacr.org/2023/843.pdf points out differences 
between the proven version and the draft versions v03 and v09 (I did not 
check whether all these still apply to v11). Most importantly, [JKX18] 
requires session identifiers not only for the overall OPAQUE protocol 
but also for the VOPRF building block. However, the VOPRF as currently 
specified in draft-irtf-cfrg-voprf-21 does not add unique session 
identifiers to, e.g., hash inputs (which would be required for the 
security analysis of both [JKK14] and [JKX18] to apply to a multi-user 
VOPRF, and a multi-client OPAQUE). I discussed this with Chris and he 
added the following disclaimer to the VOPRF security considerations 
section of draft-irtf-cfrg-voprf-21:

"In [JKK14], these properties are proven for one instance (i.e., one 
key) of the VOPRF protocol, and without batching. There is currently no 
security analysis available for the VOPRF protocol described in this 
document in a setting with multiple server keys or batching."

The same should be done in the OPAQUE draft, because for the specified 
protocol, multi-client security is not proven anywhere in the 
literature, afaik.

Nits:
- the voprf draft is now a RFC and could be cited as such
- "describes the details of these stages in detail"
- Sec 4, Create CleartextCredentials: client_public_key missing from the 
inputs?

Best,
Julia

Am 18/08/2023 um 08:17 schrieb Stanislav V. Smyshlyaev:
> Dear Crypto Panel Experts,
>
> The chairs would like to ask the Crypto Panel to provide three (or 
> more) reviews for the OPAQUE draft, "The OPAQUE Asymmetric PAKE 
> Protocol", draft-irtf-cfrg-opaque-11 
> (https://datatracker.ietf.org/doc/draft-irtf-cfrg-opaque/)
>
> The OPAQUE protocol was selected as a result of the PAKE selection 
> process in CFRG; there were a lot of reviews of the protocol and the 
> early versions of the draft, see https://github.com/cfrg/pake-selection
> There were several important questions in those reviews which had to 
> be addressed during the evolution of the draft in CFRG: some of them 
> are underlined in the following paper: 
> https://eprint.iacr.org/2021/839.pdf
>
> Hence we would like to ask the reviewers to pay a lot of attention to 
> reviewing this draft, trying to take into account as many 
> considerations provided in the previous reviews as possible.
>
>
> Stanislav (on behalf of the CFRG Chairs)
>
> _______________________________________________
> Crypto-panel mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/crypto-panel