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

"Stanislav V. Smyshlyaev" <> Thu, 29 September 2016 05:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5BCCE12B028 for <>; Wed, 28 Sep 2016 22:03:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id n-JVuZAlMbIs for <>; Wed, 28 Sep 2016 22:03:36 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BCB7712B016 for <>; Wed, 28 Sep 2016 22:03:35 -0700 (PDT)
Received: by with SMTP id t83so78768409oie.3 for <>; Wed, 28 Sep 2016 22:03:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7jDyHg7+9OfevdG6no3/6gJCpekXbbAlVWJAsaLnmFA=; b=cOmZfW3yeBDrY5uMmt9bbZwpZ5pFnEvvxcW6aLAk1+nVL0Vz6o+i1bRGD0krQd6m1v mckXAnuVmX88eJkNMNYRSt5Yydiyi19Gfnkd9E+IcVEBkxGv8DPvvZjy2CGVEwRftJMX KDPCktG3lkrk1gYzKJo1/yk2NxqGpVkXkJixDNatKlLgC6NdazMIW5CsV9t0kuzt/J8T RknGXXYVQ159THiz50A7QBNzSn8xZ27FmEFgzPEG8RFBM0tJ0FMR5DXBu6Whd0wtrj2D fhppoNPC8b3qOh9smD0/AeviD3ecF07/PTDE0+ipfchusjG7EMi33+e6G7YSjQM9BEr5 57IQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7jDyHg7+9OfevdG6no3/6gJCpekXbbAlVWJAsaLnmFA=; b=Nkfm5M5RCxuGwKV+4e4fgpo8J/wciKRT7L7Mv1jMvjP3bm161vtu1ZLtpDjnQ2Duno CgRSAAjMyDQdOu7P8BxODoXmpUSH4fcr2kL1czGFBO+vMGE+8lKg5hUjYshRRtztaDh6 Y2pw4X5UkXgDcL4Wmgaijt27wMkAppURWq4RG0C+Y6jg0BHM/O8AIR8W6iCwKitnyp01 i0laAUy3w0rzdzsv0SQR7RzSLLcGc+Ig370+0Nju1sSFYMFYtUIsUZAMBAjQAg0OQYy+ tcjbdJVIDxF/aX9VmgC3M3X7bOHLHjuuN8Y/2VRgdAB/Dhx9DJOqS8yltTYtmxCyFysD lyIw==
X-Gm-Message-State: AA6/9Rmhr2wwhAUsomd9QWO7kaQbWAPolujfYoc9AW2hxs37I7NfiRJbC8miwuR+wHiYVetnivwx7B8sFvM/1A==
X-Received: by with SMTP id o95mr805035ota.23.1475125415080; Wed, 28 Sep 2016 22:03:35 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 28 Sep 2016 22:03:34 -0700 (PDT)
In-Reply-To: <>
References: <>
From: "Stanislav V. Smyshlyaev" <>
Date: Thu, 29 Sep 2016 08:03:34 +0300
Message-ID: <>
To: Paul Lambert <>
Content-Type: multipart/alternative; boundary="001a1143ad5e5d803c053d9e6684"
Archived-At: <>
Cc: "" <>
Subject: Re: [Cfrg] SPAKE2+mbDH a PAKE+PKA
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 29 Sep 2016 05:03:38 -0000

Dear Paul!

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?").

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)".

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) 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.

Kindest regards,

2016-09-29 4:25 GMT+03:00 Paul Lambert <>:

> The PKEX protocol ( )
> 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 (
> ) combines nicely
> with mutually blinded Diffie-Hellman (mbDH). Blinded DH (bDH) is described
> in
> A brief description of the resulting SPAKE2+mbDH protocol is contained in
> slides 13 to 18 of:
> cryptographic-rev
> iew-and-pkex.ppt
> Comments would be appreciated.
> If this protocol seems useful an RFC could be developed.
> Paul
> _______________________________________________
> Cfrg mailing list