You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think there is a bug in the Window Table calculation in the SerialSetup.java.
Around line 90, there is this block of code that initializes the window table.
The scalarSizeG1 is set to the size of the generator, and this returns the minimum number of bits that can represent generatorG1. If I pick this to be g1Factory.one() (a valid generator), the scalarSizeG1 would be 2 and the window table would be too small. I did some basic tests for batchMSM with such a table (with scalars between 1 and 10) and it could not accurately compute the multiples of generatorG1, because it did not inspect all the bits of the scalars.
I think this should not really depend on the generator but be an attribute of the type used. Otherwise, even when uniformly sampling the generator, we should get a wrong number of bits with reasonable probability.
I did a quick fix for my particular use case (non-generic) like this. A better fix should be capable of taking the type into account:
I think there is a bug in the Window Table calculation in the SerialSetup.java.
Around line 90, there is this block of code that initializes the window table.
The
scalarSizeG1
is set to the size of the generator, and this returns the minimum number of bits that can representgeneratorG1
. If I pick this to beg1Factory.one()
(a valid generator), thescalarSizeG1
would be 2 and the window table would be too small. I did some basic tests forbatchMSM
with such a table (with scalars between 1 and 10) and it could not accurately compute the multiples ofgeneratorG1
, because it did not inspect all the bits of the scalars.I think this should not really depend on the generator but be an attribute of the type used. Otherwise, even when uniformly sampling the generator, we should get a wrong number of bits with reasonable probability.
I did a quick fix for my particular use case (non-generic) like this. A better fix should be capable of taking the type into account:
The text was updated successfully, but these errors were encountered: