Subject: [Cfrg] comments on draft-irtf-cfrg-spake2-02.txt

From: "Dan Harkins" <[email-masked]>
Date: Tue, 18 Aug 2015 10:57:30 -0700 (PDT)

Hi Watson,

  (Sorry for the resend, I fat-fingered CFRG in my original
email to you).

  I have a few comments on the latest SPAKE2 draft. A few
trivial ones are:

  - if you refer to SEC1 (section 2.1) you should make it an
    Normative reference.

  - the parties are A and B (as mentioned in "Setup"). SPAKE2+
    should refer to A and B like SPAKE2 does and not Alice and
    Bob, either that or generate K' with "Alice" and "Bob".

  - I assume that in SPAKE2+ L = w1*G, where G is the generator.

  - there needs to be some RFC 2119 words (and a normative reference
    to RFC 2119), especially in section 3 which is crucial for
    interoperation. Anyplace where you say "this is critical for
    security" or "it is essential that..." needs to be reworded to
    include "MUST".

  - the comment about verifying received points should be in the
    protocol descriptions (sections 2.2 and 2.3) when points are
    received by A and B and not just in the Security Considerations
    (section 4).

  But a larger problem is the algorithm to determine M and N in
section 3. I was unable to reproduce M and N for any of the
curves you've given examples for. You say, "The initial segment
of bytes of length equal to that of an encoded group element is
taken, and is then formatted as required for the group." That
is very ambiguous. In fact, the whole process is ambiguous and
open to too much interpretation to guarantee interoperability.

  - what's the format? In section 2.1 you say "common choices would
    be SEC1 uncompressed for elliptic curve groups" but then you
    set the first byte to 0x02 which implies that compressed form
    is used and the bit is always 0. Yet some of the points, e.g.
    N for P256, begin with 0x03 which implies the bit is 1. What
    is it?

  - Since you're repeatedly rehashing the output the specific number
    of bytes used as "the initial segment of bytes" is critical.
    "[L]ength equal to that of an encoded group element" depends
    on the encoding and if one guy tried compressed and the his peer
    tried uncompressed (both valid encodings) they would not generate
    the same points and fail to interoperate.

  - when you say "set the first byte to 0x02" you don't mean overwrite
    the value of the first byte (which is what it implies). You mean
    prepend the string with 0x02, right? And then try and see whether
    it can be uncompressed?

  - the point generation scheme should not depend on an _output_
    point format. There's no reason to do any prepending of 0x02.
    Just hash out enough bits for x, see if there's a solution to
    the equation for the curve, and choose some way to select the
    bit (e.g. the value of the low-order bit of the first hash of
    the string). Then you can output 0x02... or 0x03... as the
    case may be.

  - I used the phrase "1.2.840.10045.3.1.7 point generation seed (M)"
    to find M for p256. You provide what seems like a compressed point
    with the bit set to 0 and the x coordinate = 0x886e2f97.... yet
    I did 20 repeated hashings (hashing the output again) and never
    got that. I actually found a point on the 3rd hash that came out
    as 0x68a373f108.... Compressed, bit=0: 0x0268a373f108.... Didn't
    work for p384 or p521 either.

  And a few suggestions:

  - You might think about publishing the code you're using to generate
    M and N as an appendix.

  - Generate M and N for a good finite field group, don't just do
    ECC. I suggest the 4096-bit group from RFC 3526 but I don't
    know if there's an OID for that and your scheme seems to require
    an OID.

  - You mention Ed25519 in the table of points but you don't include
    points for it.

  regards,

  Dan.