[curves] SPAKE2 and SPAKE2 Elligator Edition
mike at shiftleft.org
Thu Feb 19 09:34:45 PST 2015
On 02/19/2015 02:41 AM, Michael Scott wrote:
> Just to be clear, I am talking about this Abdalla paper
> 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
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.
[context removed, because the list autorejects messages > 40kB; thanks Trevor]
More information about the Curves