search

anoma / ferveo

An implementation of a DKG protocol for front-running protection on Anoma.
https://anoma.net
GNU General Public License v3.0
78 stars 20 forks source link

Instantiate public key crypto primitives #11

Closed joebebel closed 3 years ago

joebebel commented 3 years ago

Unlike #10 there is really only one choice for public key primitives, BLS12-381 curve with the described key agreement/encryption/signature schemes. This is mostly dictated by the small number of acceptable choices and also desire to reuse existing trusted setups.

Nevertheless, alternatives should be discussed and choices finalized, and then implementations of primitives written and/or imported from existing crates.

joebebel commented 3 years ago

Actually, it is worth discussing whether the VSS/DKG participant public keys should be a different signature scheme instead of BLS, as there probably are not enough participants to justify aggregation. Probably the best approach is to use the same scheme as the ledger, although the keys should be generated separately for use in the DKG.

joebebel commented 3 years ago

Current plan is to also allow BLS12-377 because of future potential for snark composition (likely negligible additional work over BLS12-381; probably a compile-time switch)

DKG message signatures will probably be Ed25519 because performance will be much better than BLS signatures for small validator sets (less likely that BLS signature aggregation will offset the pairing cost; please prove me wrong if this is not the case)

Key exchange will probably be over BLS12-{377,381} to minimize code duplication; while I had hoped to use x25519 key exchange to leverage existing crates, it is simpler to depend on one curve/dependency and reimplement the DH step.

joebebel commented 3 years ago

Actually, this is not as clear now.

It seems possible to implement the BZ03 threshold encryption scheme with Schnorr signatures instead of BLS signatures (basically, W plays the role of a signature verifying r) which gives flexibility to not use a BLS curve, but rather a highly 2-adic curve like one of zcash's pasta curves.

  1. bls12-381/377 with pairing: U, W are G1, G2 so ciphertext is 48+32+96=176 bytes and ciphertext validity is 1 pairing check (slightly batchable). Can use KZG commitments and also randomness beacon is possible
  2. bls12-381/377 with schnorr/NIZKP: U,W are G1, nizkp is 2 scalars, ciphertext is 48+32+48+64=192 bytes, ciphertext validity is 1 schnorr check (probably not batchable). Can use KZG and implement randomness beacon
  3. zcash pasta curve: U,W are G points+nizkp is 2 scalars, ciphertext is 32+32+32+64 = 160 byte, validity check is 1 schnorr check. Cannot use KZG commitments and also is not clear if we can implement randomness beacon (requires further discussion)

A cash pasta curve also potentially allows recursion/composition, instead of composition with bls12-377.

The loss of KZG commitments is a downside as well but the increased performance of a pasta curve may make up for it.

joebebel commented 3 years ago

We have a fairly clear direction now on the threshold encryption scheme and curve selection, with some performance tweaks still needed. However the basic scheme is described and instantiated on BLS12-381, with no major changes anticipated.