Add rustcrypto as a backend

[mike-marcacci]

I have a need for a pure-rust toolchain, even if it comes with some performance penalty.

This adds a verify-rustcrypto feature that uses rustcrypto in place of ring or aws-lc-rs. The only meaningful changes are in verify.rs.

I used substantial AI to check these implementations for correctness against the corresponding RFC's, but I am NOT an expert. This is working well in my proof-of-concept, but needs careful scrutiny by a human who has more familiarity with these specs than me.

A few notes:

• Both ring and aws-lc-rs don't appear to support arbitrary salt lengths, while RustCrypto does.
• I followed the existing feature priority (now ring > aws-lc-rs > rustcrypto), but this means testing with --all-features can be unintuitive
• To pass MSRV checks in CI, I ensured minimal changes to Cargo.lock, but did not constrain them in Cargo.toml to avoid over-constraining.
• CI is running nightly clippy, which is complaining about files that were not changed in this PR. Happy to fix those too, but didn't want to clutter the PR unnecessarily.

[mike-marcacci]

To add, the security finding is real: the rust-native RSA implementation is not constant time, and this appears to still be outstanding.

However, it is not exploitable here, as verification never sees the private key.

[cpu]

I think maintaining first party cryptography integrations for every niche is going to be untenable, especially given the limited resources this crate has for maintenance. Ring and aws-lc-rs are reasonable choices for first party integration because they share the ~same API and cover most bases. Cargo features are also a frustratingly limited configuration mechanism with lots of downsides (as you mention w.r.t --all-features).

Do you have interest in proposing and/or developing a more general extension mechanism by which cryptography providers can be provided external to this crate? An integration with RustCrypto (or SymCrypt, or Botan, or OpenSSL, or Graviola, etc) could then be implemented with that mechanism without requiring this crate to maintain it. That's the approach that crates like rustls have pursued, and is also a pattern I've been pushing for crates like instant-acme.

[cpu]

I have a need for a pure-rust toolchain, even if it comes with some performance penalty.

Have you considered using x509-cert instead of x509-parser? I believe it has significant overlap, but is well integrated into the RustCrypto ecosystem.

[mike-marcacci]

Thanks @cpu. I agree that using rust features feels a bit clumsy, especially with the meaningful new code I'm introducing.

I considered making a trait abstraction, similar in spirit to rustls's CryptoProvider. Is that something this project would be open to?

On the surface x509-cert would be a better fit for the "pure rust" requirement, but in my particular case x509-parser was a transitive dependency. I'm perfectly happy running off a fork – I mostly need this for a proof-of-concept, and figure somebody else might get value out of it.

If a more generic extension mechanism would be preferable, I can take a shot at that; if this introduces too substantial a maintenance burden, I'm happy to close it with no hard feelings and leave the PR as a reference for anybody who might have the same need.

[cpu]

I considered making a trait abstraction, similar in spirit to rustls's CryptoProvider. Is that something this project would be open to?

That would be my preference, but I can't speak for chifflier. I would recommend waiting on his reply before investing too much time one way or the other since he's the final authority for this crate. We can probably draw inspiration from instant-acme#268 and similar existing approaches.

On the surface x509-cert would be a better fit for the "pure rust" requirement, but in my particular case x509-parser was a transitive dependency.

That makes sense 👍

If a more generic extension mechanism would be preferable, I can take a shot at that; if this introduces too substantial a maintenance burden, I'm happy to close it with no hard feelings and leave the PR as a reference for anybody who might have the same need.

Let's leave it open for now, but I think I will probably hold off on doing a code review for now. When chifflier has a chance to weigh in I'll react accordingly, either helping review the code to get it merged as-is, or collaborating on a more extensible solution.

In either case, thanks for the contribution + discussion :-)