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

Nico Williams <nico@cryptonector.com> Tue, 19 May 2015 19:02 UTC

Return-Path: <nico@cryptonector.com>
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 C96C81A9071 for <kitten@ietfa.amsl.com>; Tue, 19 May 2015 12:02:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.034
X-Spam-Level: *
X-Spam-Status: No, score=1.034 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
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 c4YzRvgqrxfY for <kitten@ietfa.amsl.com>; Tue, 19 May 2015 12:02:22 -0700 (PDT)
Received: from homiemail-a32.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 71D6F1AD0A4 for <kitten@ietf.org>; Tue, 19 May 2015 12:01:12 -0700 (PDT)
Received: from homiemail-a32.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTP id 130C0584078; Tue, 19 May 2015 12:01:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=DPBFowv8YUu8+c 75r53j/TzjDMs=; b=N007dvDBuyMX3pJM5Zt6BmW9+9ROTKdx8iRO1oMKNTu8+K Dz1MEObKB6hPxZM5B81AFbGvzBLu4CLDgJHkOZbqRM+fbS3cnh+5uTjzdPnzZLBJ luan7fJbNNW9xVqRkqQox6s6T2gJ3L7e9Fj+btYcKf17ENEgFnF+iQMSoiB7I=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTPA id 55C57584075; Tue, 19 May 2015 12:01:11 -0700 (PDT)
Date: Tue, 19 May 2015 14:01:09 -0500
From: Nico Williams <nico@cryptonector.com>
To: Greg Hudson <ghudson@mit.edu>
Message-ID: <20150519190109.GM9922@localhost>
References: <x7dk2wd6355.fsf@equal-rites.mit.edu> <555B6176.2000906@mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <555B6176.2000906@mit.edu>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/DmgqMTUO6egX5eBr40QPlrZ8mDs>
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 19:02:24 -0000

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