Subject: Re: [Cfrg] using hash2curve in a protocol

From: Mathy Vanhoef <[email-masked]>
Date: Sat, 10 Aug 2019 08:57:16 -0700

I echo the advice that using an existing PAKE is likely the most
secure option, since these are more well-studied,

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.

Best,
Mathy

On Thu, Jul 25, 2019 at 3:20 PM Watson Ladd <[email-masked]> wrote:
>
> On Wed, Jul 24, 2019 at 11:05 AM Dan Harkins <[email-masked]> wrote:
> >
> >
> >    Hello,
> >
> >    The hash-to-curve draft is still a work in progress but I want to
> > use it to fix a broken protocol. The protocol in question is EAP-pwd
> > defined in RFC 5931. It does a "hunting and pecking loop" method
> > of hashing to a curve that is similar, but worse, than the technique
> > described in RFC 7664. (The method of obtaining a secret element in
> > a MODP group is similarly broken). It is susceptible to side channel
> > attack and I want to use the hash-to-curve draft to fix it.
>
> Why not use a PAKE that comes out of the competition? And are you sure
> the result of your chosen modification is actually secure?
>
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg

---

From: "Riad S. Wahby" <[email-masked]>
Date: Sat, 10 Aug 2019 13:27:57 -0700

Mathy Vanhoef <[email-masked]> wrote:
> implementation issues or other side-channels) more costly.

This is a great suggestion. To keep things modular, it might be
reasonable to treat the output of PBKDF2 (or bcrypt, scrypt, ...)
as the input to the hash-to-curve or hash-to-field algorithm
rather than merging the two. This ends up requiring some extra HKDF
invocations, but at least when hashing to curves those are cheap
relative to other costs. (This is likely also true when hashing to
a mod-p subgroup, since there's an exponentiation at the end.)

In any case, a small bit of care is warranted: roughly speaking,
the underlying hash function needs to give collision resistance
commensurate with the security level of the target curve or field.
For example, processing a password with PBKDF2-HMAC-SHA256 before
hashing to Ed448 isn't great, but PBKDF2-HMAC-SHA512 would be.

Regards,

-=rsw

---

From: Dan Harkins <[email-masked]>
Date: Sat, 10 Aug 2019 17:25:51 -0700

Hi Mathy,

> secure option, since these are more well-studied,

   It is an existing PAKE.

> not in every run of the handshake, the added overhead should be

   This is actually more of a comment for the hash-to-curve I-D. I'm
just going to use the techniques defined in that (soon to be) RFC.

   regards,

   Dan.

---

From: Dan Harkins <[email-masked]>
Date: Mon, 12 Aug 2019 00:38:49 -0700

Hi Mathy,

> not in every run of the handshake, the added overhead should be
   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?

   regards,

   Dan.

* 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.

---

From: Mathy Vanhoef <[email-masked]>
Date: Fri, 16 Aug 2019 16:42:30 -0700

> 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!

> 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.

> 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.