Re: [Cfrg] Updated review of PAKEs

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

Thanks a lot, Bjoern!

Regards,
Stanislav

пн, 9 марта 2020 г. в 01:24, Bjoern Tackmann <[e-mail]>:

> This is a brief update of my review of all candidates sent on October 29
> [1]. Note that there was a follow-up discussion in which Hugo pointed out
> flaws in my report. (None of them had an effect on the outcome.)
>
>
> Balanced PAKE
> ===========
>
> The short version is that I prefer CPACE over SPAKE2. The arguments are
> essentially the same as in the previous review. SPAKE2 seems an (almost)
> equally good alternative, and picking one of the two was difficult.
>
> Sparked by Julia’s excellent review of the proofs [2], I wanted to share
> some of my own thoughts on this in a bit more detail. I fully support
> Julia’s argument that SPAKE2 has a published proof that is written clearly
> and in detail, and that has withstood scrutiny since 2005. The CPACE proof,
> by contrast, omits several important steps (such as all reduction
> arguments), has been more of a moving target during review, and has been
> published only last year. The SPAKE2 theorem is in concrete security (which
> I think is an important aspect), whereas the CPACE theorem only provides an
> asymptotic “soundness” guarantee. And yet, the formal statement for SPAKE2
> has the assumption of uniformly distributed passwords; the protocol does
> not seem to use this anywhere but it is still a limitation in the proof
> support. It is also unclear how the proved security of SPAKE2 composes when
> the key is used in higher-level protocols. And last but not least, I think
> (disclaimer: what follows is not a statement I can make formal) that the
> dependency on stronger idealization in the proof of CPACE is linked to the
> use of a security model that is significantly stronger in corruption
> modeling. So in terms of proof support I find the two protocols
> incomparable, and my preference for CPACE mostly comes from the “more
> useful” (targeted) security statement. I fully understand Julia’s reasons
> for coming to a different conclusion.
>
> Finally, and although it may be unnecessary to point this out: even subtle
> changes in protocols invalidate existing security proofs. I think it would
> be prudent for CFRG to re-evaluate the proof support after the
> now-discussed modifications to the chosen protocol (e.g., choice of session
> id for CPACE, choice of M,N for SPAKE2) are finalized, before deciding on
> the final outcome (“zero or one” candidates) of the process.
>
> And just for completeness: I deliberately did not take possible IP issues
> into account.
>
>
> Augmented PAKE
> ===========
>
> The short version is that I prefer OPAQUE over AUCPACE. The main arguments
> are OPAQUE’s better compatibility with important application protocols
> through less protocol messages, and its flexibility.
>
> Amending my previous review, the latest proof for OPAQUE is indeed a
> significant improvement over the one that was available when I started that
> review. So besides the preferable properties stated above, I now consider
> the proof support for OPAQUE also as better than that for AUCPACE. (This is
> in full agreement with Julia’s assessment.)
>
>
> [1]
> https://mailarchive.ietf.org/arch/msg/cfrg/1sNu9USxo1lnFdzCL5msUFKBjzM/
> [2]
> https://mailarchive.ietf.org/arch/msg/cfrg/47pnOSsrVS8uozXbAuM-alEk0-s/
>
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg
>