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 <[email protected]> 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:[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
