Re: [Cfrg] Proposed PAKE Selection Process

"Crockett, Eric" <> Tue, 18 June 2019 21:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 95DD612029C for <>; Tue, 18 Jun 2019 14:21:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -11.809
X-Spam-Status: No, score=-11.809 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] 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 IL4EFfKCTtht for <>; Tue, 18 Jun 2019 14:21:37 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 70211120048 for <>; Tue, 18 Jun 2019 14:21:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;;; q=dns/txt; s=amazon201209; t=1560892897; x=1592428897; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=XANey53LyCAlJA4HR/Dio2rSGSpZrJs/w2pvdMNEy7Q=; b=u0DJxZhpdvAZeYWABBHMHE0RRrcD/6hzoX2eOHkiEdsEQv6QoJQzlQ+A aVH3DW6MAiGpOzQsUPBBis3YUTg6+qb/J2f8SEbd/ELZu7mU2SBqAY6cE VkqzjgEn7f/puwYrW8grhY4IVKTOhDbD/4zXvJ6D5RoI7RM2AlabYWQs1 k=;
X-IronPort-AV: E=Sophos;i="5.62,390,1554768000"; d="scan'208";a="806193865"
Received: from (HELO ([]) by with ESMTP; 18 Jun 2019 21:21:35 +0000
Received: from ( []) by (Postfix) with ESMTPS id 413AFA1FDA for <>; Tue, 18 Jun 2019 21:21:34 +0000 (UTC)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 18 Jun 2019 21:21:34 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 18 Jun 2019 21:21:34 +0000
Received: from ([]) by ([]) with mapi id 15.00.1367.000; Tue, 18 Jun 2019 21:21:34 +0000
From: "Crockett, Eric" <>
To: "" <>
Thread-Topic: Re: Proposed PAKE Selection Process
Thread-Index: AdUmGz+cDO8fggmKTUi7ZMzMLqCrQg==
Date: Tue, 18 Jun 2019 21:21:34 +0000
Message-ID: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Precedence: Bulk
Archived-At: <>
Subject: Re: [Cfrg] Proposed PAKE Selection Process
X-Mailman-Version: 2.1.29
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 18 Jun 2019 21:21:39 -0000

AWS is interested in PAKE. Of the options we've reviewed, OPAQUE appears to be the best fit for us. However, the lack of standardization of OPAQUE or any other provably secure augmented PAKE scheme has slowed our adoption of PAKE, so we look forward to a CFRG recommendation. I've listed a few things that we are looking for in a PAKE scheme for use at AWS: 

1. We would like to see the standardization of both a standalone scheme and its integration into TLS, similar to SRP (RFCs 2945 and 5054) or OPAQUE ( and

2. We would like clear IPR statements for any selected schemes, and would prefer a scheme that is completely unencumbered.

3. We would prefer a scheme with a security proof in the strongest model possible. Precomputation security is a plus.

4. Opaque (, and probably other schemes, support client-side iterated hashing, e.g., with Scrypt. We would like to see recommendations on using iterated hashing on PAKE clients.

5. We would like a scheme that explains how to avoid a user enumeration attack. Both SRP and OPAQUE do this.

6. Our primary use of PAKE would benefit from an augmented, rather than balanced, PAKE scheme.

Eric Crockett | Applied Scientist - Cryptography |