Re: [Cfrg] SPM2 -> was Re: SPAKE2+mbDH a PAKE+PKA
"Stanislav V. Smyshlyaev" <smyshsv@gmail.com> Wed, 05 October 2016 05:55 UTC
Return-Path: <smyshsv@gmail.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 305DC126FDC for <cfrg@ietfa.amsl.com>; Tue, 4 Oct 2016 22:55:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CwMyWOMES517 for <cfrg@ietfa.amsl.com>; Tue, 4 Oct 2016 22:55:34 -0700 (PDT)
Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 157F0126B6D for <cfrg@irtf.org>; Tue, 4 Oct 2016 22:55:34 -0700 (PDT)
Received: by mail-it0-x22d.google.com with SMTP id r192so169430136ita.0 for <cfrg@irtf.org>; Tue, 04 Oct 2016 22:55:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=G81dI7kGt27gA6zg3FFa0w52bJxnKiZW5Y6ihU8cWCE=; b=0w05mK4MxBbcv9GKXjHRC6jBi0Sn2kdc3vR2YbhutrzowNPW6JK7Q7sfcTXYSyQLj5 6CDnwrrSRWzHjOX+/Sx864S1ccMAnB0u72zuCuyTJL3fS98rIuZBfVsgcdqcBm2rsipV Ju1FSBWkA1Mkli4pjSLOVNBZYj6uUHmG24XJTnlN27aYUatpj/MuNKa6bxU35QTM8BgQ L+1cn2R+RyRY/qhBYRB9PnncjsYUBcGs50JYUmo29sKxduHuFBkRmIZ3XGywvVjmoMhF 10Hm/F8hXEluEng6mlJWZj6cW5b2rK7PvWApb250MePzauGgE/AU3V84Bc5ggk80xEM4 tMwA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=G81dI7kGt27gA6zg3FFa0w52bJxnKiZW5Y6ihU8cWCE=; b=FXFzarOEu4wXG2DMDEEl+vA9zRhUr8bBuPqQXTq7m2XEFln7t/lhQ22yU0q6pQ1DxO NAsQKGeuw7XYnSs0ds/KDBkMwpH/taLaW+9b4pPKWkRsZ6TgO8BJ/ChAZh8pXKdrQtMW YzhghIAkEZAZgI7W9VGupC+ZUPIc5Z+ZvxfFXvBaDW/bpruKuwWPzVlS1aFMTluHd8PJ BxGaQgeLRq6m5nVOaoTp+C/h3+YolLzs2cKNRxV2+THg//OU6clQ3ItTy6QFQXA+5dpV ohdsArjIXtfElZsRsKQWFfZXub//dYx4i8/vnjNah0FKcwLV2PMijmNYHa5E92bPKpAk 68WQ==
X-Gm-Message-State: AA6/9RkhyL7WWrUC94m4QEej3/ZapArnyqoWIdir2/YMPRcNuYBc5J0NCZaJE3sr8ssqOyOw6BWzgcEyRyZeuA==
X-Received: by 10.107.136.85 with SMTP id k82mr8111923iod.202.1475646933319; Tue, 04 Oct 2016 22:55:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.225.44 with HTTP; Tue, 4 Oct 2016 22:55:32 -0700 (PDT)
In-Reply-To: <c5853319-cfa5-1180-38ce-3fb438df8151@lounge.org>
References: <D41831C3.A2964%paul@marvell.com> <CAMr0u6k4U0fsXV2jHxam6Lk0OmmDS1NkV9Z43QF3sjJinW7fPQ@mail.gmail.com> <CAMr0u6ngTf+_eW_qhVz0G_jUNHUqPEMyQO+4A3xrqCh2tRe6FQ@mail.gmail.com> <D418A094.A29E7%paul@marvell.com> <CAMr0u6mUWxjqZbFBriMv8wDnmsWU6g2SBm3vnvOhX=B2rRF3aQ@mail.gmail.com> <c5853319-cfa5-1180-38ce-3fb438df8151@lounge.org>
From: "Stanislav V. Smyshlyaev" <smyshsv@gmail.com>
Date: Wed, 05 Oct 2016 08:55:32 +0300
Message-ID: <CAMr0u6kpt-bMw7NVj=bjE3_9pqJs_oHX0mD7A5NR+qqBc9nACQ@mail.gmail.com>
To: Dan Harkins <dharkins@lounge.org>
Content-Type: multipart/alternative; boundary="001a113ecf3c465333053e17d313"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/nRXmPc_LOKbTFdaQs-ABtEjOpLM>
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] SPM2 -> was Re: SPAKE2+mbDH a PAKE+PKA
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Oct 2016 05:55:36 -0000
Hello, Dan! mbDH (without modifications to SPM2) allows mutual authentication by private keys s_A and s_B in case the parties obtain trusted (i.e. obtained by a well-authenticated channel before the mbDH itself, of course) P_A and P_B – as well as ordinary authenticated DH. The thing I am talking about is that SPM2 seems not to provide it – Alice, who has a valid Bob's P_B, can be tricked by an adversary who doesn't have a correct s_B and has only the password. Regards, Stanislav 2016-10-05 8:45 GMT+03:00 Dan Harkins <dharkins@lounge.org>: > > Privyet Stanislav, > > On 10/4/16 9:56 PM, Stanislav V. Smyshlyaev wrote: > > Dear Paul! > > > Thank you very much for the corrections. > > > I. In the sense of PAKE everything seems to be OK now: now the proposed > protocol is at least as strong as SPAKE2 itself – since SPAKE2 + mbDH for > certain values of parameters is reduced to SPAKE2. Since the first part > of SPAKE2 (key agreement itself) is proven to be secure, we may say that > SPM2 should be a secure PAKE. Nevertheless a separate accurate proof would > be interesting anyway – but I think this is not the thing we should care > now about SPM2, there seems to be a lot more important problem. > > > > II. The problem is SPM2 in the case of known password seems to be less > secure than mbDH (it seems to be unsecure at all in this case). > > > What security properties do you believe mbDH has beyond simple DH-- i.e. > unauthenticated key agreement? > > Dan. > > > Consider the following attack (thanks to my colleague Liliya Ahmetzyanova for > the description) > > Let the adversary who tries to impersonate himself as B, knows password w, > but doesn't possess private key s_B and wants to make honest party A > believe that he does it for some fixed value of P_B. > > > > 1. A sends the values R_A, Y_A, where > > R_A = x_A * G + w * M_A; (according to the protocol description) > > Y_A = y_A * P_A = y_A * s_A * G; (according to the protocol description) > > 2. The adversary calculates for random x_B and y_B the values > > Y_B = y_B * P_B; > > R_B = x_B * G + w * M_B *– Y_B*; > > K = x_B * (R_A – w * M_A) + x_B * Y_A ( = x_B * (x_A * G) + > x_B * (y_A * s_A * G)); > > Then all actions are made according to the protocol. > > 3. A calculates K according to the protocol: > > K = (x_A + y_A * s_A)(R_B – w * M_B + Y_B) ( = (x_A + y_A * > s_A)(x_B * G) ); > > The key K is equal to the key of adversary = > decryption will be correct > => the check > > assert Y_B == y_B * P_B will be successful; > > > Thus SPM2 is not secure in the same case as mbDH is – it loses all > private-key-related security when the password is known. > > Again, Paul, please correct me if I missed something. > > > > Best regards, > Stanislav Smyshlyaev > > > 2016-10-04 10:44 GMT+03:00 Paul Lambert <paul@marvell.com>: > >> >> >> >> Dear Stanislav, >> >> >> Just a small remark: I'm sure that in the second message you wanted to >> send "encrypt( key=sk_BA, ((y_B, P_B), ...) )", not "encrypt( key=sk_BA, >> ((x_B, P_B), ...) )" (and "y_A, P_A" correspondigly). Otherwise you would >> obtain exactly the same problem as before. >> >> >> Thanks! I missed making this variable change … appreciate your catching >> this error. >> >> This update also made the shared key calculation more exactly match the >> SPAKE2 RFC and I missed changing the terms in this hash in a couple places. >> >> These are now fixed in: https://mentor.ieee.org/80 >> 2.11/dcn/16/11-16-1329-01-00ai-pkex-alternatives.ppt >> >> Best Regards, >> >> Paul >> > > > _______________________________________________ > Cfrg mailing listCfrg@irtf.orghttps://www.irtf.org/mailman/listinfo/cfrg > > >
- [Cfrg] SPM2 -> was Re: SPAKE2+mbDH a PAKE+PKA Paul Lambert
- Re: [Cfrg] SPM2 -> was Re: SPAKE2+mbDH a PAKE+PKA Stanislav V. Smyshlyaev
- Re: [Cfrg] SPM2 -> was Re: SPAKE2+mbDH a PAKE+PKA Stanislav V. Smyshlyaev
- Re: [Cfrg] SPM2 -> was Re: SPAKE2+mbDH a PAKE+PKA Paul Lambert
- Re: [Cfrg] SPM2 -> was Re: SPAKE2+mbDH a PAKE+PKA Stanislav V. Smyshlyaev
- Re: [Cfrg] SPM2 -> was Re: SPAKE2+mbDH a PAKE+PKA Dan Harkins
- Re: [Cfrg] SPM2 -> was Re: SPAKE2+mbDH a PAKE+PKA Stanislav V. Smyshlyaev
- Re: [Cfrg] SPM2 -> was Re: SPAKE2+mbDH a PAKE+PKA Dan Harkins
- Re: [Cfrg] SPM2 -> was Re: SPAKE2+mbDH a PAKE+PKA Stanislav V. Smyshlyaev
- [Cfrg] FW: SPM2 -> was Re: SPAKE2+mbDH a PAKE+PKA Paul Lambert
- Re: [Cfrg] FW: SPM2 -> was Re: SPAKE2+mbDH a PAKE… Andy Lutomirski
- Re: [Cfrg] FW: SPM2 -> was Re: SPAKE2+mbDH a PAKE… Paul Lambert
- Re: [Cfrg] FW: SPM2 -> was Re: SPAKE2+mbDH a PAKE… Dan Harkins