kilic / bls12-381 Goto Github PK

Is there any reason why we can't use fe, modulus, and q directly? For example, I want to implement the BBS+ signature scheme using this library and it involves operations on fe like add, sub, inverse all mod q.

I'd rather not do it in BigInt and duplicate the code you have written here. I don't mind submitting a PR to do so.

The problem can be reproduced by running

go build -linkshared ./...

Output:

asm: fp_arithmetic_x86.s:1427: when dynamic linking, R15 is clobbered by a global variable access and is used here: 00895 (src/github.com/kilic/bls12-381/fp_arithmetic_x86.s:1427)  CMOVQCC R12, R15
asm: fp_arithmetic_x86.s:2142: when dynamic linking, R15 is clobbered by a global variable access and is used here: 01198 (src/github.com/kilic/bls12-381/fp_arithmetic_x86.s:2142)  CMOVQCC R8, R15

This library takes place in the security audit of drand project carried by SigmaPrime. Report can be found here

All issues related with this library in the report are resolved within go-ethereum integration effort.

Currently, the Affine function is calling g.affine(p, p):

But then it changes the underlying point p, because of this Set:

This is unexpected from a function that's supposed to return an affine representation, since it actually mutates the point (and can cause nasty race conditions in code assuming the Affine is really just a getter and not a setter.)

We would like to use the g1 package with the blake2b hash function. It would be helpful if you could expose a function that permits any hash function to be used.

Cross-posted from hyperledger/aries-framework-go#2247

../../go/pkg/mod/github.com/kilic/[email protected]/arithmetic_decl.go:13:45: undefined: forceNonADXArch

I've imported the package and then vendored it using go mod vendor. No idea why the error didn't appear when running go test on the package directly. Sadly I don't have a minimal test case yet.

PointG1, PointG2, and PointGT don't implement any of the encoding related types. This makes it hard top use things like the Gob package with these types.

Hello @kilic I have been following this library long time ago and want to use it directly to create and sign using keypairs.
On older versions you had a package named blssig but seems it is removed now.

Do you have plans to implement it soon, or how should I implement it?

It can be reproduced as: https://gist.github.com/guidovranken/14f882f1b0af90398ceb39eeebdace27

While investigating this issue in our verkle tree library, we figured out that there is a re-entrancy issue in EC point multiplication. A description and a test to reproduce the problem can be found here.

We are aware that the README states that group instances and pairing instances are not suitable for concurrent contexts. This issue is here to 1) declare interest in a goroutine-safe version of this library 2) to document that issue in case someone else runs into it.

Currently this package only exposes a function to determine if a pairing is unity or not, but not a function to compute pairing values and no way to do arithmetic on the torus. These are needed for applications such as identity based encryption.

I tried implementing an algorithm based on the following property:
g^x == g^(x*1) == g^(x * (s * inv(s))) == (g^s)^(x * inv(s)),
but I can't get it (or the simpler one: g == (g^s)^inv(s)) to work with code:

G := bls.NewG1()
g := G.One()
x, _ := bls.NewFr().Rand(rand.Reader)
X := G.New()
G.MulScalar(X, g, x)

s, _ := bls.NewFr().Rand(rand.Reader)
si, six, sixRed := bls.NewFr(), bls.NewFr(), bls.NewFr()
si.Inverse(s)
six.Mul(x, si)
sixRed.RedMul(x, si)

x2 := bls.NewFr()
x2.Mul(s, six)
fmt.Println(x.Equal(x2)) // false

x2Red := bls.NewFr()
x2Red.RedMul(s, sixRed)
fmt.Println(x.Equal(x2Red)) // true

g2 := G.New()
G.MulScalar(g2, g, s)
G.MulScalar(g2, g2, si)
fmt.Println(G.Equal(g, g2)) // false

X2 := G.New()
G.MulScalar(X2, g, s)
G.MulScalar(X2, X2, six)
fmt.Println(G.Equal(X, X2)) // false

X2Red := G.New()
G.MulScalar(X2Red, g, s)
G.MulScalar(X2Red, X2Red, sixRed)
fmt.Println(G.Equal(X, X2Red)) // false

I've seen that the test for Inverse uses Fr.RedMul, but I have no idea when to use it instead of Mul (some documentation would be great). Neither of them work with this example.

There is definitely some missing understanding of the library where reading source can only get me so far;
what can be done to make this work?

Sorry bu i think there is a big problem in this code !

The wNaf is incorrectly implemented since the size of the resulting representation (according to the code) is the same ad the size in bits of the nitial binary representation. Hence, the glv multiplication (and of course the wNaf points multiplication) are not optimized and in contrast mush slower than naive binary approach. In addition, if the goal is secure "constante" implementation, this is also not meet because of the test inside the loop (if i=0..).
According to which paper you have implement this?

Regards

In trying to implement the YAHK scheme I realized that I need a reciprocal in Gt. While it's possible to implement for elements of order r through exponent, there probably are more efficient methods.

Opening this issue to request ARM64 build support or native go fallback.

Tracking downstream here: prysmaticlabs/prysm#2546
We may select between this library and phoreproject's BLS for ARM builds so we aren't totally blocked.

Thanks!

The HashToCurve functions are currently hard-coded to use the little-endian variant (https://tools.ietf.org/html/draft-irtf-cfrg-hash-to-curve-06#section-4.1.2) of sgn0. It would be helpful if there was an additional option to use the big-endian variant (https://tools.ietf.org/html/draft-irtf-cfrg-hash-to-curve-06#section-4.1.1).

There are some scenarios that require the operations of Pairing, not just signature verification, but need to operate G1, G2, GT add, mul, pairing and other operations to design specific pairing-based cryptographic schemes.

herumi implements the pairing library with C++（mcl）, and based on this, the bls library （bls) is implemented, so can this library be split into two libraries? A pairing library is used for actual calculations, and the bls library wraps the pairing library to implement the signature scheme.

As far as I can tell the order of the group isn't defined as a constant or function returning a big.Int in the API. This makes it very hard to do arithmetic outside the package and then pass in the result: this is necessary for things like picking random points or doing arithmetic in the exponents.

I can easily submit a PR to fix this if you think it's a good idea, but want to know what you think of the various ways to solve this problem.

The library is currently using the hash_to_curve draft 6 scheme.

It is incompatible with what is used in Ethereum Consensus layer (H2C draft 7 minimum), in particular due to the changes in sgn0 introduced in https://github.com/cfrg/draft-irtf-cfrg-hash-to-curve/pull/230/files

See vectors: https://github.com/ethereum/bls12-381-tests

There shouldn't be any impact on the execution layer because there is no hash-to-curve precompile (yet) but EIP2537 will be added soon: https://arachnid.github.io/EIPs/EIPS/eip-2537