[Cfrg] proofs for augmented PAKEs

["Björn Haase" <[e-mail]>]

Hello to all,

 

I do fully support Hugo’s statement and the assessment regarding the status of proofs of different augmented PAKE protocols.

 

My own analysis regarding the rather complex topic of security analysis of augmented PAKE protocols for IoT is found in my recent CHES publication

https://tches.iacr.org/index.php/TCHES/article/view/7384" rel="nofollow">https://tches.iacr.org/index.php/TCHES/article/view/7384 (“AuCPace: Efficient verifier-based PAKE protocol tailored for the IIoT”). This paper also covers an analysis and a comparison with other proposals such as AugPake and SPAKE2+.

 

Hugo’s and my assessment regarding SPAKE2+ is also in line with the analysis of Pointcheval and Wang in (https://www.di.ens.fr/david.pointcheval/Documents/Papers/2017_asiaccsB.pdf" rel="nofollow">https://www.di.ens.fr/david.pointcheval/Documents/Papers/2017_asiaccsB.pdf). I’d like to cite Pointcheval and Wang from this paper:

“Cash et al.  proposed […] SPAKE2+. While it has been proven secure against server compromise, as for SPAKE, forward-secrecy has never been considered.”

 

Their result is in line with my analysis. This means, while, IMO, there is no specific reason to believe that SPAKE2+ is insecure. However just as for AugPake the security analysis covers only part of the security guarantees associated with augmented PAKE. Notably forward secrecy (which is the main objective for the use-case of bootstrapping security on a IoT device!) is not formally considered neither by SPAKE2+ nor by AugPake.

 

One possible problem of using PAKE protocols in a larger environment is that vulnerabilities might be introduced by the larger protocol framework (of which the PAKE is only one sub-component). OPAQUE unlike SPAKE2+ and AugPake has been analyzed in a composable framework (UC) allowing for modular security analysis. I do see this as a significant advantage of OPAQUE. Moreover the security guarantees within UC also cover the case of applications which use related passwords.

 

Regarding security analysis, in my assessment (see also the AuCPace paper) the best security properties available today are offered by OPAQUE:

 

The currently unique feature of OPAQUE among all candidates suggested for TLS is it’s resistance to pre-computation attacks. So if having the choice between OPAQUE and all of the other augmented PAKE candidates (SPAKE2+, AugPake), I’d clearly opt for OPAQUE!

 

My personal objections regarding OPAQUE are only the following:

• Patent issues, which appearantly will be *no* issue for use in TLS at all.
• Secondly I see some minor advantages for my own augmented PAKE proposal AuCPace in specific, extremely resource-constrained environments which could afford neither SPAKE2+ nor OPAQUE.

 

For the general IoT use-case, in my humble opinion, OPAQUE is *clearly* the best current available proposal, specifically if used on Montgomery or Edwards curves in conjunction with Elligator2 for the OPRF and with a memory-hard password hash such as Argon2 or scrypt.

 

Yours,

 

Björn