[curves] The SPEKE Protocol Revisited

[Feng Hao]

Hi Mike,

It is not because SPEKE is symmetric (e.g., J-PAKE is also symmetric, but not subject to this attack), but because of a lack of entity identifier that causes unknown-key sharing. If you include entity identifiers into the key confirmation, then the attack can be prevented. However, the key confirmation is optional, as stated in IEEE and ISO/IEC standards. The patch we propose in the paper is to include entity identifiers into the key computation function. So the key confirmation remains optional.

I just had a look at the latest version of Dragonfly (04). I am not too sure if the key confirmation defined in the document is mandatory; if it is, then the attack will not work. 

But on the other hand, from the protocol design's point of view, it's a bit strange to see the key confirmation defined as "mandatory", as it makes the protocol less flexible for applications where round efficiency is critical (explicit key confirmation requires extra rounds). A well-designed authenticated key exchange protocol should remain secure even without explicit key confirmation (i.e., relying on implicit key confirmation only). 

Cheers,
Feng

>-----Original Message-----
>From: Michael Hamburg [mailto:mike at shiftleft.org]
>Sent: 29 September 2014 19:11
>To: Feng Hao
>Cc: curves at moderncrypto.org
>Subject: Re: [curves] The SPEKE Protocol Revisited
>
>Thanks for this, Feng.
>
>The wormhole attack appears to be based almost entirely on the fact that
>SPEKE is symmetric and doesn’t include party identities in the key
>confirmations.  Does it therefore also apply to Dragonfly, since Dragonfly is
>also symmetric and is very similar to SPEKE?  Or is Dragonfly’s key confirmation
>somehow protected?
>
>Cheers,
>— Mike
>
>> On Sep 29, 2014, at 6:48 AM, Feng Hao <feng.hao at newcastle.ac.uk> wrote:
>>
>> Hi,
>>
>> To those who are interested in PAKE, we publish some new security analysis
>results about SPEKE.
>>
>> https://blogs.ncl.ac.uk/security/2014/09/29/the-speke-protocol-revisited/
>>
>> Any comments are welcome.
>>
>> Regards,
>> Feng
>>
>> _______________________________________________
>> Curves mailing list
>> Curves at moderncrypto.org
>> https://moderncrypto.org/mailman/listinfo/curves