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

From: "Stanislav V. Smyshlyaev" <[email-masked]>
Date: Wed, 20 Nov 2019 10:43:26 +0300

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

---

From: "Hao, Feng" <[email-masked]>
Date: Wed, 20 Nov 2019 10:52:43 +0000

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

---

From: "Stanislav V. Smyshlyaev" <[email-masked]>
Date: Wed, 20 Nov 2019 19:12:24 +0800

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]>:

> 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,
>
>
>
-- 

С уважением,

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

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

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

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Wed, 20 Nov 2019 15:49:01 +0000

The issue I foresee in a hash-to-curve method is that SPAKE2 attempts to use a number of different curves (P256, Curve25519), and these curves have different hash2curve algorithms.

Do we restrict the curves supported?  Do we use different hash2curve algorithms for different curves?  Do we try to use a single hash2curve algorithm that attempts to supports all the curves (possibly suboptimially)?

From: Cfrg <[email-masked]> On Behalf Of Stanislav V. Smyshlyaev
Sent: Wednesday, November 20, 2019 2:43 AM
To: CFRG <[email-masked]>
Subject: [Cfrg] A question to be added to the Round 2 questions list for nominated PAKEs (about SPAKE2)

Dear CFRG,

Best regards,
Stanislav