Re: [Cfrg] PAKE selection repository

On Wed, Sep 25, 2019, 7:21 AM Björn Haase <bjoern.m.haase@web.de> wrote:

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

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.

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

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

>
> 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 <cfrg-bounces@irtf.org> <cfrg-bounces@irtf.org> on behalf of
> Yaron Sheffer <yaronf.ietf@gmail.com> <yaronf.ietf@gmail.com>
> *Date: *Friday, 20 September 2019 at 16:30
> *To: *"cfrg@irtf.org" <cfrg@irtf.org> <cfrg@irtf.org> <cfrg@irtf.org>
> *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/
>
>
>
>
>
> _______________________________________________
> Cfrg mailing listCfrg@irtf.orghttps://www.irtf.org/mailman/listinfo/cfrg
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>