Subject: Re: [Cfrg] A question to be added to the Round 2 questions list for nominated PAKEs (about SPAKE2)
From: "Stanislav V. Smyshlyaev" <[email-masked]>
To: "Hao, Feng" <[email-masked]>
Cc: CFRG <[email-masked]>
Date: Wed, 20 Nov 2019 19:12:24 +0800
List-Id: Crypto Forum Research Group <cfrg.irtf.org>

Dear Feng,

Of course, any modifications of the protocols can only be provided only
together with updated security proofs (that need additional verification,
of course) - it was mentioned in my previous message.

Regards,
Stanislav

ср, 20 нояб. 2019 г. в 18:52, Hao, Feng <[email-masked]>:

> 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 <[email-masked]> on behalf of "Stanislav V.
> Smyshlyaev" <[email-masked]>
> *Date: *Wednesday, 20 November 2019 at 07:44
> *To: *"[email-masked]" <[email-masked]>
> *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
>
-- 

С уважением,

Станислав Смышляев, к.ф.-м.н.,

Заместитель генерального директора

ООО «КРИПТО-ПРО»