Re: [Cfrg] Removing the magic constants from SPAKE2

[Bodo Moeller <[e-mail]>]

>
>
> However, the protocol is considered problematic (and is out of favor with
> CFRG) in large part because of the magic curve points M,N.  The discrete
> logs of these points would be a backdoor in SPAKE2, so care must be taken
> to ensure that M,N are generated at random.
>
> However, there’s another way to do SPAKE2, which doesn’t need magic curve
> points.  Instead, M^hash(password) and N^hash(password) can be replaced
> with Elligator(hash(“M to the”, password)) and Elligator(hash(“N to the",
> password)).  This obviously achieves the same bounds in the ROM.
>

I like this idea.

For purposes of standardization, instead of generating those "magic" SPAKE2
base points randomly using unbiased US dollar coins in some other agency's
back room, I'd expect you'd be using "verifiably pseudorandom" points based
on some seed (which shouldn't be an unacceptable leap of faith if you're
already relying on the Random Oracle Model for your security proofs), but
using Elligator to obtain proper mask values more directly seems like a
good alternative.


Furthermore, if a completely symmetric PAKE is desired, there’s nothing
> really wrong with setting these two blinding factors to the same value.
>  That is, they can both be M^hash(password) or Elligator(hash(“M to the”,
> password)).  The disadvantage is in the proof: the proof will now be based
> on “CDH squaring” instead of regular CDH, i.e. computing g^(x^2) from
> (g,g^x).  Because of quarter-squares the two problems are equivalent, but
> it changes the epsilon^2 in SPAKE to an epsilon^4.  This isn’t a huge deal,
> and if you prefer stronger proof frameworks like Kudla-Patterson’s GapDH
> trick, then it doesn’t change the bounds at all.
>

Note that there's also a SPAKE variant called SOKE, which only masks one of
the DH shares in the first place (
http://www.bmoeller.de/pdf/soke-asiaccs2006.pdf; this was *meant* for TLS,
but due to patent concerns at the time was soon replaced by a thoroughly
gimmicky protocol that you don't really want to know about, and hence the
I-D was never completed).



> * Is the completely symmetric PAKE desirable?
> * Is SRP-style augmentation desirable?  Should it be optional?


By "SRP-style" augmentation I think you mean a verifier-based PAKE in
general, right?  ("Verifier-based" = the password information as held by
the server cannot be used to impersonate the client to other server
instances, and is rather merely a verifier to check that the client holds
such information.  I don't like the term "augmented" for this because it
appear to refer to an implementation detail of certain solutions, notably
the original Bellovin-Merrit Augmented EKE.)

I think having a verifier-based protocol is highly desirable, but that this
can be optional if that's sufficiently justified by efficiency advantages.

Bodo