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

Switch to subtle-ng #68

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

davidrusu
Copy link

Hello, I'm working with some zkcrypto crates that depend on subtle-ng but I'm not able to interoperate with the ff family of crates since we're still on the subtle package here.

Do you mind taking this change to switch us over to subtle-ng? We'll have to propagate this change throughout other packages as well.

@davidrusu
Copy link
Author

Ping on this issue.

I have a crate I'd like to publish that is depending on this branch. I'd rather not publish my fork of ff to crates.io

Would you prefer a PR with just the subtle-ng change (no clippy run)?

@tarcieri
Copy link
Contributor

tarcieri commented Mar 2, 2022

I just wanted to note that if you do this, it will be a difficult transition for @RustCrypto.

We use subtle for https://github.com/RustCrypto/elliptic-curves but also in quite a few other things like symmetric cryptography implementations. If this were to change then we would wind up in the situation where some crates are using subtle-ng and others are using subtle.

For crates that combine things like ECC and symmetric cryptography, such as ECIES systems, this means that until we can get everything switched over (and we are just wrapping up a set of symmetric crypto releases), crates like this would have to deal with e.g. incompatible Choice and CtOption as sourced from both subtle and subtle-ng.

@davidrusu
Copy link
Author

I'm not intimately familiar with the history of these crates, but the README on https://github.com/zkcrypto/subtle-ng suggests that subtle is not maintained by someone who likes to co-operate with the community.

So, sure, there will be some pain in the transition, but I'd feel much better if a low-level dependency of the crypto ecosystem is maintained by a group we can all trust and work with.

If someone has more knowledge of the state of these two crates, please share!

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

Successfully merging this pull request may close these issues.

2 participants