Re: [Cfrg] PAKE review

Bjoern Tackmann <> Tue, 19 November 2019 20:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F14DE120122 for <>; Tue, 19 Nov 2019 12:10:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Xp2blBcawDuU for <>; Tue, 19 Nov 2019 12:10:15 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::335]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A39EF120073 for <>; Tue, 19 Nov 2019 12:10:15 -0800 (PST)
Received: by with SMTP id c22so5316534wmd.1 for <>; Tue, 19 Nov 2019 12:10:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yD3P8hShlWsWD98zOyxImEF5F6l5WG7fi3IWTVQbouE=; b=YFMUl1lcadeOgiip9U4mMJX+XMaDYczGBL8UMkonSZgGB2Sr6MHsqD8tAclCAXyGb6 PCZ9rNTsW9VtJAvQWXhfbVIxbEg17k/YMtCA5LpKBIIru92uolNu8Goq2f8y1eX/NCLd LFAn9yY00WL1dBmFiiupJA8tP/m3dAOt/NDHA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yD3P8hShlWsWD98zOyxImEF5F6l5WG7fi3IWTVQbouE=; b=FnbqnJL12mhxssl1TP2ofst+1iCa+DtTn30B8kFdw78zGGKRvEdPlYsN4HktCq73tY tjpl+Kqz7CMhN9WPVhlCcBVzAC2tdgrohzSf0uuUNNSnv7fY7tVCR5rziDH5PyaYbaD0 n9mOiajgICq1Jd3Po7wGKvl85ggMFloLhPE6sAVd1xED7cl2TC5uquFf48/if7qq1gH1 MwmNtChVXd8679TW/U3RFCKAp6ttzKth11psZAjQBhNnNHpUzQ0nVgywHtkLNOTir8iO 72fIwWJy/vUR7ipxlWJ6Itb7WXzLRJ0jYmefCtnyJi79VP6kMd7YAMX8GjvUIo/2BLX1 pGgg==
X-Gm-Message-State: APjAAAXLvMvvscrZvB8C2czs48l6hlzaMrwrLhb/S1uJ9rwTgNaGY/Gi pkX2w1vNsxqb+zNgiMVF9KAaTQ==
X-Google-Smtp-Source: APXvYqwWQMHfnbsP+6TA373TD+22Ei3klZmSKsaYNrecmkYRDHH0F6tN8F1g40QFuXUTkvP2apYj9w==
X-Received: by 2002:a1c:7f44:: with SMTP id a65mr8091776wmd.19.1574194213857; Tue, 19 Nov 2019 12:10:13 -0800 (PST)
Received: from ?IPv6:2001:8e0:2002:8600:dc0e:c54:952:9a01? ([2001:8e0:2002:8600:dc0e:c54:952:9a01]) by with ESMTPSA id u4sm28208694wrq.22.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Nov 2019 12:10:13 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
From: Bjoern Tackmann <>
In-Reply-To: <>
Date: Tue, 19 Nov 2019 21:10:12 +0100
Cc: CFRG <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Hugo Krawczyk <>
X-Mailer: Apple Mail (2.3601.0.10)
Archived-At: <>
Subject: Re: [Cfrg] PAKE review
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: Tue, 19 Nov 2019 20:10:18 -0000

Hi all,

sorry for my late response. I wanted to answer some things below.

> On Nov 1, 2019, at 3:49 AM, Hugo Krawczyk <> wrote:
>> Assumptions. All augmented schemes depend on similar assumptions (CDH and hash function as random oracle). OPAQUE and AUCPACE require the random oracle to be programmable, but that seems to be related to the stronger security statements.
> DH-OPRF requires the Gap-One-More-DH assumption so both OPAQUE and Strong AuCPace need that too.

Thanks, that is of course correct.

>> Properties. The major difference in properties seems to be whether schemes support security against precomputation, which is proved for OPAQUE and also claimed for BSPAKE. The "strong" variant of AUCPACE also achives this property, whereas standard AUCPACE and VTBPEKE do not. For OPAQUE and VTBPEKE, solving a single dlog attacks multiple sessions. It is important to differentiate here, though, between VTBPAKE where all protocol sessions globally are affected, whereas in the case of OPAQUE it only affects one subset of users at a time.
> Why a subset of users and a single user? Note that he OPRF key k is unique per user. The setting where this may be relevant is with quantum computers that can break dlog efficiently, and as I commented in another email, OPAQUE seems better positioned in the sense of preparedness for the PQ (and transition) era.

If one uses one k per user, then it only affects one user. I wanted to emphasize that, in contrast to the case of VTBPAKE, such an attack does not affect every user; sorry if that formulation caused confusion.

>> Implementation. AUCPACE and BSPAKE need map_to_curve.
> OPAQUE too.

Thanks for the correction.

>> Integration. All candidates except for OPAQUE seem difficult to integrate with TLS, in particular the message pattern of AUCPACE and BSPAKE does not seem to fit well, and possibly require some out-of-band communication. For IKEv2, all candidates seem compatible, of course those with better round complexity seem preferable.
> I expect most applications to integrate the aPAKE with some existing mechanism, at the very least, a mechanism that uses the key derived from the aPAKE to protect communication (a standalone key exchange without an application that uses the key is not too useful in general). Today TLS would be the natural choice for such integration but there are other cases (e.g. IKEv2/IPsec). The modular design of OPAQUE eases integration in these cases too, in particular allowing to reuse the existing AKE mechanism (if so desired). Yet another reason to integrate aPAKE with existing (non-password-based) AKE protocols is the need to protect user account information.

Sure. I find it hard to select a “best” aPAKE without considering a specific application. For TLS, I find OPAQUE clearly the best option. Other protocols may also benefit from OPAQUE’s round efficiency. At the same time I envision that other protocols may have a different profile...

>> Conclusion. One main question for me related to augmented PAKEs is: which application scenarios does IETF aim for? If the goal is to retrofit existing protocols in the typical TLS scenario with improved security, then OPAQUE is the best option for its strong security and its compatible communication pattern. (In particular, TLS should use OPAQUE.) TLS and the likes aside, however, I see the "strong" version of AUCPACE as a strong contender: it is efficient in terms of computation and communication; the most significant drawback over OPAQUE appears to be the additional message.
> also (though possibly less significant) Strong AuCPace requires an additional (variable-base) exponentiation per party to achieve security against pre-computation attacks.

True, I just found the additional message more significant. But, as stated above, that may depend on the application.