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

Pure Rust implementation? #33

Open
vn971 opened this issue Aug 7, 2020 · 2 comments
Open

Pure Rust implementation? #33

vn971 opened this issue Aug 7, 2020 · 2 comments

Comments

@vn971
Copy link

vn971 commented Aug 7, 2020

Hi. Is it possible to provide a pure Rust-based generation of certificates (that avoids openssl)? There seem to be libraries/apps that generate certificates using Rust already: https://crates.io/crates/certainly

Avoiding openssl makes sense for users who are worried about openssl vulnerabilities and [unnecessary] complexity.

Using the pure-rust implementation could then be hidden under a feature flag if openssl is desired to be used by default.

@breard-r
Copy link
Owner

breard-r commented Aug 7, 2020

Hi!

Well, the choice of a cryptographic library it's not an easy subject. ACMEd uses cryptography in several places and I want only one cryptographic library for all those usages. The most important ones are:

  • key pair generation, PEM import and export
  • either access to the private key's internal components or correct JWK export
  • X.509 certificate generation, manipulation and PEM import
  • CSR generation and DER export
  • TLS

And there is an additional difficulty: the TLS stack must also be used within a decent HTTP client library that does not come with too much dependencies.

The cryptographic libraries I have looked for are :

  • Rust Crypto: no certificate, CSR or TLS support.
  • Ring: as stated in crypto and TLS implementation support #2 there is no RSA key generation (required) and no access to private keys internal components.
  • OpenSSL: has everything excepted the optional Curve 25519 support.
  • Botan: very good candidate, seems to have everything except being used in an HTTP library (but it should be reasonable to add it to an existing one that already support multiple cryptographic libraries like attohttpc).

As you can see, right now OpenSSL is the only choice. Botan is seriously considered to be its successor, but it still requires some work.

By the way, the crate you quoted uses Ring in addition to an RSA library that has not been audited. Considering the very high complexity of correct RSA implementation, I worry much more about such a crate than I do about OpenSSL. Yes, I also yell in pain when I have to deal with the OpenSS-HELL API and I also have been marked by heartbleed. However, RSA being a real mine field, I would rather stick with a well known and audited library like OpenSSL, even though it's painful, rather than use the first one that looks cool.

@vn971
Copy link
Author

vn971 commented Aug 8, 2020

@breard-r thanks for the insightful comment! (Also, was interesting to read it and some of the articles.) Feel free to close the issue if deemed more proper

breard-r added a commit that referenced this issue Aug 17, 2020
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

2 participants