Re: [Cfrg] I-D Action: draft-irtf-cfrg-spake2-06.txt

[Greg Hudson <[e-mail]>]

On 12/01/2018 04:10 PM, Nico Williams wrote:
>     But in SPAKE2 we have X=x*G and T=w*M+X, while in SPAKE2+ we have
>     X=x*G+w0*M, but X is not reused in the text in SPAKE2.
[...]
>          A picks x randomly and uniformly from the integers in [0,ph)
>      -   divisible by h, and calculates X=x*G and T=w*M+X, then transmits T to
>      +   divisible by h, and calculates X=w*m+x*G, then transmits X to
>          B.

This change would have some minor downstream ripples:

* draft-ietf-kitten-krb-spake-preauth contains X, Y, T, and S values in 
its test vectors.

* MIT krb5's shipped implementation of the above draft uses T and S in 
comments and variable names.

While those are fixable without any interop impact, my preference is to 
change the SPAKE2+ terminology rather than the SPAKE2 terminology.  I 
also think it is mildly useful to have separate names for the unmasked 
and masked DH points.

The other SPAKE2 implementation I am aware of (BoringSSL's, which isn't 
draft-conformant for reasons having to do with M and N generation and 
cofactors) uses P and Pstar as variable names, so wouldn't really be 
affected.

>     SPEKE/B-SPEKE would have made implementation easier by requiring only
>     scalar point multiplication, thus enabling cheap curve25519
>     implementations.

I know that in discussions of PAKE algorithms for Kerberos, we wanted to 
avoid requiring hash-to-curve if possible.  From what I can find online, 
if you use SPEKE with curve25519 and simply hash to the x coordinate, 
you leak one bit of the hashed password, which isn't necessarily a huge 
problem but isn't an attractive property.

I believe I wound up with a SPAKE2-edwards25519 implementation based on 
the BoringSSL 25519 code which is pretty competitive with X25519 
implementations, although I don't have test results handy.  Point 
addition and subtraction are not expensive operations; they're just not 
necessarily part of a crypto API geared towards X25519 or ed25519.  But 
neither is hash-to-curve.