Re: [Cfrg] using hash2curve in a protocol

Mathy Vanhoef <vanhoefm@gmail.com> Wed, 23 October 2019 22:12 UTC

Return-Path: <vanhoefm@gmail.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E30A212008D for <cfrg@ietfa.amsl.com>; Wed, 23 Oct 2019 15:12:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RcmyNivISRYJ for <cfrg@ietfa.amsl.com>; Wed, 23 Oct 2019 15:12:53 -0700 (PDT)
Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com [IPv6:2607:f8b0:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CEB2120019 for <cfrg@irtf.org>; Wed, 23 Oct 2019 15:12:53 -0700 (PDT)
Received: by mail-oi1-x22a.google.com with SMTP id 83so18853765oii.1 for <cfrg@irtf.org>; Wed, 23 Oct 2019 15:12:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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: <8f8cb405-b534-c0ff-d351-3951fef62725@lounge.org> <CACsn0c=jOStaHXpREY9fJM3K88JAdQdY4UKdtzmEOoK65osCCw@mail.gmail.com> <CAFXAJYwem=yiMB0Jd+AKaLkQfGLqiVoNm9cqrD3wfrw3qkjeGw@mail.gmail.com> <a98d5bcf-2fb4-c680-600e-4cc43c0364b9@lounge.org> <CAFXAJYyFtW4zfNu=bzHDLHz_tCg4g7M-gY-roSZucGhi588APQ@mail.gmail.com>
In-Reply-To: <CAFXAJYyFtW4zfNu=bzHDLHz_tCg4g7M-gY-roSZucGhi588APQ@mail.gmail.com>
From: Mathy Vanhoef <vanhoefm@gmail.com>
Date: Thu, 24 Oct 2019 02:12:44 +0400
Message-ID: <CAFXAJYyTzKFSUuxbWe4UQ7Lgw88AwBiGzU8c+_UBWRTzBwj=Kg@mail.gmail.com>
To: Dan Harkins <dharkins@lounge.org>
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/JxHFXB7fWKLPeRdqA85DcH3_r34>
Subject: Re: [Cfrg] using hash2curve in a protocol
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=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:
https://github.com/cfrg/draft-irtf-cfrg-hash-to-curve/blob/master/draft-irtf-cfrg-hash-to-curve.md#security-considerations
In the context of Dragonfly this is highly recommended, since the
password element will leak if bad randomness is used (or the device is
compromised).

Best,
Mathy

On Sat, Aug 17, 2019 at 3:42 AM Mathy Vanhoef <vanhoefm@gmail.com>; 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.