[curves] SPAKE2 and SPAKE2 Elligator Edition

[Watson Ladd]

On Feb 19, 2015 12:19 PM, "Michael Scott" <mike.scott at certivox.com> wrote:
>
> "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.

Read the literature on UC and you will find plenty of simple protocols that
compose in unexpected ways.

To prevent this we use security definitions that modularize protocol design
so that an analyst doesn't have to understand the entire design at once but
rather each piece in isolation.

Sincerely,
Watson Ladd
>
> Mike
>
>
>
> _______________________________________________
> Curves mailing list
>Curves at moderncrypto.org
>https://moderncrypto.org/mailman/listinfo/curves
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/curves/attachments/20150219/60137907/attachment.html>