This post explains an inherent tension between BLS signature and Hashed Elgamal in the context of a threshold network, and then presents a way to augment such threshold network such that a smart contract can efficiently verify a signature and decrypt/verify encryption onchain.
For encryption/decryption and signing, we (usually) require a group, i.e. a single elliptic curve. However, using pairings, we have to choose between $\mathbb{G_1}$ and $\mathbb{G_2}$ (and even $\mathbb{G_t}$), each group have their pros and cons depending on the cryptographic protocol we want to use. In practice, $\mathbb{G_1}$ is usually preferred given it is much shorter and faster to compute in it, than its counterparties.
This choice of group comes up when designing threshold networks. Indeed, there is a distributed key lying in a group $\mathbb{G}$ which could be any of the three groups aforementionned. In particular, when using pairing equipped curves, a threshold network can be used to create threshold BLS signatures (which has lots of nice properties and is used more than even in the blockchain space) but it can also be used as a decryption oracle. In the latter, users encrypts towards the threshold network and push the encryption onchain.
This posts shows the pros and cons of using $\mathbb{G_1}$ and $\mathbb{G_2}$ for each and shows there is a tension between the two. This posts then shows a simple solution to get the best of both worlds. The technique is heavily inspired by a post by Kobi Gurkan on efficient multisignature verification onchain.
There are many references on the web that will explain BLS signatures. This post by Remco Bloemen is one of them!
Workflow: user creates a signature and push it onchain. The smart contract will verify the validity of this signature.
For succinctness and simplicity, we present this CCA version of El Gamal encryption scheme. Note that are many versions and also IBE based encryption scheme (such as the one used for timelock encryption), that will expose the same problem laid in this post.
Workflow: a user encrypts a message, and push it onchain. The smart contract will verify the “validity” of this ciphertext.
Assume we have a generic group $\mathbb{G}$, then
Such protocol is used to generate a distributed private key, such that each node has a share of it, but no one individually can recover the private key. The public key is known. The set of all nodes can act as if it was a single entity.
Let’s assume we have $n$ participants, with a threshold of $t$, a distributed public key $P=xG \in \mathbb{G_1}$, with each node having a share $x_i\in\mathbb{F_r}$-The “public share” can also be computed publicly $X_i=x_iG_1\in\mathbb{G_1}$
To recover the private key $x$, the network would need to come together and compute