BLS Keys and Schemes

BLS keys are based on two elliptic curves and a pairing between these. This provides a cryptosystem that has some unique properties when combined with MPC:

• Signatures are deterministic and does not contain randomness.
• Signature operations are local operations for each MPC node, which means that pre-signatures are pointless.
• Signatures can be combined (aggregated) in a single signature that can be checked faster.

BLS has three different schemes that are used to provide various security guarantees:

• Basic: Basic scheme that uses the core functionality directly. This can be insecure if aggregating signatures, as related signatures can be created for non-existing private keys.
• Augmented (Aug): Augmented scheme tries to fix the problem with aggregated signatures by including the public key in the signature. This also means that derivation is secure in this scheme.
• Proof of Possession (PoP): Proof of Possession (PoP) scheme uses a PoP of the private key to fix the problem with aggregate signatures. The requirement in this scheme is that the PoP is checked before it is used to check any aggregate signature.

Since BLS is defined over two different curves and these curves have different sizes, each of the above schemes can be instantiated in two different variants depending on what curve is used for public keys and which is used for signatures:

• Minimal Public Key Size: This means that signatures are larger. This variant is beneficial for aggregate signatures, as all public keys must be used in the verification, but only one signature is used.
• Minimal Signature Size: This means that the public keys are larger. This is primarily for single signatures because the signatures will require less data to transport around.

Besides the above-mentioned main considerations, there may be other use cases that can benefit from using one over the other.

📘
NOTE: Non-hardened derivation in BLS is by default insecure. The problem is that derivation adds an offset to public keys, which an attacker can add to potential signatures to move them around the derivation tree. This affects the different schemes to various degrees:

• Basic: This is completely insecure and derivation should not be used with the Basic scheme.
• Augmented: This is secure as the message changes if the public key changes, which prevents an attacker from moving signatures.
• Proof of Possession: Is also insecure, but slightly less than the Basic scheme. An attacker will only be able to move signatures between public keys for which a PoP is known.

Using BLS

The interface for BLS is very similar to normal Schnorr/ECDSA in the functionality it provides, so the above sections for different operations can be used to see how to interact with BLS.

There are a few notable differences though:

• Core API:
  • There are no pre-signatures, so generate pre-signatures and sign with pre-signatures are not available for BLS.
  • Sign works as sign with pre-signatures in that there are no communication between nodes, and thus no need for a session configuration.
  • There is a PoPProve method to create the Proof of Possession of a key. This only works with keys from the PoP scheme.
• Static utility methods:
  • There are methods for generating and verifying PoPs.
  • There are methods for aggregating (combining) signatures and checking aggregated signatures.

Example

There are a couple of examples for BLS in the TSM demo repository:

• Normal sign: Can be found in Go, Java, and Node.JS.
• Signing and verifying with aggregate signatures: Can be found in Go, Java, and Node.JS.

Updated 3 months ago