Subject: Re: [Cfrg] PAKE selection repository

From: "Hao, Feng" <[email-masked]>
Date: Wed, 25 Sep 2019 10:28:39 +0000

Hi Yaron,

Thanks for putting this together. It’s really encouraging to see the interest and detailed comments on PAKE from different sectors in the industry. After reading all reviews, I think there is a fundamental question that needs to be addressed. The question is below:

“Trusted setup vs hash-to-curve - which  of these two is considered acceptable, or neither?”

If the former is acceptable, we need to fully understand the implications once this setup becomes a target of attack and is broken in the worst case. However, the implications are not spelt out. If the latter is acceptable, the hash-to-curve functions must be fully specified. They have to be part of the complete specification for a PAKE system, and “fixed” (not movable parts) so people can review the whole system and fairly compare it with other techniques. We should also need to anticipate the likely scenario that in 10-20 years from now new EC curves might emerge and have more desirable security/efficiency properties, and hence become the preferred choices in the industry. Does a general hash-to-curve function exist that can adapt to any such curve that may emerge in the future?

Cheers,
Feng

From: Cfrg <[email-masked]> on behalf of Yaron Sheffer <[email-masked]>
Date: Friday, 20 September 2019 at 16:30
To: "[email-masked]" <[email-masked]>
Subject: [Cfrg] PAKE selection repository

Hi,

We have established a GitHub repository [1] for the source material of the PAKE selection candidates, as well as a list of all reviews submitted so far. We will update it when new reviews come in.

If you would like to amend a review you have submitted, please send the full review to the CFRG mailing list, and then open a Pull Request (or a GitHub Issue if that’s easier) with a stable link for the new review.

Thanks,
                Yaron

[1] https://github.com/cfrg/pake-selection/

---

From: Björn Haase <[email-masked]>
Date: Wed, 25 Sep 2019 16:20:40 +0200

Dear Feng,

>“Trusted  setup vs hash-to-curve - which  of these two is considered acceptable,
or neither?”

It was for preparing a clearer picture specifically for this question
why I have reviewed last week the patent situation regarding hash2curve.

After concluding that any patents on hash2curve algorithms could safely
be circumvented, I am now clearly advocating for avoiding "trusted
setup". It's not only a security aspect but rather also an aspect of
efficiency.

Regarding the algorithms, I'd opt on a one-to-one mapping of hash2curve
algorithm per curve. For Montgomery or (twisted) edwards curves, I'd
like to suggest elligator2. For the conventional short-Weierstrass form
curves, I'd like to suggest Riad's version of simplified SWU that avoids
using "-1" as a non-square element. This latter also provides a solution
for most curves.

The only real drawback of hash2curve that I am aware of might be related
to legacy designs of secure element chipsets. Unlike for conventional
scalar multiplication there might not be comparable hardware assistance
for hash2curve. However I am not aware of any legacy secure element
chipset that serves the typical IETF use cases. In my perception most
applications regarding passwords will be software-based and future
secure-element solutions could consider hash2curve without problems.

Yours,

Björn.

Am 25.09.2019 um 12:28 schrieb Hao, Feng:
>
> Hi Yaron,
>
> Thanks for putting this together. It’s really encouraging to see the
> interest and detailed comments on PAKE from I agreifferent sectors in
> the industry. After reading all reviews, I think there is a
> fundamental question that needs to be addressed. The question is below:
>
> If the former is acceptable, we need to fully understand the
> implications once this setup becomes a target of attack and is broken
> in the worst case. However, the implications are not spelt out. If the
> latter is acceptable, the hash-to-curve functions must be fully
> specified. They have to be part of the complete specification for a
> PAKE system, and “fixed” (not movable parts) so people can review the
> whole system and fairly compare it with other techniques. We should
> also need to anticipate the likely scenario that in 10-20 years from
> now new EC curves might emerge and have more desirable
> security/efficiency properties, and hence become the preferred choices
> in the industry. Does a general hash-to-curve function exist that can
> adapt to any such curve that may emerge in the future?
>
> Cheers,
>
> Feng
>
> *From: *Cfrg <[email-masked]> on behalf of Yaron Sheffer
> <[email-masked]>
> *Date: *Friday, 20 September 2019 at 16:30
> *To: *"[email-masked]" <[email-masked]>
> *Subject: *[Cfrg] PAKE selection repository
>
> Hi,
>
> We have established a GitHub repository [1] for the source material of
> the PAKE selection candidates, as well as a list of all reviews
> submitted so far. We will update it when new reviews come in.
>
> If you would like to amend a review you have submitted, please send
> the full review to the CFRG mailing list, and then open a Pull Request
> (or a GitHub Issue if that’s easier) with a stable link for the new
> review.
>
> Thanks,
>
> Yaron
>
> <https://github.com/cfrg/pake-selection/>
>
>
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg

---

From: Watson Ladd <[email-masked]>
Date: Wed, 25 Sep 2019 09:52:10 -0700

On Wed, Sep 25, 2019, 7:21 AM Björn Haase <[email-masked]> wrote:

> It was for preparing a clearer picture specifically for this question why
> I have reviewed last week the patent situation regarding hash2curve.
>
> After concluding that any patents on hash2curve algorithms could safely be
> circumvented, I am now clearly advocating for avoiding "trusted setup".
> It's not only a security aspect but rather also an aspect of efficiency.
>

Great news: no PAKE in the competition have a trusted setup. The efficiency
aspect is simply one of DH with unknown base  vs SPAKE2 which has some
additional operations. What SPAKE2 does have is a slight weakness where one
DL breaks the protocol everywhere going forwards. Solution: use groups
where DL is hard which you have to do anyway.

In fact one could avoid both via Elligator+encryption, but sadly I didn't
have that idea on time.

> algorithm per curve. For Montgomery or (twisted) edwards curves, I'd like
> to suggest elligator2. For the conventional short-Weierstrass form curves,
> I'd like to suggest Riad's version of simplified SWU that avoids using "-1"
> as a non-square element. This latter also provides a solution for most
> curves.
>

There is a separate hash2curve draft. Let's use that.

> scalar multiplication there might not be comparable hardware assistance for
> hash2curve. However I am not aware of any legacy secure element chipset
> that serves the typical IETF use cases. In my perception most applications
> regarding passwords will be software-based and future secure-element
> solutions could consider hash2curve without problems.
>
>
> Yours,
>
>
> Björn.
>
>
>
> interest and detailed comments on PAKE from I agreifferent sectors in the
> industry. After reading all reviews, I think there is a fundamental
> question that needs to be addressed. The question is below:
>
>
>
> If the former is acceptable, we need to fully understand the implications
> once this setup becomes a target of attack and is broken in the worst case.
> However, the implications are not spelt out. If the latter is acceptable,
> the hash-to-curve functions must be fully specified. They have to be part
> of the complete specification for a PAKE system, and “fixed” (not movable
> parts) so people can review the whole system and fairly compare it with
> other techniques. We should also need to anticipate the likely scenario
> that in 10-20 years from now new EC curves might emerge and have more
> desirable security/efficiency properties, and hence become the preferred
> choices in the industry. Does a general hash-to-curve function exist that
> can adapt to any such curve that may emerge in the future?
>
>
>
> Cheers,
>
> Feng
>
>
>
> *From: *Cfrg <[email-masked]> <[email-masked]> on behalf of
> Yaron Sheffer <[email-masked]> <[email-masked]>
> *To: *"[email-masked]" <[email-masked]> <[email-masked]> <[email-masked]>
> We have established a GitHub repository [1] for the source material of the
> PAKE selection candidates, as well as a list of all reviews submitted so
> far. We will update it when new reviews come in.
>
>
>
> If you would like to amend a review you have submitted, please send the
> full review to the CFRG mailing list, and then open a Pull Request (or a
> GitHub Issue if that’s easier) with a stable link for the new review.
>
>
>
> Thanks,
>
>                 Yaron
>
>
>
> Cfrg mailing [email-masked]://www.irtf.org/mailman/listinfo/cfrg
>