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

Nico Williams <> Tue, 19 May 2015 19:02 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C96C81A9071 for <>; Tue, 19 May 2015 12:02:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id c4YzRvgqrxfY for <>; Tue, 19 May 2015 12:02:22 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 71D6F1AD0A4 for <>; Tue, 19 May 2015 12:01:12 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 130C0584078; Tue, 19 May 2015 12:01:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to;; bh=DPBFowv8YUu8+c 75r53j/TzjDMs=; b=N007dvDBuyMX3pJM5Zt6BmW9+9ROTKdx8iRO1oMKNTu8+K Dz1MEObKB6hPxZM5B81AFbGvzBLu4CLDgJHkOZbqRM+fbS3cnh+5uTjzdPnzZLBJ luan7fJbNNW9xVqRkqQox6s6T2gJ3L7e9Fj+btYcKf17ENEgFnF+iQMSoiB7I=
Received: from localhost ( []) (Authenticated sender: by (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 <>
To: Greg Hudson <>
Message-ID: <20150519190109.GM9922@localhost>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.21 (2010-09-15)
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 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.


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

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.