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

[Nico Williams <[e-mail]>]

On Tue, May 19, 2015 at 12:14:46PM -0400, Greg Hudson wrote:
> 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.

Notionally each curve should have its own conversions.

> * 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.

Sure.

> * 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.

We do have to specify what this conversion is.  We can't merely refer to
OpenSSL.

If need be use w' = truncate(H(w), floor(log2(group_order / cofactor))).
We don't need w or w' to be particularly strong (that's the point of
using a PAKE), so this should be just fine.

> * 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.

Agreed.

Nico
--