SPAKE2 comparison

[chris-wood]

From @cjpatton

Comparison to the SPAKE2 spec

• SPAKE2 is more prescriptive about key confirmation:

  This confirmation message cA is computed as a MAC over the protocol transcript TT using KcA, as follows: cA = MAC(KcA, TT). Similarly, B MUST send A a confirmation message using a MAC computed equivalently except with the use of KcB.

  I think SPAKE2+ should follow suit.

• SPAKE2 and SPAKE2+ use the same fixed points M, N. I think this is a good idea because it means the implementations of the two protocols can share code. However, an argument can be made for generating different fixed points for SPAKE2+: Finding the discrete log for a fixed point in one protocol does not lead to a break in the other. I think SPAKE2+ could address this argument in Security Requirements, but I wouldn't make a protocol change for this.

• The definitions of the fixed points and the algorithm for generating them are identical in both drafts (or at least they should be, I haven't checked closely). I'd suggest removing these sections from the SPAKE2+ draft and just referring to SPAKE2. (Or vice versa, depending on which gets published first.)

[chris-wood]

@cjpatton I don't understand your comment about the key confirmation being less prescriptive than SPAKE2. Is the generation of each confirmation message not clear? Something else?

The other comment about shared fixed points makes sense. I think generating different points is the way to go. @ttaubert, thoughts?

[cjpatton]

From draft-04 (maybe I should be looking at the latest, unpublished version?):

[In case a MAC is used for key confirmation], KcA and KcB are symmetric keys used to compute tags cA and cB over data shared between the participants. That data could for example be an encoding of the key shares exchanged earlier, or simply a fixed string.

cA = MAC(KcA, ...) cB = MAC(KcB, ...)

I.e, this draft doesn't tell you what to MAC, whereas the SPAKE2 draft tells you exactly what to MAC (TT).

[chris-wood]

Got it -- thanks for clarifying!

[chris-wood]

@ttaubert I suggest we simply MAC the entire transcript for the confirmation message. If you agree, could you please send a PR?

[chris-wood]

Also, regarding M and N, we can update their generation method (and test vectors) by domain separating the hash for SPAKE2+ and SPAKE2. @ttaubert would you be OK with this change?

[ttaubert]

@ttaubert I suggest we simply MAC the entire transcript for the confirmation message. If you agree, could you please send a PR?

As proposed in #20, I think we should stick to MAC-ing the key shares as shown in our test vectors.

See also #3, encoding the transcript TT can be done incrementally. That would likely be harder for the key confirmation as I think most MAC APIs will require the confirmation key upfront, which itself is derived from TT.

[ttaubert]

Also, regarding M and N, we can update their generation method (and test vectors) by domain separating the hash for SPAKE2+ and SPAKE2. @ttaubert would you be OK with this change?

This should be covered by the change in #23 as well.