Re: [Cfrg] SPAKE2+mbDH a PAKE+PKA

Andy Lutomirski <luto@amacapital.net> Sun, 02 October 2016 05:48 UTC

Return-Path: <luto@amacapital.net>
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 0235212B168 for <cfrg@ietfa.amsl.com>; Sat, 1 Oct 2016 22:48:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=amacapital-net.20150623.gappssmtp.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 gV1tBSrtkgsZ for <cfrg@ietfa.amsl.com>; Sat, 1 Oct 2016 22:48:19 -0700 (PDT)
Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::232]) (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 76C0F12B008 for <cfrg@irtf.org>; Sat, 1 Oct 2016 22:48:19 -0700 (PDT)
Received: by mail-ua0-x232.google.com with SMTP id n13so126198977uaa.3 for <cfrg@irtf.org>; Sat, 01 Oct 2016 22:48:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amacapital-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=p4ORKaXcGeT4H1vYle8rP68QgijkinHMMGmnAVY9ue0=; b=b59dPHKRgQBZnITi6wZroxQIcxttoKXHo2x6V+G5U/qqBEUz+2NCboGMHJsQsRRSNj LvsXd+by/Ax2QAfm3+Ikyg61fA7L3ob4vlIgOrVm1Y9HiBPFaCdVUGiUW9ag4Cvuw9xh fSrAEnsC+RSZ2JI3eXjNNzMsyhKrXqNvNj6c4BR1ClBzeheSQ5SCEmDoD/P9K3hTOWBH v1wLUYuWIEpRCvGsIghnOq9auBezZQVOsiZZXz4k6w3DBf6XqM1n9Zy9Ulxb9tEjG+Gq cHtwjbYeV3QlIXe1EfmYe4zTl8bIOXy9N8ORCO9vPN+Nc0T4WaJ2iEdBL+7kPixUvJY9 QmwQ==
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=p4ORKaXcGeT4H1vYle8rP68QgijkinHMMGmnAVY9ue0=; b=fzlIDKxgRXyhoE39UGuJjdtawzvQzIpxO8rUm5BK+HtsBU8BfoSkfWfC1Rl7FHiTAj +YDLhqRRYFVcXz3oWBsn3juY7cA82Z+Y9lYMmmODzJPxJwxs9uG8X20jClbaG3Aks7q1 30NyyWwSyCeCpsy/jpeq14ux1dPvilrrbQyAtes01zY6ABI9FRnqHwfLwBGtekioMNfV MuXODScX8fyEMm6KWmrrPU/GXs8fJ53waHzA7BvFpjOb6BgXR5VUCpLFRkCtl/+ftTmR apqtmBJk5BTk9joKw0p5SOEFJT+Y+Xt9y7ln5JXPvVtIK0LYsS3Q9hhvHOiz0I2Qf+j3 5fNA==
X-Gm-Message-State: AA6/9RmcUeuKyQ5VIQQNmfS/Z4AB/lh4wKb38klVuZIWlUEnM4sCJ0VEi+LINYb4hn83NVF4QT3ek0zEu3cIsDka
X-Received: by 10.176.68.102 with SMTP id m93mr10636462uam.68.1475387298528; Sat, 01 Oct 2016 22:48:18 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.65.22 with HTTP; Sat, 1 Oct 2016 22:48:17 -0700 (PDT)
Received: by 10.103.65.22 with HTTP; Sat, 1 Oct 2016 22:48:17 -0700 (PDT)
In-Reply-To: <676438da-4cb1-b6a1-89d6-a67ae334a0f8@lounge.org>
References: <D411B584.A2445%paul@marvell.com> <CAMr0u6n_OEe772s2b55iND7zYL_CN0F8k6DFaq6K7z-0gH1Mpg@mail.gmail.com> <D4121C90.A249D%paul@marvell.com> <676438da-4cb1-b6a1-89d6-a67ae334a0f8@lounge.org>
From: Andy Lutomirski <luto@amacapital.net>
Date: Sat, 1 Oct 2016 22:48:17 -0700
Message-ID: <CALCETrUDLtMCc3PQXJhvZ-uP_UtbuVLV42k3NfHutTzpFeHHdg@mail.gmail.com>
To: Dan Harkins <dharkins@lounge.org>
Content-Type: multipart/alternative; boundary=001a114ccd32d5d8b5053ddb5fa5
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/jp1zzULI5CtKf8cjmsQAbYDG_JY>
Cc: cfrg@irtf.org
Subject: Re: [Cfrg] 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: Sun, 02 Oct 2016 05:48:22 -0000

For the record: I have nothing to do with the proposal here.  This thread
is the first time I've seen it.

I still think that the right way to do this type of exchange is to use
existing, proven primitives as black boxes.  I don't see why the concepts
of "point" or "group", for example, should be involved except insofar as
they occur in the details of the underlying primitives.

So if SPAKE2 is going to be used, use it as is.  Don't modify it without a
very compelling reason and a proof.

On Oct 1, 2016 10:22 PM, "Dan Harkins" <dharkins@lounge.org> wrote:

>
>   Paul,
>
>   Why are you and Andy Lutomirski asking for review of a couple of slides
> on a powerpoint deck? Especially a deck whose focus is about a different
> protocol that does not exist anymore. Make an Internet-Draft that specifies
> _exactly_ how the protocol runs and not some ambiguous powerpoint
> suggestion
> based on a slide that uses some abbreviated notation that you admit is
> incomplete?
>
>   An I-D should clarify the unclear stuff regarding how you suggest to
> use AEAD schemes. Some of these schemes have critical usage requirements--
> like NEVER reuse a counter-- that you will have to deal with. You can't
> just wave your hands and say "encrypt".
>
>   Given the fact that it is not really clear what you and Andy Lutomirski
> are proposing I can only reply to the slides that you provide under the
> caveat that they may be inaccurate given their poor specification. So...
>
>   The "mutually blinded DH" you and Andy Lutomirski propose is completely
> broken
> and provides absolutely no authentication at all. A DH by itself provides
> no
> authentication so doing another DH "under the protection of" another
> unauthenticated
> DH  does not magically create authentication out of thin air.
>
>   There is a difference between proof-of-possession and authentication. The
> former is necessary for the kind of exchange you propose but it is not
> sufficient.
> An unauthenticated DH provides the former but not the latter. Your
> mutually blinded
> DH also provides the former but not the latter.
>
>   The "mutually blinded DH" that you and Andy Lutomirski propose is
> susceptible to
> a simple man-in-the-middle attack due to the fact that it provides
> absolutely no
> authentication whatsoever. You have no idea who sends Rb and no idea whose
> public
> key is Pb. The fact that Pb is sent encrypted by a secret derived from an
> unauthenticated Diffie-Hellman does not change anything. In fact, it
> enables the
> attack.
>
>   Modulo the obvious concerns with your proposal being a couple of
> powerpoint
> slides I feel safe in saying that the protocol you and Andy Lutomirski
> propose
> is completely broken.
>
>   Dan.
>
> On 9/29/16 1:54 AM, Paul Lambert wrote:
>
>
> 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>om>:
>
>>
>> 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-rev%0Aiew-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 listCfrg@irtf.orghttps://www.irtf.org/mailman/listinfo/cfrg
>
>
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>
>