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

[Björn Haase <[e-mail]>]

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 <[e-mail]
> <mailto:pgut001%40cs.auckland.ac.nz>>:
>> Ruben Gonzalez <[e-mail]
>> <mailto:in%2Blists%40ruben-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
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg