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

Greg Hudson <> Tue, 19 May 2015 23:51 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 27F5E1A8724 for <>; Tue, 19 May 2015 16:51:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XnTwyrheQgxX for <>; Tue, 19 May 2015 16:51:30 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CB9B91A8FD5 for <>; Tue, 19 May 2015 16:51:12 -0700 (PDT)
X-AuditID: 12074425-f79ca6d000000e5e-2a-555bcc6f68bc
Received: from ( []) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 84.D1.03678.F6CCB555; Tue, 19 May 2015 19:51:11 -0400 (EDT)
Received: from ( []) by (8.13.8/8.9.2) with ESMTP id t4JNpB3K024033; Tue, 19 May 2015 19:51:11 -0400
Received: from [] ( []) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id t4JNp7dh019957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 19 May 2015 19:51:09 -0400
Message-ID: <>
Date: Tue, 19 May 2015 19:51:07 -0400
From: Greg Hudson <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Watson Ladd <>
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJIsWRmVeSWpSXmKPExsUixCmqrZt/JjrU4PM/PYujm1exWPR0nmRz YPLYOesuu8eSJT+ZApiiuGxSUnMyy1KL9O0SuDKenfjCXDBNumJ/yz7GBsZlol2MnBwSAiYS W7etZoOwxSQu3FsPZHNxCAksZpLYMqmPEcLZyChxdPNRqMwRJok5dy+ygLTwCqhJfH01l72L kYODRUBV4tqqWpAwm4CyxPr9W8FKRAXCJKb9fs4KUS4ocXLmE7C4iIC6xITlm8BsZgFhiQvb 94LVCAtESCy+dJ4JYtdERonpz14ygyQ4BQIl1j7YxwzRoC7xZ94lKFteonnrbOYJjIKzkOyY haRsFpKyBYzMqxhlU3KrdHMTM3OKU5N1i5MT8/JSi3Qt9HIzS/RSU0o3MYJCmN1FdQfjhENK hxgFOBiVeHhPHIoOFWJNLCuuzD3EKMnBpCTKe+M4UIgvKT+lMiOxOCO+qDQntfgQowQHs5II 76yZQDnelMTKqtSifJiUNAeLkjjvph98IUIC6YklqdmpqQWpRTBZGQ4OJQlet9NAjYJFqemp FWmZOSUIaSYOTpDhPEDDJUBqeIsLEnOLM9Mh8qcYFaXEeXVAEgIgiYzSPLheWIp5xSgO9Iow ryxIFQ8wPcF1vwIazAQ02GRbJMjgkkSElFQDI0/coXMn862DrWRDX1Ru+6Rz/ZfFxV/cv5+c NO4V59TYl7jbW6d38p+EF1rTdb7VNl2KvnSk1DDrhZHfy/PiOTdPHWAr7q2/XRYgaVRjyjXH dI7LjLbiWluj7cIbzM94Cl4Nl+MzLWU/sPqjraPtkS33DordnmjuvTiaz/foz0eNKw6ua19W psRSnJFoqMVcVJwIAGls+34MAwAA
Archived-At: <>
Subject: Re: [kitten] SPAKE preauth: generation of SPAKE2 secret input (proposed text)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 19 May 2015 23:51:32 -0000

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.