Re: [Cfrg] A question to be added to the Round 2 questions list for nominated PAKEs (about SPAKE2)

["Hao, Feng" <[e-mail]>]

Hi,

I’m not involved in the panel review, but the following is my personal observation.

It seems to me that this standardization process is tangled with modifying protocols and fixing issues as they arise along the way. The changes raised below are not anything trivial. As we should all know well, designing a cryptographic protocol is extremely delicate and error-prone – it often takes several years of public scrutiny to uncover flaws; even for protocols that are “provably secure”, the proofs may contain errors or invalid assumptions, which can also take several years for them to be discovered. If a protocol is to be considered for standardization, first of all, it should really need to be “completely” specified, and “fixed” (no movable parts). Then, give plenty time for public scrutiny and time for maturity. If no attacks are found, the public confidence on the security on the protocol will grow over time. In most cases, designers of a protocol only have a chance to get it right – either at the start or never. Allowing heuristic or retrospective changes would not help increase public confidence.

Cheers,
Feng

From: Cfrg <[e-mail]> on behalf of "Stanislav V. Smyshlyaev" <[e-mail]>
Date: Wednesday, 20 November 2019 at 07:44
To: "[e-mail]" <[e-mail]>
Subject: [Cfrg] A question to be added to the Round 2 questions list for nominated PAKEs (about SPAKE2)

Dear CFRG,

I've just sent two questions to be considered to be added to the Round 2 questions list, including: "Can you propose a modification of SPAKE2 (preserving all existing good properties of SPAKE2) with a correspondingly updated security proof, addressing the issue of a single discrete log relationship necessary for the security of all sessions (e.g., solution based on using M=hash2curve(A|B), N=hash2curve(B|A))?"

We've had a discussion with Dan Harkins about possible improvements of SPAKE2 (many thanks to him for such a fruitful discussion!): it seems that the only major issue about SPAKE2 can be solved by using M=hash2curve(A|B), N=hash2curve(B|A)). It seems that there can't be any additional side-channel issues (like occured in Dragonfly), since the proposed modification needs only calculations based on publicly available information.

Of course, such a modification requires additional security analysis of SPAKE2, modified accordingly.

Best regards,
Stanislav