[curves] SPAKE2 and SPAKE2 Elligator Edition

[Mike Hamburg]

On 02/19/2015 02:41 AM, Michael Scott wrote:
>
> Just to be clear, I am talking about this Abdalla paper
>
> http://www.di.ens.fr/~mabdalla/papers/AbPo05a-letter.pdf 
> <http://www.di.ens.fr/%7Emabdalla/papers/AbPo05a-letter.pdf>
>
> And I am referring to the last paragraph in the introduction on page 1 
> (also see figure 1)
>
> They say "this protocol can be easily broken by an active adversary 
> performing a man-in-the-middle attack."
>
> That's what I'm having difficulties with. I don't see that its at all 
> "easy".
>
>
> Mike
>

I think they're assuming that the next-layer protocol is insecure and
reveals the session key, eg by a timing attack.  They're also assuming
that the session key is not hashed at all, and is used in raw EC point
form.  They give a formula to break the password right in the paper on
pages 1-2.  So you should hash the DH output.

You also obviously want to hash the other party's identity, eg to stop
an attacker from redirecting your connection to a different server
where you have the same password.

Someone asked on CFRG about why you might want to hash X* and Y*.  The
best attack I thought of was that an attacker who knows the password
can MITM you in a way that both sides get the same session key (the
identity), but the attacker knows it.  They can do this by setting X*
= M^pw and Y* = N^pw.  In that case, even if the session key's
integrity is confirmed by the higher-level protocol (a la tcpcrypt),
the attacker can still read and modify messages.  If the identity
point is banned as a session key, I don't know an attack.  But I
haven't thought very hard about this; maybe there's even an attack
which reveals the password.

Overall, though, hashing the protocol transcript is a small price to
pay for a security proof.  It'll cost maybe a few % of the total
computation.  And it's a standard technique: most other protocols have
parties either hash, MAC or sign the transcript for the same reasons.

-- MikeH

[context removed, because the list autorejects messages > 40kB; thanks Trevor]