Re: [Cfrg] using hash2curve in a protocol

[Mathy Vanhoef <[e-mail]>]

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 <[e-mail]> 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.