search

ZenGo-X / multi-party-ecdsa

Rust implementation of {t,n}-threshold ECDSA (elliptic curve digital signature algorithm).
GNU General Public License v3.0
982 stars 313 forks source link

Test migration to ff crate #18

Closed omershlo closed 5 years ago

omershlo commented 6 years ago

https://github.com/zkcrypto/ff contain Traits and utilities for working with finite fields. Before using it let's test how it can fits in our design. i.e. use it instead of mod_mul or mod_sub

mortendahl commented 6 years ago

It seems that the only operations for free are those in the PrimeFieldRepr trait.

If that's indeed the cases, and assuming more than that is needed, then I'm not convinced this is the right direction to take: the performance on those select operations is perhaps better than eg GMP and RAMP but it would probably not be the case moving to anything more advanced (not least since they'd have to be implemented afaict).

I suspect that most of the benefits from having a common interface and implementation for various rings and fields can be achieved easily on top of eg GMP.

omershlo commented 6 years ago

@mortendahl Basically what you are saying is that once we will encounter a new required method that we will need to implement it will be 1)easier 2)more efficient to implement it directly on top of GMP than using the u64 limbs to implement it and plug it to the interface ? (I agree)

Question: looking at https://github.com/zkcrypto/ff/blob/master/ff_derive/src/lib.rs it seems that all the arithmetic we need for elliptic curves can be derived using the methods in the PrimeFieldRepr trait. This is also the main reason for interest in this interface imho - to be able to make our code work for all elliptic curves by just changing the EC parameters instead of using a different library with different interface for every curve. Intuitively there will be some performance degradations. Can we separate the use of GMP/RAMP for general modular arithmetic operations and ff for elliptic curve arithmetic? meaning that https://github.com/KZen-networks/multi-party-ecdsa/blob/master/src/cryptographic_primitives/proofs/dlog_zk_protocol.rs#L64-L67 will use BigInt but https://github.com/KZen-networks/multi-party-ecdsa/blob/master/src/cryptographic_primitives/proofs/dlog_zk_protocol.rs#L83-L92 will use group and ff?

mortendahl commented 6 years ago

it's good you insisted @omershlo!

after having taken a second look I see we can also get the Prime trait implemented for free, which contains more useful methods (but the struct needs to be public for it to show up in the documentation, which I had missed)

could a next step be to evaluate how well the operations of the current code base fits with what is offered by ff?

gbenattar commented 6 years ago

I suggest to use it in a isolated part of our code and see how it feels, we can start with that. If it make us remove significantly code we wrote (for instance in here: https://github.com/KZen-networks/cryptography-utils) or provides more ability / abstractions, then it is a win (assuming the crate is trustable and well maintained).

gbenattar commented 6 years ago

See here https://github.com/KZen-networks/cryptography-utils/issues/2. This will be our first POC.