[curves] SPAKE2 and SPAKE2 Elligator Edition

[Michael Scott]

"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."

And that's where I get stuck. I think its actually perfectly fine to use
the raw EC point form as a session key, if that's what you want to do, and
therefore there is absolutely no need to hash the DH output.

First assume that the attacker can launch a timing attack against both
Alice and Bob, and determine their session keys(as required to apply the
formula). Then the attacker can simply use this same talent every time to
access their keys, hashed or not, and passively eavesdrop their
communication. No need to go after the password. So if the next-layer
protocol is insecure we are broken anyway. Its kinda like saying that if we
are broken, then we are broken.

However I do see that hashing effectively firewalls the PAK protocol from
the failings of the next layer. In particular if the next layer gives up
its session keys, there is no reason that that should reveal the PAK
password. But I would maintain that the PAK protocol itself does not
require hashing.

And for this particular attack to have any significance we have to assume
that it is not so easy (despite what the authors claim), and that it won't
work every time, but it will work at least once, which would be enough to
find the password using the "formula". However I think such an attack is in
fact impractical. Launch timing or other side channel attacks against both
Alice and Bob simultaneously? Get them to encrypt lots of data (enough for
a side-channel attack) and transmit it to each-other without noticing that
the incoming data decrypts as garbage? I don't think so.

Therefore the rest of the paper is predicated on a false assumption. There
is no "easy" attack.

The dubious added value from hashing the DH output may in fact be
outweighed by the extra complexity introduced by using hash functions.

But I think you are right. Hashing is just an artefact introduced to get a
security proof (as long as you are happy with random oracles). However I
would suggest that such a simple protocol hardly needs one, given the
amount of scrutiny it has had.

BTW I would of course hash the EC point along with every other protocol
value I could think of, but only on the basis that it does no harm, and
you end up with something from which its easier to extract session keys.

Thanks for the insight into what "they" were thinking.

Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/curves/attachments/20150219/e90edb87/attachment.html>