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

Greg Hudson <ghudson@mit.edu> Tue, 19 May 2015 23:51 UTC

Return-Path: <ghudson@mit.edu>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27F5E1A8724 for <kitten@ietfa.amsl.com>; Tue, 19 May 2015 16:51:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XnTwyrheQgxX for <kitten@ietfa.amsl.com>; Tue, 19 May 2015 16:51:30 -0700 (PDT)
Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB9B91A8FD5 for <kitten@ietf.org>; Tue, 19 May 2015 16:51:12 -0700 (PDT)
X-AuditID: 12074425-f79ca6d000000e5e-2a-555bcc6f68bc
Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 84.D1.03678.F6CCB555; Tue, 19 May 2015 19:51:11 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id t4JNpB3K024033; Tue, 19 May 2015 19:51:11 -0400
Received: from [18.101.8.169] (vpn-18-101-8-169.mit.edu [18.101.8.169]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (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: <555BCC6B.9070409@mit.edu>
Date: Tue, 19 May 2015 19:51:07 -0400
From: Greg Hudson <ghudson@mit.edu>
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 <watsonbladd@gmail.com>
References: <x7dk2wd6355.fsf@equal-rites.mit.edu> <555B6176.2000906@mit.edu> <CACsn0cm+6JisrBgR0-zbU86_6n_2p8DcWabWA7W1ZnX8=wuhgA@mail.gmail.com>
In-Reply-To: <CACsn0cm+6JisrBgR0-zbU86_6n_2p8DcWabWA7W1ZnX8=wuhgA@mail.gmail.com>
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: <http://mailarchive.ietf.org/arch/msg/kitten/Uu2Na1xHu50-nBmMs_4VoosGZIo>
Cc: kitten@ietf.org
Subject: Re: [kitten] SPAKE preauth: generation of SPAKE2 secret input (proposed text)
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=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.