Re: [Cfrg] SPM2 -> was Re: SPAKE2+mbDH a PAKE+PKA
"Stanislav V. Smyshlyaev" <smyshsv@gmail.com> Tue, 04 October 2016 06:05 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 3F5641295C9 for <cfrg@ietfa.amsl.com>; Mon, 3 Oct 2016 23:05:11 -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 p7TwqwSYd3Ah for <cfrg@ietfa.amsl.com>; Mon, 3 Oct 2016 23:05:07 -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 B144B12944D for <cfrg@irtf.org>; Mon, 3 Oct 2016 23:05:06 -0700 (PDT)
Received: by mail-it0-x22d.google.com with SMTP id j69so140418377itb.0 for <cfrg@irtf.org>; Mon, 03 Oct 2016 23:05:06 -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=BYEFZWYizy2ZUmCMwPeQa2vtARInqrmPNliBO0rVC9M=; b=0Pt0zOEXRHJBpkL81NRm2dYigCwDdfDx/+MqB0nOjUJhJUsFV+8YQ4gkGh1ui/vwGf te1uZa38KJ6KuO5LHqVLNL4AkmLDubWfxYE3P3eWYoI08MWSM63K3PYaZ2KiJbJm4UFg n1GqmZunA20oD1wQZImyx8V9LRmSOOI1NGU1hnWDJjxRR8hdeSkqmMHkViN1SQEWQrTF NKaoRNHWqebIteTmoq/clKaGKghLq7tuvB4+gVbzw+Fnk2mMcjEdZCwC2GaynD3AIG5l ZyNSoCMuEA862EpdkkxiKbz2c+44xJ9JvCts+Zn+lLxpVaO1OLicsOw4gnubPzSWiZjV Ou0Q==
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=BYEFZWYizy2ZUmCMwPeQa2vtARInqrmPNliBO0rVC9M=; b=SZFBysxXzDOsNNqnEu9SalDHAXGlRzl6yABcSDp0j3WXUAFJLJVMSof50EGt607Ovs ad84pBjGqQ0WXSa5IdIwFmahbgBnlhTvQXVDSzzqtBFwJxvab4bO8gFBDUTG7XTFhFMq BaDiRAtygjPVuZEZdlcgbqKOWmBmn7uUV/kFPDKCb8pqkzJa0GyHYEORqn6yyi1nUUTh yDdAOyhyhKsDM0k63eOoXNdMwKf7ZH6juaUv6NScNX+ePFB/zmNAE3uyza6iZXbiK1I2 iz0ZAUj60JSgsuco53NDQsADi+PimyEEMHZnmfYnk2wQTXDxLDGDHUHUaWZJ3Fw0ydiX 5DvA==
X-Gm-Message-State: AA6/9RmXzigIY5hpKSidvGVd2ElNNgN45P7CxdaWwQroVqfparI2OnjaLAKanzVLjejXrBCq1OKgn7yoE+1O9Q==
X-Received: by 10.36.224.137 with SMTP id c131mr2519440ith.10.1475561105770; Mon, 03 Oct 2016 23:05:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.225.44 with HTTP; Mon, 3 Oct 2016 23:05:05 -0700 (PDT)
In-Reply-To: <D41831C3.A2964%paul@marvell.com>
References: <D41831C3.A2964%paul@marvell.com>
From: "Stanislav V. Smyshlyaev" <smyshsv@gmail.com>
Date: Tue, 04 Oct 2016 09:05:05 +0300
Message-ID: <CAMr0u6k4U0fsXV2jHxam6Lk0OmmDS1NkV9Z43QF3sjJinW7fPQ@mail.gmail.com>
To: Paul Lambert <paul@marvell.com>
Content-Type: multipart/alternative; boundary="94eb2c19e25e8dd38c053e03d73d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/VU6T09qG1VWYVwpcTioUdP8VUw0>
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: Tue, 04 Oct 2016 06:05:11 -0000
Dear Paul, Thank you for the new version! I'll try to review it and reply in a couple of days. Kindest regards, Stanislav 2016-10-04 2:05 GMT+03:00 Paul Lambert <paul@marvell.com>: > Dear Stanislav, > > Based on your comments, I’ve made another cut at combining SPAKE2 and > mbDH. This should not have the problem you identified in the earlier > version. The combination more directly performs the protocols in parallel. > > https://mentor.ieee.org/802.11/dcn/16/11-16-1329-00-00ai- > pkex-alternatives.ppt > > Best Regards, > > Paul > > > From: Paul Lambert <paul@marvell.com> > Date: Monday, October 3, 2016 at 11:49 AM > To: "smyshsv@gmail.com" <smyshsv@gmail.com> > Cc: "cfrg@irtf.org" <cfrg@irtf.org> > Subject: Re: [Cfrg] SPAKE2+mbDH a PAKE+PKA > > > Dear Stanislav, > > Thank you very much for your time and effort to review this proposal. I > greatly appreciate your insights. > > Thank you for your comments and for the updated version of the slides. > Since you agree with my thoughts about the importance of defining "encrypt" > properties, let's remember this question. > > After another careful reading of the protocol now I have a concern about > it that seems very important to me. > > In the original SPAKE2 (as well as in SESPAKE and AugPAKE etc) there is an > important property (that is even proven for SPAKE2 and SESPAKE) of absence > of password leakage problems in the cases when the resulting session keys > are revealed (in real life - when the session key is misused and > compromised somehow). It is extremely important since session keys often > get compromised in real life and no one wants to leak authentication data > with them. > > > I agree with your concerns. The property of preventing password leakage > when session keys are exposed may not be applicable to every application, > but it’s still an important attribute. Most importantly … The combining > of two security primitives should retain all of the properties of the > original two primitives. > > > And the proposed protocol lacks this property: if sk_AB is compromised, > then x_A and P_A are known to adversary too - thus he knows w*M_A and can > find short secret pw by dictionary attack. > > Thus in the current version any agreed session key compromise would lead > to long-term password compromise, that seems to be a really bad property. > > > I see now that the ephemeral mask in SPAKE2 with the masked public key > from mbDH have contradictory requirements. The mbDH requires the subsequent > exposure of the mask to prove possession of the public key. SPAKE2 requires > that the mask never be exposed even if encrypted under a session key. This > type of replacement of terms is a flawed construction technique. > > A more direct combination of protocol mechanisms would be to perform them > both in parallel without significant modification to either base mechanism. > The calculation of the shared key(s) could be performed jointly for some > efficiency benefits without impacting the combined security > characteristics. > > > I'll be thankful for your comments on this concern. Please correct me, if > I missed something in your description. > > > No, your concerns are well founded and show that I violated my own design > goals for building on existing mechanisms. In my enthusiasm to save a point > multiple and a few bytes, the proposed design broke a subtile, but > fundamental security property of SPAKE2. > > Best Regards, > > Paul > > > Kindest regards, > Stanislav Smyshlyaev > *От: *Paul Lambert > *Отправлено: *четверг, 29 сентября 2016 г., 11:54 > *Кому: *Stanislav V. Smyshlyaev > *Копия: *cfrg@irtf.org > *Тема: *Re: [Cfrg] SPAKE2+mbDH a PAKE+PKA > > > Dear Stanislav, > > > Thank you for these links – they give a slightly new viewpoint on PAKEs > applications (I think the most discussed question will be "for which > applications will combining public keys and passwords be most useful?"). > > Yes … it may be useful as a type of ‘introduction’ process. > > > An editorial comment on the description of the protocol in the slides: it > seemts that after the second message A should check that "R_B - w*M_B == > x_B * P_B", not "R_B == x_B * P_B" as it is shown now. Similarly with the > B's check. > > > And a tiny remark: there is a misprint in the plaintext that A encrypts on > sk_AB for the third message: "(x_A, P_A)" should be there, not "(m_A, P_A)". > > > Many thanks for catching my errors! > > I’ve updated the figures and reposted: https://mentor.ieee. > org/802.11/dcn/16/11-16-1142-06-00ai-cryptographic-review-and-pkex.ppt > > > About the protocol itself, I'll try my best to give you our opinion today > or tomorrow. > > At a glance, it seems to be useful to add some specific requirements for > the used "encrypt" functions now or some concrete cipher modes (e.g. GCM or > CTR + HMAC) > > > Yes, this is not clear. The notation slide mentions AEAD encryption but > could say more on requirements. The ‘additional data’ is not being used, so > AEAD is not strictly required. For concrete examples, I’m considering > AES-SIV or GCM-SIV or something similar. > > > due to the words "decrypt is successful" (is it a real data authentication > or just some padding check?). EMVco used to check PIN-blocks just by > correctness of ECB decryption of IUN, so we should have more details here. > > > Yes, exactly. The decryption provides the validity check for the password > based authentication and does need a better description. > > Best Regards, > > Paul > > > Kindest regards, > Stanislav > > > > 2016-09-29 4:25 GMT+03:00 Paul Lambert <paul@marvell.com>: > >> >> The PKEX protocol ( https://tools.ietf.org/html/draft-harkins-pkex-00 ) >> provides PAKE functionality (with SPAKE2) and adds public key >> authentication (PAKE+PKA). >> >> In looking at alternatives to PKEX, combining an existing and evaluated >> authenticated public key exchange with a PAKE seems like an interesting >> design path. To this end, the SPAKE2 protocol ( >> https://tools.ietf.org/html/draft-irtf-cfrg-spake2-03 ) combines nicely >> with mutually blinded Diffie-Hellman (mbDH). Blinded DH (bDH) is described >> in https://www.emvco.com/specifications.aspx?id=285 >> >> A brief description of the resulting SPAKE2+mbDH protocol is contained in >> slides 13 to 18 of: >> >> https://mentor.ieee.org/802.11/dcn/16/11-16-1142-04-00ai-cry >> ptographic-rev >> iew-and-pkex.ppt >> <https://mentor.ieee.org/802.11/dcn/16/11-16-1142-04-00ai-cryptographic-review-and-pkex.ppt> >> >> Comments would be appreciated. >> >> If this protocol seems useful an RFC could be developed. >> >> Paul >> >> >> >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> https://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