Re: [kitten] SPAKE preauth: generation of SPAKE2 secret input (proposed text)

[Watson Ladd <[e-mail]>]

On Tue, May 19, 2015 at 9:14 AM, Greg Hudson <[e-mail]> wrote:
> Based on the results of this discussion, here is the wording I came up
> with for my pull request.  In the prerequisites section:
>
>    Both KDCs and clients MUST implement one or more groups for which the
>    discrete logarithm problem is hard, each with an corresponding object
>    identifer.  Group object identifiers MUST refer to one of the
>    following:
>
>    o  One of the eight elliptic curves specified in [SEC2] section 2,
>       using the corresponding object identifier from appendix A.2.1.
>
>    o  A group with an unambiguous specification for representing group
>       elements as octet strings, and an unambiguous specification for
>       converting an octet string of a specific length into an integer
>       for use as a scalar multiplier.

My draft does not have M and N for binary curves. There are only three
curves in my draft IIRC. My draft completely describes each parameter,
and gives it a name.

>
> and then in a new section titled "SPAKE Parameters and Conversions":
>
>    The SPAKE algorithm requires a shared secret input w to be used as a
>    scalar multiplier (see [I-D.irtf-cfrg-spake2] section 2).  This value
>    MUST be produced from the client principal's long-term key as
>    follows:
>
>    1.  Determine a scalar octet string input length for the chosen
>        group.  For SEC 2 curves over a prime field F(p), this is
>        ceil(log2(p)/8).  For other groups, this length is specified by
>        the group.
>
>    2.  Produce an octet string of the above length with PRF+(K,
>        "SPAKEsecret"), where K is the long-term key and PRF+ is defined
>        in [RFC6113] section 5.1.
>
>    3.  If the chosen group is secp521r1, set the high seven bits of the
>        first byte to 0 so that there are at most 521 significant bits in
>        the octet string.
>
>    4.  For SEC 2 curves, decode the octet string as a big-endian
>        positive integer as specified in [SEC1] section 2.3.8.  For other
>        groups, decode the octet string as specified by the group.

I feel as though I should rework the draft to specify the length of an
octet string and how to treat it, but I think this was already done
elsewhere. (I.e. step 2 would need to be done, but all others in my
draft)

>
> Salient points:
>
> * SEC 2 curves over Fp (which include NIST P-256/P-384/P-521) get to use
> existing OIDs with conversions specified in this draft, using SEC 1
> encoding primitives.  Other groups need to use an OID which
> unambiguously specifies the needed conversions.  I expect the
> forthcoming CFRG curves to slot in here, although I'm not sure if they
> plan to designate OIDs for their curves.

OIDs are not unique per object.

>
> * Because the eight SEC 2 curves all have cofactor 1, we don't have to
> worry about cofactors in the conversions we specify.  Except for
> secp521r1, they all use primes close to a power of 2^8.
>
> * The w values won't be uniformly distributed even if the long-term key
> is.  But as Watson noted, SPAKE doesn't assume that w is uniformly
> distributed.
>
> * A small proportion of w values will be larger than the group order.
> Implementations need to be able to handle these values correctly and
> without side channels.  I will try to make a note of this in the
> security considerations, and will try to make sure that there are test
> vectors exercising this possibility.  OpenSSL contains P-256 and P-521
> implementations which are supposed to be constant-time if the input
> bignum doesn't contain more than 256 or 521 significant bits respectively.

The easy fix here is to truncate.
>
> * It's possible, though vanishingly unlikely, for w to be equal to 0 or
> to the group order.  I believe all of the computations should work in
> this case, so there is no need to reject those values.