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

Use a better optimized numeric library than GMP #13

Open
vkomenda opened this issue Mar 14, 2019 · 8 comments
Open

Use a better optimized numeric library than GMP #13

vkomenda opened this issue Mar 14, 2019 · 8 comments

Comments

@vkomenda
Copy link

vkomenda commented Mar 14, 2019

According to the results of the competition the GMP dependency is a performance bottleneck. It should be replaced on x86_64 with a better optimized library such as MPIR.

MPIR is supported by Flint, which in turn has Rust bindings. The available Rust bindings for Flint are not suitable in their present state because they build Flint using the GMP dependency instead of MPIR. So possibly instead of the redirection via Flint, direct MPIR bindings could be provided.

Although MPIR is faster than GMP, it supports less CPU architectures, e.g, it doesn't support ARM at the moment. For completeness we would need either a Cargo feature allowing to choose between the two libraries, or an intermediate crate providing bindings to either of the two libraries. Issue #7 discussed a backend along these lines. I personally think a Cargo feature would suffice to switch between MPIR and GMP because these have a high degree of similarity.

@burdges
Copy link
Contributor

burdges commented Mar 14, 2019

I suspect any VDF must be tuned to a particular architecture for deployment anyways, but maybe it simplifies downstream code if everything runs on ARM too.

@burdges
Copy link
Contributor

burdges commented Mar 19, 2019

Anyone who wants to write MPIR bindings, or do other optimizations, could apply for funding at https://github.com/w3f/Web3-collaboration

I'd personally prefer we spend any VDF budget on isogenies because isogenies VDFs are much more flexible, and the work yields soo many other cool toys, but some MPIR bindings sound inexpensive and handy regardless.

@vkomenda
Copy link
Author

vkomenda commented Mar 19, 2019

Do you mean pairing-based isogeny VDFs or trapdoor-based ones? Is there any particular kind of isogenies that offers itself to implementation?

@burdges
Copy link
Contributor

burdges commented Mar 19, 2019

I meant the pairing-based isogeny VDF, mostly because its proofs are composable, which likely improves liveness in some applicaitons. It provides encryption to the future too, but no idea how one uses that. It also yields a small but quantum annoying signature and VRF, which support aggregation for a common signer. And some IBE/IBS scheme with better aggregation but quantum annoyance only per issued key. And more..

@DemiMarie
Copy link
Contributor

@burdges can you explain “quantum annoying”?

@vkomenda
Copy link
Author

@DemiMarie, it's from the paper:
"if the adversary cannot break sequentiality, even when he is allowed a quantum precomputation before seeing the point Q, we say that the VDF is quantum annoying."

@burdges
Copy link
Contributor

burdges commented Mar 20, 2019

Almost all existing public key cryptography has the property that a quantum computer can break the public key itself. And they classical computer can decrypt everything after that. In a quantum annoying scheme, the adversary cannot break the public key but they can break individual key exchanges or forge individual signatures.

Imaginary quadratics VDFs are quantum annoying because we believe the adversary must use the quantum computer separately to learn the group order for each discriminant. Also, the isogenies VDF using pairings is quantum annoying because they must compute the discrete log for H_2(m) separately for each m.

As another example, an axolotl double ratchet is arguably quantum annoying too, but an adversary has more time to run the quantum computer for key exchange cases, so this does nothing.

@burdges
Copy link
Contributor

burdges commented Apr 18, 2019

Also relevant for https://github.com/cambrian/accumulator most likely.

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