Re: [Cfrg] PAKE selection repository

[Björn Haase <[e-mail]>]

Dear Feng,


I agree with all of your points and specifically one of the key questions:

>“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:
>
> “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 <[e-mail]> on behalf of Yaron Sheffer
> <[e-mail]>
> *Date: *Friday, 20 September 2019 at 16:30
> *To: *"[e-mail]" <[e-mail]>
> *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/
> <https://github.com/cfrg/pake-selection/>
>
>
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg