Re: [Cfrg] Balanced PAKEs: new paper on SPAKE2

Dan Harkins <> Wed, 30 October 2019 18:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C8854120996 for <>; Wed, 30 Oct 2019 11:05:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lhHSkTOOGeaC for <>; Wed, 30 Oct 2019 11:05:10 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DDE08120939 for <>; Wed, 30 Oct 2019 11:05:10 -0700 (PDT)
Received: from ( []) by (PMDF V6.8-0 #1001) with ESMTP id <> for; Wed, 30 Oct 2019 13:05:09 -0500 (CDT)
Received: from Dans-MacBook-Pro.local ([]) by (PMDF V6.7-x01 #1001) with ESMTPSA id <> for; Wed, 30 Oct 2019 11:04:03 -0700 (PDT)
Received: from ([] EXTERNAL) (EHLO Dans-MacBook-Pro.local) with TLS/SSL by ([]) (PreciseMail V3.3); Wed, 30 Oct 2019 11:04:03 -0700
Date: Wed, 30 Oct 2019 11:05:05 -0700
From: Dan Harkins <>
In-reply-to: <>
Message-id: <>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8; format=flowed
Content-language: en-US
Content-transfer-encoding: 8BIT
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.2.0
X-PMAS-SPF: SPF check skipped for authenticated session (, send-ip=
X-PMAS-External-Auth: [] (EHLO Dans-MacBook-Pro.local)
References: <> <>
X-PMAS-Software: PreciseMail V3.3 [191025] (
X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists)
Archived-At: <>
Subject: Re: [Cfrg] Balanced PAKEs: new paper on SPAKE2
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 30 Oct 2019 18:05:18 -0000

On 10/25/19 5:22 AM, Scott Fluhrer (sfluhrer) wrote:
>> -----Original Message-----
>> From: Cfrg <> On Behalf Of Karthik Bhargavan
>> Sent: Friday, October 25, 2019 6:03 AM
>> To:
>> Subject: [Cfrg] Balanced PAKEs: new paper on SPAKE2
>> Hello All,
>> Michel Abdalla and Manuel Barbosa have just published a new paper the
>> perfect forward security of SPAKE2:
>> They say:
>> "In this version, we tried to address some of the issues that were raised in
>> the CFRG mailing list and during our meeting.
>> In particular, the proof handles explicitly the case M=N. The cases where M
>> and N are chosen as the output of a random oracle also follows from the
>> proof. This means for instance that M and N could be set the hash of two
>> fixed points (or one point when M=N) or set as a function of the client and
>> server, such as M=H(C,S) (where H is a hash-to-group function.)
>> The goal of the paper was not to compare it with the other submissions. It
>> was simply to improve the security analysis of SPAKE2 and its possible
>> variants”
>> With these new results in mind, I would recommend that the SPAKE2 draft
>> use a connection-specific M=N=H(C,S,...) generated using hash-to-curve.
>> This will make the precomputation attack on SPAKE2 less worrisome.
> While it would certainly improve things, it wouldn’t actually make SPAKE2 fully "Quantum Annoying"
> It would improve things in that solving a single global DLog problem wouldn't allow an easy one-exchange dictionary search.  However, the attacker could still perform a single on-line exchange (obtain the M=N value and the initial encrypted message that depends on that M value, solve the DLog problem for that specific M, and then perform the dictionary search).  It would mean that he would need to perform a DLog for every system he attacks, however it still remains an earier attack than any known attack against (for example) CPACE
> On the plus side, there would not be an issue if the hash-to-curve routine is not constant time (which is a major concern with CPACE)

   So what are we evaluating then? I was leaning towards CPACE because 
SPAKE2 seems
a bit too much like "the Dual_EC_DRBG of PAKEs" but if it's going to 
become this:

both side share: w = MHF(pw) and M = hash2curve(Alice | Bob | ...)
Alice sends: A = xG + wM
Bob sends: B = yG + wM
secret = x(B - wM) = y(A - wM)

then it's looking more attractive for the reason you mention.