Re: [Cfrg] using hash2curve in a protocol

Dan Harkins <> Mon, 12 August 2019 21:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6E32E120A1A for <>; Mon, 12 Aug 2019 14:29:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 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] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id N3OayZPDD_A8 for <>; Mon, 12 Aug 2019 14:29:05 -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 6626C1208E5 for <>; Mon, 12 Aug 2019 00:38:52 -0700 (PDT)
Received: from ( []) by (PMDF V6.8-0 #1001) with ESMTP id <> for; Mon, 12 Aug 2019 02:38:51 -0500 (CDT)
Received: from thinny.local ([]) by (PMDF V6.7-x01 #1001) with ESMTPSA id <> for; Mon, 12 Aug 2019 00:38:19 -0700 (PDT)
Received: from ([] EXTERNAL) (EHLO thinny.local) with TLS/SSL by ([]) (PreciseMail V3.3); Mon, 12 Aug 2019 00:38:19 -0700
Date: Mon, 12 Aug 2019 00:38:49 -0700
From: Dan Harkins <>
In-reply-to: <>
To: Mathy Vanhoef <>
Cc: "" <>
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.13; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
X-PMAS-SPF: SPF check skipped for authenticated session (, send-ip=
X-PMAS-External-Auth: [] (EHLO thinny.local)
References: <> <> <>
X-PMAS-Software: PreciseMail V3.3 [190811] (
X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists)
Archived-At: <>
Subject: Re: [Cfrg] using hash2curve in a protocol
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: Mon, 12 Aug 2019 21:29:08 -0000

   Hi Mathy,

On 8/10/19 8:57 AM, Mathy Vanhoef wrote:
> Because similar changes are also being proposed in an update to the
> Wi-Fi standard, one remark is that in the simplified_swu and
> hash_to_ffc routine you can use PBKDF2 or similar instead of HKDF.
> This will make possible brute-force attacks (e.g. due to
> implementation issues or other side-channels) more costly. Since these
> routines only have to be executed when configuring the password, and
> not in every run of the handshake, the added overhead should be
> manageable.
   Given that hash_to_element() takes the password as the only
parameter there is nothing to prevent rainbow tables from being
generated based on the "X most popular" passwords (where X is 100 or
1000 or whatever). In fact, it's a given that they will be generated
(this was done in the "Wi-Fi standard" you refer to). So any benefit
you propose seems mostly imaginary.

   A KE is a PAKE when the advantage that an adversary gains is through
interaction (on-line) instead of through computation (off-line). But if
the individual act of testing a password is based on a rainbow table
then it doesn't matter whether PBKDF2 was used or whether just HKDF was
used. The attack will simply run through a table of predetermined elements.
It will just be done on-line.

   The key in using a PAKE is to make sure your password is not guessable
(which is a MUCH lower bar than saying it must be a "random n-bit PSK" *).
Since an attack against a PAKE requires repeated active attacks (instead
of just number crunching off-line) there is a benefit since it constrains
attacks and forces them to be detectable, but there really isn't much of
a gain by trying to increase the unit cost of each guess. Unless I'm
missing something. What am I missing?



* think of the example of a PSK being a number chosen uniformly such that
1 < PSK < 1,000,000. In a (non-PAKE) PSK exchange this will be successfully
attacked, in a matter of seconds, with a probability of 1, but with a PAKE
it will require 500,000 active attacks until probability reaches 0.5. That
is the benefit, not the unit cost of each guess.