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

[Nico Williams <[e-mail]>]

On Sat, Dec 01, 2018 at 05:10:04PM -0500, Greg Hudson wrote:
> 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.

That's quite fair.

Speaking of SPAKE2+, I said draft-ietf-kitten-krb-spake-preauth uses
SPAKE2+, but it's SPAKE2.  I'm wondering how to extend krb-spake-preauth
to use SPAKE2+ some day.  I think we might need to overload the group ID
to mean {PAKE, group} rather than just {group}.  But we can do that some
time in the future.

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

Can you explain this a bit more, that is, how hash-to-curve leaks a bit?

A leak of one bit per-exchange is absolutely disastrous if it means that
with each exchange an eavesdropper can eliminate half the passwords in
their dictionary, as then observing N exchanges lets you eliminate all
but 2^-N of passwords in your dictionary.

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

OK.

Nico
--