Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Test migration to ff crate #18

Closed
omershlo opened this issue Jul 7, 2018 · 5 comments
Closed

Test migration to ff crate #18

omershlo opened this issue Jul 7, 2018 · 5 comments
Assignees

Comments

@omershlo
Copy link
Contributor

omershlo commented Jul 7, 2018

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
Copy link

mortendahl commented Jul 9, 2018

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
Copy link
Contributor Author

omershlo commented Jul 9, 2018

@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
Copy link

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
Copy link
Contributor

gbenattar commented Jul 17, 2018

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
Copy link
Contributor

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

davidsemakula pushed a commit to davidsemakula/multi-party-ecdsa that referenced this issue Jul 25, 2023
* Fix broken link to threshold signatures article (ZenGo-X#185)

* Map errors instead of expecting

* fix check warnings

---------

Co-authored-by: Evan Tedesco <Evantedesco@gmail.com>
Co-authored-by: 1xstj <106580853+1xstj@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants