[curves] Curves for pairings

[Brendan McMillion]

Hey Mike,

This morning, I forked Golang's implementation of bn256 and fit it with a
448-bit BN [1] curve based on the parameter

u = 1910986621940954212840033034977453

which, according to ellipticnews, should be closer to the 128-bit security
level. Interestingly, it's also very close to 2.5 times slower than the
same implementation for a 256-bit curve for all major operations. For
scalar mult in G1, 2 milliseconds to 5ms. For scalar mult in G2, 5ms to
13ms. For a pairing, 15ms to 35ms. All of these numbers can be lowered by
an order of magnitude by porting them to C and the scalar multiplications
can still be sped up by implementing GLV decomposition.

Is this also roughly the situation for the BLS curves you're experimenting
with?

[1] https://github.com/Bren2010/bn448



On Sep 28, 2016 4:09 PM, "Jeff Burdges" <burdges at gnunet.org> wrote:

> On Tue, 2016-09-27 at 05:28 +0000, Zooko Wilcox-OHearn wrote:
> > I was totally wrong about this. Our performance bottleneck is in a
> > path (zk-SNARK proving) that doesn't require pairing operations, so
> > using a curve which was 2.5 times slower at pairing operations would
> > not worsen our performance issues. However, if it was also 2.5 slower
> > for curve operations, then it would.
>
> It's still slower for scalar multiplication due to being a larger curve,
> no?
>
> In any case, you said there are no risks to the anonymity here, so an
> alternative to changing curves might be to prevent attacks from being
> profitable by capping the maximum value in a transaction or account,
> right?  In the short term, this should not require dong anything.
>
> Jeff
>
>
> _______________________________________________
> Curves mailing list
> Curves at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/curves
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/curves/attachments/20160928/e2b46d5d/attachment.html>