Re: [Cfrg] SPM2 -> was Re: SPAKE2+mbDH a PAKE+PKA
"Stanislav V. Smyshlyaev" <smyshsv@gmail.com> Tue, 04 October 2016 06:45 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 90B791294F4 for <cfrg@ietfa.amsl.com>; Mon, 3 Oct 2016 23:45:16 -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 o3qz7fQcu_Gg for <cfrg@ietfa.amsl.com>; Mon, 3 Oct 2016 23:45:14 -0700 (PDT)
Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (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 0CC95127A91 for <cfrg@irtf.org>; Mon, 3 Oct 2016 23:45:14 -0700 (PDT)
Received: by mail-io0-x234.google.com with SMTP id i202so63416515ioi.2 for <cfrg@irtf.org>; Mon, 03 Oct 2016 23:45:14 -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=kN1vhpf5uELL9DwXdq10LxdSY01Db7LhoKcJTE/6xaI=; b=mx34phXXkoTbwpqVqbLGiqVSqH85Y8I4fSvawM9poGmMphq3vjSTl54VARooSgtc/f Vj/yYlwPS2S1IjRGbXt5WZMnm0mS5lHJwSNwS9S0ni0vQk49ERT2sr7avXRUjIbffyYa lEVHqw4XvOTTQUNWqw2GlEal8s7wxwZzd1f7Pgozv55v+DhVejnrpABv61W8y163/lI/ GjnOfg4JSeqU5gUR9Pehrwhbm5M760cW3ALKFVUFrf+P6r9C6YDaA+uawiD9p2i7m+/f BBU7sJEvjtZkrDnzyfUx15LpNcF2IZPstPyXgxWWTl3wXgm+LeUyyVsuvmcbJZwPHAaH HWXw==
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=kN1vhpf5uELL9DwXdq10LxdSY01Db7LhoKcJTE/6xaI=; b=LR4fI/d5mEMeVRVpsRbdvkG3OVmgcrQy+2xHqtAZowo8TVv649uS8a8X6X7InGOZYn TeAu1nwyrU7qCDyDiaHz3zMTxz/50HcGm4/LOP8cvGd8UOVjBZZQXUvbrQp5djlEf0N/ fBK1O78e0Ug+qUB++lDpLW9m2ESgI9tJ5Zy6n7ymWvj06vTCRsU0wQH9G+z4RASPXv8y SmmqKeXPH2hs7t9d804KFfx3l/RalKNo1bgY8m+XWswrOBqYvO5zD9ISKezXrTJrmd03 C1Ha0aMaDSAnSJsL/8/pz6fs9dt6eJQdNp/hS2/t7M/zMrmjsxOmSyaZYbUNAV1czF2G 6ZPA==
X-Gm-Message-State: AA6/9RnMcNHpaJmyZkiHCcKS0yN+xImJQTYy7L/3jyfXS96k19ciNTdIDB6sC8T9BD3bG8kHjYuHrj3avbsvyQ==
X-Received: by 10.107.132.217 with SMTP id o86mr2745151ioi.81.1475563513260; Mon, 03 Oct 2016 23:45:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.225.44 with HTTP; Mon, 3 Oct 2016 23:45:12 -0700 (PDT)
In-Reply-To: <CAMr0u6k4U0fsXV2jHxam6Lk0OmmDS1NkV9Z43QF3sjJinW7fPQ@mail.gmail.com>
References: <D41831C3.A2964%paul@marvell.com> <CAMr0u6k4U0fsXV2jHxam6Lk0OmmDS1NkV9Z43QF3sjJinW7fPQ@mail.gmail.com>
From: "Stanislav V. Smyshlyaev" <smyshsv@gmail.com>
Date: Tue, 04 Oct 2016 09:45:12 +0300
Message-ID: <CAMr0u6ngTf+_eW_qhVz0G_jUNHUqPEMyQO+4A3xrqCh2tRe6FQ@mail.gmail.com>
To: Paul Lambert <paul@marvell.com>
Content-Type: multipart/alternative; boundary="001a113f85d40d541a053e04675a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/iZfeavjVuZkxxhbv1gfO4gEeV8k>
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:45:16 -0000
Dear Paul, 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. Best regards, Stanislav 2016-10-04 9:05 GMT+03:00 Stanislav V. Smyshlyaev <smyshsv@gmail.com>: > 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-pke >> x-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 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