Add support for aws_lc_rs as crypto backend

[BiagioFesta]

Starting from 0.22.0, rustls, ecosystem has started supporting aws-lc-rs as crypto back-end. This latter replaces crypto functionalities provided by ring.

The main reason behind this is to provide FIPS compliance in the future via aws-lc:

Optional support for cryptography from aws-lc-rs. Once the certification process completes , we will support FIPS mode using aws-lc-rs.

---

This PR is implementing the same supporting mechanism.

In short:

• if cfg(feature = "ring") -> ring (this will be the default)
• if cfg(feature = "aws-lc-rc") -> aws-lc-rs
• if both -> compile_error! EDIT: ring
• if none -> compile_error!

[djc]

Given that Cargo features are supposed to be additive, I'm not a fan of this:

• if both -> compile_error!

I would suggest just picking ring in that case, or providing explicit access to a crypto provider via some kind of trait (not sure how invasive that would be to the API).

[cpu]

I was hoping the aws-lc-rs backend would unblock RSA key generation support, but it looks as though there's upstream work required. I've filed a feature req: aws/aws-lc-rs#296

[BiagioFesta]

Given that Cargo features are supposed to be additive, I'm not a fan of this:

• if both -> compile_error!

I would suggest just picking ring in that case, or providing explicit access to a crypto provider via some kind of trait (not sure how invasive that would be to the API).

Fixed, CI still fails also because some --no-default-features tests. What about that case?

[est31]

compile_error is fine in that case, tests should be changed to either specify ring or aws_lc_rs. The main important property is that cargo features stay additive.

[est31]

Maybe the name can be bikeshedded but otherwise this is fine to go.

[BiagioFesta]

Codecoverage test fails but I think it is not fair :)

[cpu]

Codecoverage test fails but I think it is not fair :)

Yup! The flagged lines are missing coverage on main, don't worry about that one 👍

[cpu]

Thanks for taking this on 🚀

I think it would be interesting to consider how the KeyPair APIs might need to change to allow runtime selection of the backing crypto library but it might make sense to hash that out in a follow-up issue.

[djc]

Nothing to add to @cpu's feedback, nice work!

[cpu]

Thanks for iterating on this. There's just one last thing to fix:

The Windows CI task fails right now with the aws-lc-rs backend feature because it needs nasm as a build time dependency on that OS. Could you add something like this to the relevant bit of CI?

There's an upstream issue that I hope will let us remove this in the future.

[cpu]

Thanks!