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

[Greg Hudson <[e-mail]>]

On 05/19/2015 03:09 PM, Watson Ladd wrote:
>>    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.

I've been operating under the assumption that M and N can be computed
for other curves as long as they have assigned OIDs.  The risk of
interoperability failures from people getting it subtly wrong might be
kind of high, though.

I don't have an objection if we want to limit ourselves to curves
explicitly listed in the spake2 document (or follow-on SPAKE2
documents), but it's a greater departure from Nathaniel's intent.

F2m curves (I assume that's what you mean by "binary curves") are
documented in SEC 2 section 3, not in section 2.  I don't think we need
to support those.

>>    1.  Determine a scalar octet string input length [...]
>>    2.  Produce an octet string of the above length with PRF+ [...]
>>    3.  If the chosen group is secp521r1, set the high seven bits [...]
>>    4.  For SEC 2 curves, decode the octet string as a big-endian [...]

> 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)

There's RFC 6979 section 3.2, but it would introduce a significant side
channel if applied here.

I would be happy to delegate steps 3 and 4 to another document if there
is a suitable reference.

>> [...] 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.

Can you elaborate on this?

>> * A small proportion of w values will be larger than the group order.
>> Implementations need to be able to handle these values [...]

> The easy fix here is to truncate.

You mean lop off the high bit?  We could do that, but I'm not sure if
it's needed.  I think 25519's scalar preprocessing generates scalar
values up to eight times the subgroup order, for comparison.
(2^254+(2^251-1)*8 / 2^252+27742317777372353535851937790883648493 ~= 8.)

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

I'm not referring to OpenSSL for semantics.  Mathematically, scalar
multiplication within a group is defined for any non-negative value of
the scalar.  If an implementation can't handle values above a certain
size, or has side channels for values above a certain size, that is an
implementation limit.  I just brought up OpenSSL as an example of
implementation limits compatible with my proposed method.

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

I'm not sure why we would want to introduce another hash invocation.  w
is already the output of a PRF; we can truncate it to any desired size.