Re: [Cfrg] PAKE selection process: status after Phase 1 and following steps

Watson Ladd <> Fri, 19 July 2019 04:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CB03412010C for <>; Thu, 18 Jul 2019 21:39:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 zy8z_96lidNL for <>; Thu, 18 Jul 2019 21:39:01 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9A638120100 for <>; Thu, 18 Jul 2019 21:39:00 -0700 (PDT)
Received: by with SMTP id r9so29475553ljg.5 for <>; Thu, 18 Jul 2019 21:39:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1oWDbRz0Clf1X9NCd+uHgnS9Cn59qYm+/R1xYyU9g5U=; b=I9qJtZK6knQUbrxBiCpWmsaLwjnc9u9SNqw4adsSIUQi6bqDRsefiKEMTQBnFsikjG Ov23AiIeJnUA2R33hX662u1cgGw6YpZmsfuHH9r2ANw8eV5uMNTL1WGD1Ldir4TOlAhT j0MV+qkkyOI7d+4TR2bVjrQmePFWz7PzwC6/+C/7IXgam3VshOQdwYZecwf0dTu14eb6 oaBGbxP/A1lUBiyFr45Un1KgCK8gG48Dd6WAZgMGomreVt77M2KnsBgPVxBlfhc7cN6K iZ6CLkQd5TU464ijYIYHwlfLMU8kbqOo0/3CBluj9FkLar/AT9EZTgtBIxgEk1G6xzf0 m/tg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1oWDbRz0Clf1X9NCd+uHgnS9Cn59qYm+/R1xYyU9g5U=; b=QVLnyjtOBt+R7ujcpxjIJl+FjGCNdVuVatu3XPV6RER421f2VsuxHGf8fxxnV6j0Pg 79xRN29ZRk5Eq0lTkGqFqZTczlDnsadGI8HDpJWwUdBGqqRlIAocCG9aLAW8Az4k8pXS ZiT4XfpoitSg6PiYE8v1hZbCFrIr+RpMVqqAGgqZxWPK+1g5XoU0TRDReuBuhydawhUh I0J4kJmH6suKvwu/pdizTi6erxvUa9ZYmBicUhug0TBMSYqa9a8BKRrIvQYGD7g1Z0Fs 2xMI/2Z3OjmIQUixVbctZhd9M7vvWRS1Vv1DjDg3fZ8XlmE2KhEOMX2aB6eN9+gOdRyn Q6/g==
X-Gm-Message-State: APjAAAVQ9sqSxXJ+s3h6GxZ2U/hgu359wxs7q7gWU50k3xwFU1fDRdzz a0PIA25tVXeg5cjwllLVJD+QaSThxyiH44MdGypimvJP36A=
X-Google-Smtp-Source: APXvYqwl3RMxVxSXHiE/mBjxQchJqxfaMrImNS4dKTeZJGF4Op+2xBGTm4AYe6abRnJwpf0noi0N+j5JUKAy0h1pWrc=
X-Received: by 2002:a2e:8892:: with SMTP id k18mr26795217lji.239.1563511138789; Thu, 18 Jul 2019 21:38:58 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Watson Ladd <>
Date: Thu, 18 Jul 2019 21:38:46 -0700
Message-ID: <>
To: "Stanislav V. Smyshlyaev" <>
Cc: CFRG <>,
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [Cfrg] PAKE selection process: status after Phase 1 and following steps
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: Fri, 19 Jul 2019 04:39:03 -0000

Dear all,
Apologies for the empty email and long delay.

First the auxiliary questions:
SPAKE2 is a balanced PAKE. Both peers could initiate at the same time
but must distinguish their roles somehow. It can be integrated into
IKEv2 or the TLS handshake. There are per-group parameters: this is
not a barrier to agility as a method for their generation is
specified. There is no limit on applicability. The security model is
not unusual and there are no problems with the proof. As for the
security with common password entropy the standard security
requirement for PAKE requires online guessing attempts equal in number
to the number of passwords guessed. Clearly no scheme can do better,
and as SPAKE2 has this property it is only as unsafe for common
passwords as any scheme would have to be.

SPAKE2 does not have a trusted setup: it does have two system
parameters which are points of which of the discrete logs would lead
to a security issue for any exchanges in the future. Any such
computation would cast significant doubt on the difficulty of the
discrete logarithm problem in the group. The protocol is 1 round.

Password hashing guidance does not seem to differentiate PAKE
protocols. It could of course be included in any document. The same
for blocking user enumeration: the obvious trick is to use a random
string as password and continue the PAKE.

Now the main ones:
R1: It is a balanced PAKE
There is a security proof in

Abdalla, M. and D. Pointcheval, "Simple Password-Based
              Encrypted Key Exchange Protocols.", Feb 2005.

              Appears in A.  Menezes, editor.  Topics in Cryptography-
              CT-RSA 2005, Volume 3376 of Lecture Notes in Computer
              Science, pages 191-208, San Francisco, CA, US.  Springer-
              Verlag, Berlin, Germany.
in the ROM.
R3: There are no operations that pose any difficulty in rendering
constant time implementations
R4: Irrelevant: there is no map in the scheme of the type discussed in RFC 8125.
Each party conducts 4 point multiplications in the course of the
protocol. Note that two of the multiplications may be combined into
one computation of x*A+y*B which is moderately more efficient.
I am not sure I understand what R6 is supposed to mean.
Shielding identities is a difficult topic and very protocol specific.
R8: I am unaware of any patents that bear on SPAKE2.

Watson Ladd