Re: [Cfrg] [CFRG] PAKE / Hash2Curve First Internet draft for balanced CPace subcomponent available

["Hao, Feng" <[e-mail]>]

Hi Bjorn,

I have a couple of comments for your consideration.

First of all, it’s not safe to assume the sender must know the receiver’s exact identity before the key exchange. Identities are normally transmitted “in-flow” as part of the key exchange protocol, as each party may not always know the other party’s exact identity beforehand. I understand Watson Ladd is trying to modify SPAKE2 by hashing the user identities before the key exchange to avoid the trusted setup, but that wouldn’t work for the same reason. Also, I suggest you have a look at the SPEKE specification in the IEEE P1363.2 (2006). If you interpret that specification literally, you may find it’s basically the same as the CPace protocol you propose. The trick is how you define the “shared secret”. In IEEE P1363.2, it’s defined as follows (also see [1])

“A password-based octet string which is generally derived from a password or a hashed password, identifiers for one or more entities, an identifier of a communication session if more than one session might execute concurrently, and optionally includes a salt value and/or other data.”

The items you define in the hash-to-curve function include the above. But obviously, the definition above is highly ambitious and makes the incorrect assumption that identities and session identifiers are always known by the other party even before the key exchange. This is addressed in the latest SPEKE specification in ISO/IEC 11770-4:2017, in which the shared secret is defined as “the password only”. No assumption is made about knowing the other party’s precise identity before the key exchange.

Second, some people on this list seem to assume hash-to-curve will provide you with an ideal RO-like mapping with negligible cost at a constant time. I would urge caution on that assumption until the fact is fully established. The use of hash-to-curve is not anything new; people in the PAKE field have been playing with that idea for nearly 2 decodes. There are previous efforts in IEEE P1363 (2000-2008) and ISO/IEC 11770-4 to define and standardize this function. However, over the past many years, hash-to-curve has been known to be notoriously difficult to get right. In fact, the original SPAKE2 protocol was designed with the motivation to avoid hash-to-curve (but it introduces the trusted setup assumption instead). We may need to wait a bit until the ongoing IEFT effort on defining and standardizing hash-to-curve to finish and for that to become a really established secure primitive (which will be a major contribution to the field, but we should not underestimate that this is actually a very tricky and challenging task).

[1] https://arxiv.org/pdf/1802.04900.pdf

Cheers,
Feng

From: Cfrg <[e-mail]> on behalf of Björn Haase <[e-mail]>
Date: Monday, 6 January 2020 at 23:52
To: "[e-mail]" <[e-mail]>
Subject: [Cfrg] [CFRG] PAKE / Hash2Curve First Internet draft for balanced CPace subcomponent available

Dear CFRG community,

I have just posted a first version of an RFC-style draft regarding the balanced subcomponent CPace.

https://datatracker.ietf.org/doc/draft-haase-cpace/

Any feedback would be appreciated!

A corresponding draft for the augmented protocol is in preparation.

Yours,

Björn.