Re: [Cfrg] using hash2curve in a protocol

Mathy Vanhoef <> Wed, 23 October 2019 22:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E30A212008D for <>; Wed, 23 Oct 2019 15:12:55 -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 RcmyNivISRYJ for <>; Wed, 23 Oct 2019 15:12:53 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8CEB2120019 for <>; Wed, 23 Oct 2019 15:12:53 -0700 (PDT)
Received: by with SMTP id 83so18853765oii.1 for <>; Wed, 23 Oct 2019 15:12:53 -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=8IhZ4QA3Zr3YLGVSFVH8XGw6U8Bd3cqnFSPgPx0BxLo=; b=C9JVUStSB1lqlC58EPGZfocf2YxRyN0/rHosDUrQors7mvyXUnII3/2UmyVnxKrRFT Idm0vA6RQMNIiTo+Rhq62XOA0rEonOYRZTLzvnCLd01yUb01/d4nzzBlmKrfQ+EJ5NrU hKjyAbIaOHmuT/SQR86PSY3PGzdmIvDIWbTWyzsRB9tleZtxjAqks9EKNwoImiy4PyED 7+oQm0Df1D+bpHxO0MeDt0Slv6+9EgqdbkSTkH4kqHdiSXNOIk8Vq9LUwthGvE5rgsT6 U2U4L0+RJyl9TrnxZMV82HT1rWlvFD3M3QQfGEBOH2DzzS6tgS/Bt2+lSpd0oMd4zLCa cw7A==
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=8IhZ4QA3Zr3YLGVSFVH8XGw6U8Bd3cqnFSPgPx0BxLo=; b=s0q4NJqNzW4LabST2GVZxSVNnlBOtJvcVPwzXXMKGiLH3rqzv2XgDpCXRoQXWASto4 +Qrfhd8whAYYwwAjcVvw73lMDQrDQyXDiuN9GB4YIEhvVYw5Q/k6IoxqrARIZ4jtK/FA a+8pULkl/FDHfpx4rjVTHHFDIniEVP6+EQIxb2wP4v4LLzgvSSEpKCHu2F66Mtny7qWE hnKgCadoKUW+PUyHnK+gUPeCcdLvQ/c5NFBbdojE0H1PbMm0Z15wdaC0gX9vy5AqtZd2 WzGJjh4KKPbXWzJg3Ngf3WYE5mxdGcn6TcqDRy6G6gX+siyDHXbaRhhjRCfKzr3mc+40 0BDw==
X-Gm-Message-State: APjAAAXWvfcVmBYpkEEBv+OoJMrR5PzizfDSlVfgbhIEf5hoi+ERING1 LGe3P9tKWJknSVftvhB/qKqSKdTHP3lX4LpafLQ=
X-Google-Smtp-Source: APXvYqyARwjeiEYqjlp6Axi7EqZzhqGowdMtRwKs/ZEuAwzC8igkzaZX9/1XWzr7mYEuw8wqJ95JirVtPFSdNJmTFFo=
X-Received: by 2002:aca:1814:: with SMTP id h20mr1837674oih.12.1571868772642; Wed, 23 Oct 2019 15:12:52 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: Mathy Vanhoef <>
Date: Thu, 24 Oct 2019 02:12:44 +0400
Message-ID: <>
To: Dan Harkins <>
Cc: "" <>
Content-Type: text/plain; charset="UTF-8"
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: Wed, 23 Oct 2019 22:12:56 -0000

Hi Dan,

The advice of first applying PBKDF2 or scrypt is now merged into the
draft hash-to-curve document:
In the context of Dragonfly this is highly recommended, since the
password element will leak if bad randomness is used (or the device is


On Sat, Aug 17, 2019 at 3:42 AM Mathy Vanhoef <>; wrote:
> > 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.
> Trying the "X most popular" password sounds like an online attack,
> while rainbow tables are for an offline attack and over much more
> passwords. What exactly do you mean?
> I'll assume hash_to_element() refers to either simplified_swu() or
> hash_to_ffc(). So with the current proposal, even with PBKDF2, rainbow
> tables would be possible. You can include the SSID in hash_to_element
> to *mitigate* this. Note the word *mitigate*, because like with WPA2,
> rainbow tables can then still be generated for the X most popular
> SSIDs. Nevertheless, that's still a better situation than not
> including these defenses!
> >    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.
> Not sure what you mean. Rainbow table is an offline attack, not
> online. An adversary can always try the X most popular passwords
> online (can be mitigated a bit with rate-limiting though).
> Using PBKDF2 is to mitigate implementation bugs that leak the
> hash_to_element result (a.k.a offline attacks). For example, Aruba's
> EAP-pwd used predictable randomness, thereby leaking the password
> element. A router or client device being compromised is another
> example.
> >    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?
> Threat model for using PBKDF2 is when the result of hash_to_element
> leaks, not online attacks. See examples above.