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" <burd...@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@moderncrypto.org > https://moderncrypto.org/mailman/listinfo/curves > >
_______________________________________________ Curves mailing list Curves@moderncrypto.org https://moderncrypto.org/mailman/listinfo/curves