Subject: Re: [Cfrg] New Version Notification - draft-irtf-cfrg-spake2-01.txt

From: Evgeny Alekseev <[email-masked]>
Date: Tue, 17 Feb 2015 14:54:02 +0300

Hello!
Could you explain is it really crucial "to combine K with the values
transmitted and received" or for example it is enough to simply hash K with
some random seed by B followed by sending this seed to A? It is clear that
hash function is nessecary here, but not clear about additional parameters.
Could you maybe point to some attack which is possible in case if we simply
hash K without any additional values.
Thank you!

Kind regards,
Evgeny Alekseev, PhD
Moscow State University, Faculty of Computational Mathematics and Cybernetics

---

From: Michael Hamburg <[email-masked]>
Date: Tue, 17 Feb 2015 09:42:14 -0800

Hello Evgeny,

Hashing the protocol transcript is useful both for preventing subtle attacks and for proving the security of the protocol.  It means that an attacker cannot modify messages on the wire without changing the outcome of the protocol.

In the case of SPAKE2, it is necessary to hash the identities A and B, so that an attacker cannot (for example) reroute your connection to a different server or a different username if you are using the same password for both.  It is standard practice to hash the lengths of variable-length objects, to ensure that there are no collisions in the *input* to the hash function; since Watson has not (I believe) specified that curve points must have a fixed-length encoding, he has put the lengths there as well.

As for changing S and T, it prevents an attacker from changing Alice’s and Bob’s messages.  I’m not sure of a complete attack.  One possibility would be that an attacker who knows/guesses the password can cause the key exchange to go through with a known weak key by changing Alice’s message to wM and Bob’s to wN, causing H(A,B,0) to come out.  This is slightly stronger than a man-in-the-middle attack, because if the participants later carry out a TCPCrypt-like protocol which can see the underlying session key, it will not be disrputed as it would for a man-in-the-middle attack, even though the adversary can decrypt the session data.  This probably breaks the formal design goals of the key exchange, but it depends on the model you choose.

I don’t know of a stronger attack on SPAKE2-without-hashing-ST, but it’s nice to be able to prove that one doesn’t exist.  In fact, the original SPAKE2 also hashes the password-hash w for reasons that are only related to the proof of security.

— Mike

> On Feb 17, 2015, at 3:54 AM, Evgeny Alekseev <[email-masked]> wrote:
> 
> Hello!
> Could you explain is it really crucial "to combine K with the values transmitted and received" or for example it is enough to simply hash K with some random seed by B followed by sending this seed to A? It is clear that hash function is nessecary here, but not clear about additional parameters. Could you maybe point to some attack which is possible in case if we simply hash K without any additional values.
> Thank you!
> 
> Kind regards, 
> Evgeny Alekseev, PhD
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/cfrg

---

From: Watson Ladd <[email-masked]>
Date: Tue, 17 Feb 2015 10:10:14 -0800

On Feb 17, 2015 9:42 AM, "Michael Hamburg" <[email-masked]> wrote:
>
> Hello Evgeny,
>
> Hashing the protocol transcript is useful both for preventing subtle
attacks and for proving the security of the protocol.  It means that an
attacker cannot modify messages on the wire without changing the outcome of
the protocol.
>
> In the case of SPAKE2, it is necessary to hash the identities A and B, so
that an attacker cannot (for example) reroute your connection to a
different server or a different username if you are using the same password
for both.  It is standard practice to hash the lengths of variable-length
objects, to ensure that there are no collisions in the *input* to the hash
function; since Watson has not (I believe) specified that curve points must
have a fixed-length encoding, he has put the lengths there as well.
>
> As for changing S and T, it prevents an attacker from changing Alice’s
and Bob’s messages.  I’m not sure of a complete attack.  One possibility
would be that an attacker who knows/guesses the password can cause the key
exchange to go through with a known weak key by changing Alice’s message to
wM and Bob’s to wN, causing H(A,B,0) to come out.  This is slightly
stronger than a man-in-the-middle attack, because if the participants later
carry out a TCPCrypt-like protocol which can see the underlying session
key, it will not be disrputed as it would for a man-in-the-middle attack,
even though the adversary can decrypt the session data.  This probably
breaks the formal design goals of the key exchange, but it depends on the
model you choose.
>
> I don’t know of a stronger attack on SPAKE2-without-hashing-ST, but it’s
nice to be able to prove that one doesn’t exist.  In fact, the original
SPAKE2 also hashes the password-hash w for reasons that are only related to
the proof of security.

I did fix that omission earlier, then reintroduced this mistake in this
version.

I've tried as much as possible to simplify the work of the cryptanalysist
when analysing a protocol using this draft.  There's no need to check how
points are encoded, as any encoding will work. Likewise, ensuring that we
stick to a provably secure protocol eliminates certain classes of attack.

Some variations like the newly introduced symmetric one don't yet have
published proofs, or our dealing with cofactors. This will be fixed.

Sincerely,
Watson Ladd