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

Watson Ladd <> Tue, 19 May 2015 19:09 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 433D01AD0AC for <>; Tue, 19 May 2015 12:09:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eIj2uVE6-6pX for <>; Tue, 19 May 2015 12:09:22 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4C4241AD0A6 for <>; Tue, 19 May 2015 12:09:22 -0700 (PDT)
Received: by wgjc11 with SMTP id c11so28857694wgj.0 for <>; Tue, 19 May 2015 12:09:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=db7V2D7fIpNPc410mAb6LQlIL5r7c13Rb4qFNzdyeWI=; b=feFW1jusWOjigY7wCtkGMjijsi5+lt8sNDDG/MhBRJLyMzavR7BxeMB5ipcwo4gyUJ +L0CYuhe/wA+BJ3CMKgwqHc1T671Qe5j5CLC4TwQTZj2xTIQr4V4QNNxTBz8PeohhbMs nwGShLf26SNWc5YOlaCUTRAejTiNvJKN7LWzBriNo30bUOsqG61SNeurDtZwt4E3hes2 nllcfxhIYrs8ARAXHnIgrcM5qF+QG/f79+xhTvO6qrNH38Go/pePB2/JkA+xFqBHRJWP dz0uXNEijcJJ2RJAbkR5v/cphT4HDE7a2FWeokVlhiX6G2+oHutec7PSModhoOUwddLU PnSQ==
MIME-Version: 1.0
X-Received: by with SMTP id fs13mr34729786wic.26.1432062561044; Tue, 19 May 2015 12:09:21 -0700 (PDT)
Received: by with HTTP; Tue, 19 May 2015 12:09:20 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Tue, 19 May 2015 12:09:20 -0700
Message-ID: <>
From: Watson Ladd <>
To: Greg Hudson <>
Content-Type: text/plain; charset=UTF-8
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:09:24 -0000

On Tue, May 19, 2015 at 9:14 AM, Greg Hudson <> wrote:
> Based on the results of this discussion, here is the wording I came up
> with for my pull request.  In the prerequisites section:
>    Both KDCs and clients MUST implement one or more groups for which the
>    discrete logarithm problem is hard, each with an corresponding object
>    identifer.  Group object identifiers MUST refer to one of the
>    following:
>    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.

> and then in a new section titled "SPAKE Parameters and Conversions":
>    The SPAKE algorithm requires a shared secret input w to be used as a
>    scalar multiplier (see [I-D.irtf-cfrg-spake2] section 2).  This value
>    MUST be produced from the client principal's long-term key as
>    follows:
>    1.  Determine a scalar octet string input length for the chosen
>        group.  For SEC 2 curves over a prime field F(p), this is
>        ceil(log2(p)/8).  For other groups, this length is specified by
>        the group.
>    2.  Produce an octet string of the above length with PRF+(K,
>        "SPAKEsecret"), where K is the long-term key and PRF+ is defined
>        in [RFC6113] section 5.1.
>    3.  If the chosen group is secp521r1, set the high seven bits of the
>        first byte to 0 so that there are at most 521 significant bits in
>        the octet string.
>    4.  For SEC 2 curves, decode the octet string as a big-endian
>        positive integer as specified in [SEC1] section 2.3.8.  For other
>        groups, decode the octet string as specified by the group.

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

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

OIDs are not unique per object.

> * 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.
> * The w values won't be uniformly distributed even if the long-term key
> is.  But as Watson noted, SPAKE doesn't assume that w is uniformly
> distributed.
> * 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.

The easy fix here is to truncate.
> * 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.