[curves] The SPEKE Protocol Revisited

[Michael Hamburg]

OK, that makes sense.

What do you think of a KDF that amounts to H(minmax((Alice’s identity,Alice’s message),(Bob’s identity,Bob’s message), shared secret)

where minmax(x,y) = (min(x,y),max(x,y))?  It seems safer than the method you proposed, because it associates Alice’s identity to her message, but the wormhole attack you proposed worked because it confuses who sent which message.

— Mike

> On Sep 29, 2014, at 11:47 AM, Feng Hao <feng.hao at newcastle.ac.uk> wrote:
> 
> 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
>