OPAQUE is an sdPAKE

[Sc00bz]

• Replaced "asymmetric PAKE" with augmented PAKE since "asymmetric PAKE" is incorrect terminology.
• Added info on doubly augmented PAKEs (dPAKE).
• Stated OPAQUE is a strong dPAKE (sdPAKE).
• Replaced "secure aPAKE" with "strong dPAKE" (sdPAKE). Strong being what academic papers use to describe PAKEs that are secure against pre-computation attacks.

The following might need to be reworded or use a different source. Since JKX18 defined an saPAKE vs sdPAKE. The difference being that the client can also store data that can be used to authenticate to the server but not used to authenticate to the client. Lines 325-326:

- This document describes OPAQUE, an aPAKE that is secure against pre-computation attacks (as defined in {{JKX18}}).

+ This document describes OPAQUE, an sdPAKE (as defined in {{JKX18}}).

Note I moved "secure against pre-computation attacks" to here since that's part of being an sdPAKE. Lines 312-313:

- A secure aPAKE should provide the best possible security for a password protocol.

+ A strong dPAKE (sdPAKE) should provide the best possible security for a password protocol which includes being secure against pre-computation attacks.

Also the "Security Analysis" section needs updating since the source proved the security of OPAQUE in an saPAKE model instead of an sdPAKE model. The difference in the proof is minor and would likely be obvious for anyone that knows how to write a proof. It's basically something along the lines of "the private client identity key and public server identity key are unrelated to the password thus you can't use it to make offline password guesses. Without knowing the private server identity key means you can't authenticate as the server (which should already part of the saPAKE model proof)." Also since it's an sdPAKE the client data can't be used for offline password guesses (even if the private keys are related to the password) because of the OPRF. Although I hear that people don't like "story proofs". So I'm not sure how to prove this correctly. Lines 2061-2063:

Jarecki et al. {{JKX18}} proved the security of OPAQUE (modulo the design differences outlined in {{notable-design-differences}}) in a strong aPAKE model...

[kevinlewi]

@Sc00bz Thanks for the PR!

I think the terminology change from "asymmetric" -> "augmented" is something I am supportive of (though don't have too strong of a preference either way)

However, rather than defining OPAQUE as a strong doubly-augmented PAKE, I would prefer to still define OPAQUE as being a strong augmented PAKE, and then within the document we can also add a paragraph about the fact that it is doubly-augmented.

The reasons being that:

• The proofs in the paper prove that it is a strong aPAKE and not a strong sdPAKE as you also remarked, and it is cleaner to simply say that the proofs support that it meets the bar of strong aPAKEs
• The term "doubly augmented" is not as widely known as simply "augmented", and so I hesitate to include it in the title of the draft / first paragraph.
• We can still include the points that you wanted in the doc about doubly-augmented, just surfaced less prominently, if that is alright with you!

[kevinlewi]

Modified the PR to address my previous comments. Please see the text of the new subsection:

Client Authentication Using Credentials

and let me know if this suffices. As mentioned above, I think we are aiming to avoid defining OPAQUE as a doubly augmented PAKE, even though it does satisfy those properties, because there isn't a proof for it at the moment (nor a formal UC-style definition of doubly-augmented), and the original OPAQUE paper only proves it with respect to a strong augmented PAKE.

However, the property itself is still worth mentioning.

Thanks @Sc00bz and appreciate your patience on getting this right.

[kevinlewi]

@Sc00bz ^ can you check the revisions that I made and let us know if this is acceptable? We'd like to merge this PR in and publish the next draft once this is unblocked. Thank you!

[bytemare]

I suggest we add that we give all the details on how to do it, adding that the OPRF finish/output and stretching can be skipped in favor of directly using the randomized henceforth. What do you think?

[kevinlewi]

Good idea. I added a little bit more to the description to clarify how this would be done. Let me know what you think!

[bytemare]

Looks good to me :) thank you @Sc00bz and @kevinlewi ! 👍