pairing: Adds support for BLS12381 using CIRCL library #49
Conversation
There was a problem hiding this comment.
Really cool ! Thanks a lot for making this !!!
@AnomalRoil @CluEleSsUK there is one thing im wondering is if this should live inside kyber or be its separate repo so kyber stays mostly the interface definition ? I'm not sure.
pairing/bls12381/g1.go
Outdated
| func (p *G1Elt) IsInCorrectGroup() bool { return p.inner.IsOnG1() } | ||
|
|
||
| func (p *G1Elt) Hash(msg []byte) kyber.Point { p.inner.Hash(msg, nil); return p } | ||
| func (p *G1Elt) Hash2(msg, dst []byte) kyber.Point { p.inner.Hash(msg, dst); return p } |
There was a problem hiding this comment.
If we want to make that generic, could we put the "dst" as a field in the struct, to avoid having multiple hash functions ?
There was a problem hiding this comment.
Once #50 get fixed, there will be only one (correct) API for hashes.
pairing/bls12381/adapter.go
Outdated
| // It's important to note that the Point function will generate a point | ||
| // compatible with public keys only (group G2) where the signature must be | ||
| // used as a point from the group G1. | ||
| type SuiteBLS12381 struct { |
There was a problem hiding this comment.
I'm confused by the need for this struct - why do you have it ? Why not just "Suite" is enough ?
There was a problem hiding this comment.
it is enough, I was just mimicking what is already done in the other pairing package.
|
Great job! I confirm this does not break tests. It does not replace internal use of In term of benchmark, I end up with the following on my machine The current implementation of drand/kyber-bls12381 using This commit implementation armfazh/add_cirl_drand using There is about a 4x difference between the two. I'm not sure if there is a safer/more portable implementation which might explain the difference. Given there is no modification of actual usage (ibe implementation is not modified for instance), the commit is not going to impact downstream dependencies. |
Regarding performance, one of the reasons of this difference is that the kilic library uses assembly for the prime field arithmetic, while CIRCL uses formally-verified code. |
|
Given the way Kyber abstract stuff I think it would make sense to have a WDYT? |
|
is the motivation to merge this change the deprecation of kilic/bls12-381, used by drand/kyber-bls12381 ? |
|
Not entirely. We are going to be working on merging back drand/kyber into dedis/kyber for the v4 release of dedis/kyber. However, I have started looking into maintaining a fork of kilic/bls12-381 but the more I dig into it the more bugs I find, so yeah, switching to circl_bls12-381 seems like a plausible option. We'll just need to do some more benchmarking and profiling since we'd really want to be able to run a ~30 node network under the 1s period and need to double check how that would behave wrt aggregation times and so. |
|
News: BLS signatures are supported in CIRCL (See bls.go). |
|
The initial goal of Kyber was to have all operations implemented in pure go, so having these kind of wrappers built-in the library is already a bit much, so I don't think the goal is to move away from the current Kyber implementation of primitives other than the elliptic curves anytime soon |
This PR adds the functionality of BLS12381 pairings using the CIRCL implementation as backend.
CIRCL implementation uses formally-verified implementation (using fiat-crypto) for the prime field arithmetic.
cc: @thibmeu @nikkolasg