Re: [CFRG] Attack on a Real World SPAKE2 Implementation

By the way, they state where the algorithm details came from "This protocol is derived from Dan Boneh and Victor Shoup's cryptography book [https://crypto.stanford.edu/~dabo/cryptobook/BonehShoup_0_4.pdf] (pg 789, 'PAKE2 protocol')." So we should look at that to see how to improve descriptions. I think it's really people not knowing that "hash to curve" or "a random point on the curve" are not normal things and very important. I know of someone who read about "hash to curve" in I think OPAQUE and thought that it was "H(value)*G". So we need to make special notes on these things.

> On 05/09/2021 11:05 AM Björn Haase <bjoern.m.haase@web.de> wrote:
> 
> 
> Hello All,
> 
> 
> 
> I think we should be be careful with biased wordings such as "sharing the blame" and assumptions such as "snake oil" which implies fraudulent intentions.
> IMO, we just don't know all of the details and it might be more constructive not to speculate too much.
> 
> (When writing this: Even though my professional experience taught me to never under-estimate the power of foolishness, I think that it should be considered to be truly remarkable how many things have gone wrong here simultaneously. )
> 
> For the same reason, I don't think that one should be careful of "blaming" the authors of the SPAKE2 for anything that has gone wrong here.
> Regarding possible improvements of the draft I still would like to come up with a suggestion:
> 
> What about adding a clear and *mandatory* specification for conforming implementations of SPAKE2 on any curve on how to generate the "nothing upon my sleeve" inputs M,N? 
> 
> I would recommend mandating a procedure that refers to the current draft version of the h2c draft as it is today. 
> 
> Alternatively, if one would like to avoid references to the h2c draft (in order to make M,N independent of possible future changes in the h2c draft), one could consider using a specification in the style of appendix A in https://eprint.iacr.org/2018/286.pdf, where similar "nothing upon my sleeve" points "A, C" were needed.
> At any rate, I believe that there seems to be need for a mandatory trustworthy way for generating M, N for *any* curve.
> 
> Yours,
> Björn
> P.S.:
> Actually, I just noticed that its not really explicit how the points M, N in the current SPAKE2 draft 18 are calculated for the curves where test vectors are provided. I presume that the uniform h2c map was used for the given seed inputs?
> 
> 
> Am 08.05.2021 um 01:51 schrieb Filippo Valsorda:
> 
> > 2021-05-07 04:17 GMT-04:00 Peter Gutmann <pgut001@cs.auckland.ac.nz>:
> > 
> > > Ruben Gonzalez <in+lists@ruben-gonzalez.de> writes:
> > > 
> > > 
> > > 
> > > >We did not attack SPAKE2 directly, but a faulty implementation.
> > > 
> > > 
> > > 
> > > Nice work! This is an example of what I once referred to as second-order
> > > 
> > > snake oil crypto, good crypto applied badly (first-order is bad crypto).
> > > 
> > 
> > 
> > Snake oil is fraudulent. This is a broken implementation, for which specification authors should at least consider sharing the blame. How did the spec fail the implementers, who presumably were not trying to implement something in a broken way?
> > 
> > 
> > 
> > (I know, I know, SPAKE2 is a draft, not an RFC! But it's been a draft for almost 7 years, and at some point people need to implement stuff.)
> > 
> > 
> > 
> > _______________________________________________
> > CFRG mailing list
> > CFRG@irtf.org
> > https://www.irtf.org/mailman/listinfo/cfrg
> > 
> _______________________________________________ CFRG mailing list CFRG@irtf.org https://www.irtf.org/mailman/listinfo/cfrg