[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cfrg
Subject:    Re: [CFRG] Symmetric SPAKE2
From:       Watson Ladd <watsonbladd () gmail ! com>
Date:       2021-04-27 4:04:39
Message-ID: CACsn0c=iL_HLMidJoL9eUqmzcTumiNTZZ+7vRXNTea1geeBK7Q () mail ! gmail ! com
[Download RAW message or body]

On Mon, Apr 26, 2021 at 6:20 PM Filippo Valsorda <filippo@ml.filippo.io> wrote:
>
> Hi all,
>
> I am trying to figure out the properties of symmetric SPAKE2, where there is no
> ordering and M = N.
>
> The only note I can find in draft-irtf-cfrg-spake2-18 is this in Section 5.
>
>    In addition M and N may be equal to have a symmetric variant.  The
>    security of these variants is examined in [MNVAR].  This variant may
>    not be suitable for protocols that require the messages to be
>    exchanged symmetrically and do not know the exact identity of the
>    parties before the flow begins.
>
> https://tools.ietf.org/html/draft-irtf-cfrg-spake2-18#section-5
>
> I interpret "these variants" as the ones with M = N, and "This variant" as the
> "Per-User M and N" one, meaning this paragraph is saying that you can't do
> per-user M and N if M = N, which tracks.
>
> However, the spec is hardcoding M and N to different values, so it doesn't
> actually seem to allow M = N variants at all. Should that be addressed?

"These variants" is supposed to be M=N where you pick the point or the
per user one.
>
> I looked at [MNVAR] for a proof of the security of M = N, but I noticed its
> proofs involve UC and a sid. Does that sid have uniqueness requirements that can
> only be satisfied with a full round-trip, like the one involved in the CPace
> proof we discussed a couple weeks ago? In that case I think it wouldn't apply to
> deployed uses of symmetric SPAKE2 like Magic Wormhole.

Look in the Supplemental Material, Game Based Proofs for SPAKE2.

Sincerely,
Watson Ladd

-- 
Astra mortemque praestare gradatim

_______________________________________________
CFRG mailing list
CFRG@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg
[prev in list] [next in list] [prev in thread] [next in thread]