[curves] Curves for pairings
brendanmcmillion at gmail.com
Wed Sep 28 22:21:53 PDT 2016
This morning, I forked Golang's implementation of bn256 and fit it with a
448-bit BN  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
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,
> 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.
> Curves mailing list
> Curves at moderncrypto.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Curves