Re: [Cfrg] Using draft-irtf-cfrg-spake2-00 in Kerberos Preauth

[Nathaniel McCallum <[e-mail]>]

On Wed, 2015-01-28 at 13:12 -0500, Nathaniel McCallum wrote:
> On Wed, 2015-01-28 at 08:06 -0800, Watson Ladd wrote:
> > On Wed, Jan 28, 2015 at 7:53 AM, Nathaniel McCallum <
> > [e-mail]> wrote:
> > > I've only just now joined the mailing list, so I'm a bit late to 
> > > the party (though I see my name has been brought up in the 
> > > previous discussions).
> > > 
> > > I am currently implementing a PAKE preauthentication mechanism 
> > > for Kerberos. https://github.com/npmccallum/krb5-pake
> > > 
> > > One of the PAKEs we have chosen to use is SPAKE2. The 
> > > aforementioned program that I am using to generate M and N 
> > > constants is here: 
> > > https://github.com/npmccallum/krb5-pake/blob/master/src/pake/spake_constants.c
> > > 
> > > This program uses two seed strings:
> > >  "OID point generation seed (M)"
> > >  "OID point generation seed (N)"
> > > 
> > > OID is replaced by the OID of the curve. Since some curves have 
> > > multiple aliases, the use of OIDs removes any ambiguity to the 
> > > seed.
> > > 
> > > The method use to generate the constants is fairly similar to 
> > > that used by Chromium, but differs in several ways:
> > > http://src.chromium.org/viewvc/chrome/trunk/src/crypto/p224_spake.cc
> > > 
> > > First, we calculate the length of the encoded value of a single 
> > > point on the curve. I'll call this $CURVE_SIZE.
> > > 
> > > Second, we determine which is the smallest hash function (of SHA-
> > > 1, SHA-2-*) which outputs at least $CURVE_SIZE bytes. So, for 
> > > instance, given P256, SHA-2-256 will be used. If no hash 
> > > function is larger than $CURVE_SIZE, we use the largest hash. 
> > > For example, P521 uses SHA-2-512.
> > > 
> > > Third, we generate the seeds by filling in the OID value.
> > > 
> > > Fourth, we begin a recursive process whereby we hash the seed 
> > > (or the previous hash of the seed) until the output of the hash 
> > > yields an X coordinate on the curve. The Y coordinate (+/-) is 
> > > chosen using the right-most bit of the hash.
> > 
> > I don't think this is what your C code is doing, or if it is, I 
> > can't figure it out because of the way it uses OpenSSL internals.
> > I may try coding that up in SAGE and seeing if it agrees in the 
> > output. (In particular I think the first byte of the digest might 
> > get mangled to have the decode function work).
> 
> What internals?
> 
> EC_GROUP *g = EC_GROUP_new_by_curve_name(NID_secp521r1);
> EC_POINT *p = EC_POINT_new();
> BIGNUM *x = BN_new(hash(seed));
> int y = seed[-1] & 0x1; // Last bit 
> EC_POINT_set_compressed_coordinates_GFp(g, p, x, y);
> 
> That seems straightforward to me.

Attached is a (slightly different) method implemented in Java using 
Bouncy Castle. It depends on no system internals and only one hash. It 
should be sufficiently simple to grok. A description is given in a 
comment in the top of the file. This method is easily repeatable on 
every crypto-system I have tried (including both OpenSSL and libnss).

Nathaniel