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:[email protected]] >Sent: 29 September 2014 19:11 >To: Feng Hao >Cc: [email protected] >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 <[email protected]> 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 >> [email protected] >> https://moderncrypto.org/mailman/listinfo/curves _______________________________________________ Curves mailing list [email protected] https://moderncrypto.org/mailman/listinfo/curves
