Curve25519 and/or Curve41417 and/or Alternatives in Gecko/Firefox (was Re: Road to RC4-free web (the case for YouTube without RC4))

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Curve25519 and/or Curve41417 and/or Alternatives in Gecko/Firefox (was Re: Road to RC4-free web (the case for YouTube without RC4))

Brian Smith-19
On Thu, Jul 10, 2014 at 5:33 AM, Kurt Roeckx <[hidden email]> wrote:
>
> [snip]
> An other alternative is using curve25519.  It's also not standardized yet, but at this time it seems more likely to be standardized first.

Thanks for bringing up curve25519. I'd like to share a recent paper
written by Daniel J. Bernstein, Chitchanok Chuengsatiansup, and Tanja
Lange:

      "Curve41417: Karatsuba revisited.''
      http://cr.yp.to/papers.html#curve41417

Section 1.5, "Is high security useful?" is particularly interesting.

I think it is likely the case that Curve25519 solves the wrong
problem*: it tries to be faster than NIST P-256 but only the same
strength, but I think a new standard curve should be the same speed as
NIST P-256 but much stronger. My thinking is that now, when Curve25519
isn't an option, everybody is using P-256 without significant
performance complaints. This shows that we don't really need something
faster than P-256. Further, as the paper states in section 1.5, there
are quite a few reasons to want to have a security level higher than
~125 bits, if we can get it with reasonable performance and without
compromising other security goals, which we apparently can, according
to this paper.

By the way, an extra notable merit of this paper is that they focused
on ARM performance

I would like to hear what others think about this, including what
people think Gecko should do.

Cheers,
Brian

* Besides performance, Curve25519 solves other problems, but in
general all of the other new alternatives like curve41417 solve them
too.
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Curve25519 and/or Curve41417 and/or Alternatives in Gecko/Firefox (was Re: Road to RC4-free web (the case for YouTube without RC4))

Kurt Roeckx
On Thu, Jul 10, 2014 at 09:57:56AM -0700, Brian Smith wrote:

> On Thu, Jul 10, 2014 at 5:33 AM, Kurt Roeckx <[hidden email]> wrote:
> >
> > [snip]
> > An other alternative is using curve25519.  It's also not standardized yet, but at this time it seems more likely to be standardized first.
>
> Thanks for bringing up curve25519. I'd like to share a recent paper
> written by Daniel J. Bernstein, Chitchanok Chuengsatiansup, and Tanja
> Lange:
>
>       "Curve41417: Karatsuba revisited.''
>       http://cr.yp.to/papers.html#curve41417
>
> Section 1.5, "Is high security useful?" is particularly interesting.
>
> I think it is likely the case that Curve25519 solves the wrong
> problem*: it tries to be faster than NIST P-256 but only the same
> strength, but I think a new standard curve should be the same speed as
> NIST P-256 but much stronger. My thinking is that now, when Curve25519
> isn't an option, everybody is using P-256 without significant
> performance complaints. This shows that we don't really need something
> faster than P-256. Further, as the paper states in section 1.5, there
> are quite a few reasons to want to have a security level higher than
> ~125 bits, if we can get it with reasonable performance and without
> compromising other security goals, which we apparently can, according
> to this paper.
>
> By the way, an extra notable merit of this paper is that they focused
> on ARM performance
>
> I would like to hear what others think about this, including what
> people think Gecko should do.

I think it looks promosing.  But like the paper indicates it needs
time for other people to review it before it's going to see any
adoption.  Curve25519 on the other hand is almost 10 years old
now, and provides the security I currently think is at a good
level, and is fast.  So I think we should try to adopt curve25519
and later see if we should adopt Curve41417.


Kurt

--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Curve25519 and/or Curve41417 and/or Alternatives in Gecko/Firefox (was Re: Road to RC4-free web (the case for YouTube without RC4))

Dirkjan Ochtman
On Thu, Jul 10, 2014 at 7:35 PM, Kurt Roeckx <[hidden email]> wrote:
>> I would like to hear what others think about this, including what
>> people think Gecko should do.
>
> I think it looks promosing.  But like the paper indicates it needs
> time for other people to review it before it's going to see any
> adoption.  Curve25519 on the other hand is almost 10 years old
> now, and provides the security I currently think is at a good
> level, and is fast.  So I think we should try to adopt curve25519
> and later see if we should adopt Curve41417.

I mostly agree with Kurt; everyone is getting into curve25519 these
days, and extra performance is always welcome. Maybe trying to leap
over curve25519 is not a great idea if compatibility with everyone
else is important.

Cheers,

Dirkjan
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Curve25519 and/or Curve41417 and/or Alternatives in Gecko/Firefox (was Re: Road to RC4-free web (the case for YouTube without RC4))

Henri Sivonen-2
In reply to this post by Brian Smith-19
On Thu, Jul 10, 2014 at 7:57 PM, Brian Smith <[hidden email]> wrote:

> On Thu, Jul 10, 2014 at 5:33 AM, Kurt Roeckx <[hidden email]> wrote:
>>
>> [snip]
>> An other alternative is using curve25519.  It's also not standardized yet, but at this time it seems more likely to be standardized first.
>
> Thanks for bringing up curve25519. I'd like to share a recent paper
> written by Daniel J. Bernstein, Chitchanok Chuengsatiansup, and Tanja
> Lange:
>
>       "Curve41417: Karatsuba revisited.''
>       http://cr.yp.to/papers.html#curve41417
>
> Section 1.5, "Is high security useful?" is particularly interesting.

It seems plausible that there could be advances in attacks that cause
incremental improvents in attack capability without being such
breakthroughs as to make ECC totally fall, so in that sense the notion
of aiming for as much computation as a performance budget allows for
is persuasive.

However, I observe that
https://www.imperialviolet.org/2014/05/25/strengthmatching.html seems
to argue against adding extra security in the hope that future
advances make the margin useful but don't go all the way past the
margin.

> I would like to hear what others think about this, including what
> people think Gecko should do.

The idea of not adding Curve25519 support in order to wait for
something that's presumed to be even better but that doesn't have the
momentum of Curve25519 seems problematic.

Curve25519 now has the sort of mometum that it looks like the best bet
to get an interoperable alternative to the NIST curves. It seems to me
that going for anything else will lead to a situation where some
vendor tries to push Curve41417, another vendor pushes Goldilocks-448
and a third one pushes curves from Microsoft Research. And then
everyone keeps using the NIST curves for interop.

If indeed Curve41417 turns out at a later date to be the thing
everyone should adopt, sure it'll be harder to get server admins to
switch from Curve25519 to Curve41417 than to switch from NIST P-256 to
Curve41417, but if NISH P-256 needs switching away from, it seems bad
to push the switch further away out of fear that if admins get to
switch to Curve25519 soon, they'll be less likely to switch away from
that if Curve41417 becomes available also.

Further, I think it would be good for Mozilla's software to be in the
privacy leadership and now Cyanogenmod is leading over B2G by baking
support for the TextSecure protocol in the system's SMS service. To
get even to the point where a TextSecure-compatible SMS app
replacement is available from the Marketplace (if not baked into the
default Gaia SMS app), it would seem helpful to have Curve25519 as
part of the Gecko platform and available via Web Crypto (once it has
been specced how exactly Curve25519 should be exposed via Web Crypto
if it is exposed). (The current Chrome-oriented JS implementation of
the protocol uses NaCl for the Curve25519 part.)

(All that with the disclaimer that I'm not competent to actually
evaluate the cryptographic merit of the algorithms by looking at the
math.)
--
Henri Sivonen
[hidden email]
https://hsivonen.fi/
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto