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

"Stanislav V. Smyshlyaev" <> Fri, 30 September 2016 11:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AEC3412B0BB for <>; Fri, 30 Sep 2016 04:57:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.976
X-Spam-Status: No, score=-1.976 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, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lk6c3PVCt9nV for <>; Fri, 30 Sep 2016 04:57:46 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 50EE512B0BC for <>; Fri, 30 Sep 2016 04:57:46 -0700 (PDT)
Received: by with SMTP id t81so36368901lfe.0 for <>; Fri, 30 Sep 2016 04:57:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:content-transfer-encoding:message-id:date:subject:from :in-reply-to:references:to:cc; bh=d3fhhxolW6WVINHGK9g5ci+CiXchdfzC9xcqm6kb2dA=; b=MnBYmCO1NQqBNBcRuSlCxDIsJAVoHWkp/W6nZ3pivL9+CCIT7B6LdV2lBN0va+QMJ6 qtAQdBDiF2w6lw5NuSxeuTPAHjiA6kAMhvZAbYzKzYDcxMOgBkFQivRhNBjb4rTiVxjE ZORbWQuDfVch3fI91n2OGnyro5Zs2FkcBLk46g1+m7Og1nGgX4r4EUyj7GXsT8witrLe q8petLmuUrer8w6vmLiGR3PPdoW51jZe7s6B4VPuTWPztnrSXb+i3a6NHOVGc7xjHBcN KE4+o1KGVGC32AF4xKSkDQkI4ozzjjkYjJW5DdFVftI2m46uYBpaCU3/17sJ8fogwyoD KXPw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:content-transfer-encoding :message-id:date:subject:from:in-reply-to:references:to:cc; bh=d3fhhxolW6WVINHGK9g5ci+CiXchdfzC9xcqm6kb2dA=; b=mSF7LX13TBImPbdTpDaJRVYSHkuC0aVZvDnCMt+xOmnd/RDr7cD6Dq0DNm92nPpUXE 7Gr8h8lbLF3ld/u42LVKwdqTaFE5uqyh22+ME/Qa6mH64gYTDMzEvRIcMh3k5iXDyMDb hiGnAGLL4WtXI9aZrl37XX5LUAEyZ8XASKVwXgC3HOZSdrAWpc2OGYNrtx9KCMGulyOi D4lO87n98qnVO5SDsgoVkoW3urTbNCiu/SbpTg1Hkg/NSmQlsWvaYExF62X4OQm/b5A6 beX4mlMc2G/gjRWWU9HHSUUBlaTMzp5pfyiEHuDg2vHkiu/czp/94Fi37xtIxBQYX5j8 xhuA==
X-Gm-Message-State: AA6/9RkX67cuYYGM6w0A8VdQKdAQWw/OR1lb/Wy4NqZ+ybVlskr2T7TyO8QDZX4WahAOAQ==
X-Received: by with SMTP id 94mr2826024lja.61.1475236664305; Fri, 30 Sep 2016 04:57:44 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id g201sm2910240lfg.8.2016. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 30 Sep 2016 04:57:43 -0700 (PDT)
Content-Type: text/html; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
X-Mailer: BlackBerry Email (
Message-ID: <>
Date: Fri, 30 Sep 2016 14:57:42 +0300
From: "Stanislav V. Smyshlyaev" <>
In-Reply-To: <>
References: <> <> <>
To: Paul Lambert <>
Archived-At: <>
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: Fri, 30 Sep 2016 11:57:49 -0000

Dear Paul,

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. 

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'll be thankful for your comments on this concern. Please correct me, if I missed something in your description.

Kindest regards,
Stanislav Smyshlyaev
От: Paul Lambert
Отправлено: четверг, 29 сентября 2016 г., 11:54
Кому: Stanislav V. Smyshlyaev
Тема: 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!

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,


Kindest regards,

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

The PKEX protocol (" rel="noreferrer nofollow" target="_blank"> )
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 (" rel="noreferrer nofollow" target="_blank"> ) combines nicely
with mutually blinded Diffie-Hellman (mbDH). Blinded DH (bDH) is described
in" rel="noreferrer nofollow" target="_blank">

A brief description of the resulting SPAKE2+mbDH protocol is contained in
slides 13 to 18 of:" rel="noreferrer nofollow" target="_blank">

Comments would be appreciated.

If this protocol seems useful an RFC could be developed.


Cfrg mailing list" rel="noreferrer nofollow" target="_blank">