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

["Stanislav V. Smyshlyaev" <[e-mail]>]

Dear Julia,

Thanks a lot for your continuing efforts with the draft!

>> I am still discussing a few things related to my review with Hugo
"offline". We will get back to you if any further changes are required.
Could you please let us know when you come to a conclusion with Hugo? It
might be an issue if Hugo and you decide that any further changes are
needed after we start a RGLC.

Regards,
Stanislav (for CFRG chairs)

On Tue, Oct 31, 2023 at 11:33 AM Julia Hesse <[e-mail]> wrote:

> Hi Kevin,
>
> apologies for the delayed reply. I went through your changes and they
> perfectly address my concerns.
>
> I am still discussing a few things related to my review with Hugo
> "offline". We will get back to you if any further changes are required.
>
> Thanks!
>
> Julia
>
> Am 19/09/2023 um 02:46 schrieb Kevin Lewi:
>
> Hi Julia,
>
> Thanks for the review! Responses inline, and you can find a list of the
> changes here:
> https://github.com/cfrg/draft-irtf-cfrg-opaque/pull/423/files
>
> On Fri, Sep 15, 2023 at 1:37 AM Julia Hesse <[e-mail]> wrote:
>
>> 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?
>>
>
> Changed the DeriveKeyPair definition to read:
>
> - DeriveKeyPair(seed, info): Create and output (`sk`, `pk`), consisting of
> a private and public key derived deterministically from a `seed`` and
> `info`` parameter, as described in {{OPRF, Section 3.2}}.
>
> The public key is not used in one case (when we compute (oprf_key, _) =
> DeriveKeyPair(seed, "OPAQUE-DeriveKeyPair")), but it is used for some
> configurations in the AKE section (for example in 3DH
> ristretto255: DeriveDiffieHellmanKeyPair(seed): This function is
> implemented as DeriveKeyPair(seed, "OPAQUE-DeriveDiffieHellmanKeyPair"),
> where DeriveKeyPair is as specified in {{OPRF, Section 3.2}}. The public
> value from DeriveKeyPair is encoded using SerializeElement from {{Section
> 2.1 of OPRF}}.)
>
>
>> - 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 think there might be some confusion here. The sentence, "The server can
> use this single pair of keys with multiple clients" refers to
> the server_private_key and server_public_key parameters used in the AKE
> section, not the OPRF key. The "oprf_seed" is something we believe can be
> re-used for each client, but anyway the sentence says it is OK to use
> multiple seeds if desired. The actual OPRF key is not referenced in this
> paragraph, because it is anyway derived from KDF(oprf_seed,
> credential_identifier), and not handpicked by the server.
>
> To address the confusion, I changed the text to say, "The server can use
> `server_private_key` and `server_public_key` with multiple clients and can
> opt to use multiple seeds (so long as they are kept consistent for each
> client)." (instead of saying "this single pair of keys", just spelling out
> which pair of keys the text is referring to).
>
>
>
>> - 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.
>>
>
> I believe this is already addressed by the paragraph at the end of Section
> 3, "The rest of this document describes the details of these stages in
> detail. Section 4 describes how client credential information is generated,
> encoded, and stored on the server during registration, and recovered during
> login. Section 5 describes the first registration stage of the protocol,
> and Section 6 describes the second authentication stage of the protocol.
> Section 7 describes how to instantiate OPAQUE using different cryptographic
> dependencies and parameters."
>
> But if you have some suggested wording to make this even more clear, let
> me know and I can incorporate it!
>
>
>>
>> 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...
>>
>
> Good point. In 10.1, I changed the text on export_key to say, "This key is
> a pseudorandom value *derived from the client password (among other
> values)* and has no influence on the security analysis (it can be simulated
> with a random output)."
> And in 10.5, I still wanted to capture the usage of the export key, and so
> I changed the text to the following:
>
> "The export key can be used (separately from the OPAQUE protocol) to
> provide confidentiality and integrity to other data which only the client
> should be able to process. For instance, if the client wishes to store
> secrets with a third party, then this export key can be used by the client
> to encrypt these secrets so that they remain hidden from a passive
> adversary that does not have access to the server's secret keys or the
> client's password."
>
> Let me know if this is still inaccurate.
>
>
>> - 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.
>>
>
> I will simply delete this sentence -- I believe we added it in originally
> to address feedback that we got about choosing one specific recovery
> mechanism over another alternative, but I agree that at this point, such an
> exercise should be done with caution, and we don't want to actively
> recommend doing so (unless it comes with a proper security analysis).
>
>
>> - Sec 10.1, first bullet. The "upcoming paper" is here:
>> https://eprint.iacr.org/2023/220
>
>
> Added
>
>
>>
>> - 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.
>>
>
> Thanks, I simply removed the sentence: "This variant is also analyzed in
> the new paper referred to in the previous item."
>
>
>> - 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).
>
>
> I amended the first sentence to have the caveat: "Jarecki et al. {{JKX18}}
> proved the security of OPAQUE (modulo the design differences outlined in
> {{notable-design-differences}})" (referring to the previous section)
>
>
>
>> 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.
>>
>
> I see. At the end of this section, I added the paragraph: "In {{JKX18}},
> security is proven for one instance (i.e., one key) of the OPAQUE protocol,
> and without batching. There is currently no security analysis available for
> the OPAQUE protocol described in this document in a setting with multiple
> server keys or batching."
>
>
>>
>> Nits:
>> - the voprf draft is now a RFC and could be cited as such
>>
>
> I think it is not an RFC just yet (or at least I don't see an RFC number
> anywhere)
>
>
>> - "describes the details of these stages in detail"
>>
>
> Thanks, changed to "describes the specifics of these stages in detail"
>
>
>> - Sec 4, Create CleartextCredentials: client_public_key missing from the
>> inputs?
>>
>
> client_public_key is not stored in the struct because it is derived from
> client_private_key. But JP Aumasson also pointed out this confusion, and in
> response to his edits, I added the text: "*A subset of* these credential
> values are used in ..."
>
>
>>
>> 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
>>
>>
>