Re: [Cfrg] Review of the Balanced PAKE proposals

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

Hi Karthink,

Many thanks for your constructive feedback (and the analysis by Bruno). Please refer to my comments below.

“The proposed variant of SPEKE belongs to a long line of well-studied protocols. The specific protocol proposed here is the one by Hao and Shahandashti [1] “

As you rightly point out, there are many variants of SPEKE. Actually I don’t know which exact SPEKE variant was proposed for this selection. In Dan’s submission, he cites [2] IACR 2001/057 for the security proof of SPEKE, but also states the submitted SPEKE is symmetric and allows the parties to initiate the key exchange simultaneously. However, from [2] it should be clear that what was analysed there is essentially a “modified” SPEKE with mandatory key confirmation. The version described in [2] is certainly not symmetric, and the two parties can’t initiate the process simultaneously. It also requires more rounds. What we report in [1] is a limitation in the SPEKE protocol (as specified in Jablon’s original papers and in the IEEE P1363.2 and ISO/IEC 11770-4 standards), namely: the user identity is not cryptographically bound with the key exchange flows,  which gives rises to some authentication issues (unknown key sharing attack). The attacks don’t apply to the variant in [2] as the key confirmation is defined mandatory, but everywhere else (IEEE and ISO/IEC standards) it’s defined as optional. To avoid any confusion, I think it’s best to leave it to Dan Harkins to clarify which exact SPEKE specification he was referring to in the submission.

“This version does not appear to have a proof.”

I would like to refer you to the updated paper that is recently published at IEEE TIFS 2018.

https://arxiv.org/pdf/1802.04900.pdf

As acknowledged in the paper (last paragraph in Section VI), although we analyzed the effectiveness of the proposed countermeasure, we don’t have any reductionist proof. In my personal opinion, it’s impossible to have any reductionist proof based on common assumptions (CDH, DDH etc). There are an unbounded number of ways for the attacker to fabricate data of any format. It seems inevitable that we are stuck with the heuristic security as it is.

“Bruno observes that the above protocol has a reflection-style attack where A can be fooled into thinking it has a session with B although it only has a session with itself.
Suppose A is willing to act as Initiator and Recipient in different sessions …”

I’m not sure if the attack would work though. Please see [1] and the published version above. Kindly note that in concurrent sessions, the party should add an extension to the identity to make it unique. This is explained in both papers. We can take this discussion offline or wait for Dan to clarify which version was submitted so to keep the discussions relevant to this PAKE selection process.

“We wonder whether it would not be better to consider more efficient variants of J-PAKE, as proposed in [7], for example.”

The two variants of J-PAKE in [7] rely on a trusted setup and a hash-to-curve function respectively. The original idea in the J-PAKE construction is exactly to remove these. Indeed, if we reply on either of these, other PAKE protocols would be more desirable.

[4] https://www.dcs.warwick.ac.uk/~fenghao/files/pw.pdf
[5] https://eprint.iacr.org/2010/190.pdf
[6] https://www.normalesup.org/~fbenhamo/files/publications/SP_AbdBenMac15.pdf
[7] https://eprint.iacr.org/2016/379.pdf