# [−][src]Crate bls_like

# Aggregate BLS signature library with extensive tuning options.

In short, anyone using BLS signatures should normally choose both an orientation as well as some aggregation and batching strategies These two decissions impact performance dramaticaly, but making the optimal choises requires some attentiom. This crate employs convenient abstraction boundaries between curver arithmatic, verifier routines, and aggregated and/or batched BLS signatures.

### Pairings

If we have two elliptic curve with a pairing `e`

, then
a BLS signature `sigma = s*H(msg)`

by a public key `S = s g1`

can be verified with the one equation `e(g1,sigma) = e(S,H(msg))`

.
These simple BLS signatures are very slow to verify however
because the pairing map `e`

is far slower than many cryptographic
primitives.

Our pairing `e`

maps from a small curve over `F(q)`

and a larger
curve over `F(q^2)`

into some multipliccative group if a field,
normally over `F(q^12)`

. In principle, this map `e`

into `F(q^12)`

makes pairing based cryptography like BLS less secure than
other elliptic curve based cryptography, which further slows down
BLS signatures by requiring larger `q`

.

### Arithmatic

An almost universally applicable otimization is to seperate the
"Miller loop" that computes in `F(q)`

and `F(q^2)`

from the slow
final exponentiation that happens in `F(q^12)`

. So our actual
verification equation more resembles `e(-g1,sigma) e(S,H(msg)) = 1`

.

As one curve is smaller and hence faster, the user should choose
which orientation of curves they prefer, meaning to which curve
they hash, and which curves hold the signatues and public keys.
In other words, your desired aggregation techniques and usage
characteristics should determine if youp refer the verification
equation `e(g1,sigma) = e(S,H(msg))`

or the fliped form
`e(sigma,g2) = e(H(msg),S)`

. See `UsualBLS`

and `TinyBLS`

.

### Aggregation

We consder BLS signatures interesting because they support
dramatic optimizations when handling multiple signatures together.
In fact, BLS signatures support aggregation by a third party
that makes signatures smaller, not merely batch verification.

All this stems from the bilinearity of `e`

, meaning we reduce
the number of pairings, or size of the miller loop, by appling
rules like `e(x,z)e(y,z) = e(x+y,z)`

, `e(x,y)e(x,z) = e(x,y+z)`

,
etc.

In essence, our aggregation tricks fall into two categories, linear aggregation, in which only addition is used, and delinearized optimiztions, in which we multiply curve points by values unforseeable to the signers. In general, linear techniques provide much better performance, but require stronger invariants be maintained by the caller, like messages being distinct, or limited signer sets with proofs-of-possession. Also, the delinearized techniques remain secure without tricky assumptions, but require more computation.

### Verification

We can often further reduce the pairings required in the verification equation, beyond the naieve information tracked by the aggregated signature itself. Aggregated signature must state all the individual messages and/or public keys, but verifiers may collapse anything permitted. We thus encounter aggregation-like decissions that impact verifier performance.

We therefore provide an abstract interface that permits doing further aggregation and/or passing any aggregate signature to any verification routine.

As a rule, we also attempt to batch normalize different arithmatic outputs, but concievably small signer set sizes might make this a pessimization.

## Re-exports

`pub use single::PublicKey;` |

`pub use single::KeypairVT;` |

`pub use single::Keypair;` |

`pub use single::SecretKeyVT;` |

`pub use single::SecretKey;` |

`pub use single::Signature;` |

## Modules

delinear | Delinearized batching and aggregation for BLS signatures |

distinct | Aggregation for BLS signatures with distinct message. |

pop | Aggregation of BLS signatures using proofs-of-possession |

single | Unaggreagated BLS signatures |

verifiers | Algorithms for optimized verification of aggregate and batched BLS signatures. |

## Structs

Message | Internal message hash type. Short for frequent rehashing
by |

TinyBLS | Infrequently used BLS variant with tiny 48 byte signatures and 96 byte public keys, |

UsualBLS | Usual BLS variant with tiny 48 byte public keys and 96 byte signatures. |

## Constants

Z_BLS | Usual aggregate BLS signature scheme on ZCash's BLS12-381 curve. |

## Traits

EngineBLS | A weakening of |

Signed | Representation of an aggregated BLS signature. |

## Type Definitions

PublicKeyAffine | |

PublicKeyProjective | |

SignatureAffine | |

SignatureProjective | |

ZBLS | Usual aggregate BLS signature scheme on ZCash's BLS12-381 curve. |