Test migration to ff crate about multi-party-ecdsa

[mortendahl]

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]

@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]

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]

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]

See here ZenGo-X/curv#2. This will be our first POC.