Support pluggable crypto providers

[flub]

We would like to investigate supporting pluggable crypto providers, similar how RustLS itself supports.

[miruji]

Overall, in #3968 the problem is that Iroh does not work on GNU/MSVC. The issue is related to how rustls and ring behave in this regard.

ctz replied as follows:

Here's a list of Intel CPUs that rustlsCheck.exe above, does not work on:

Nehalem
Westmere
Sandybridge
Ivybridge
Haswell
Broadwell
Saltwell
Silvermont
Goldmont
Goldmont Plus
Tremont
Snow Ridge

Those are quite old. But there seems to be a general problem of no dynamic dispatch for use of BMI1 or SSE4a instructions. That is typical of an executable compiled with an inappropriate profile, like target-cpu=x86-64-v3 or target-cpu=native.

This is not inherent in the x86_64-pc-windows-msvc target (which targets x86_64-v1 profile), and is not a problem in any of the crates you have filed bugs against.

He also suggested using aws-lc-rs, which helped fix the problem.

In general, I see Iroh as a library that is supported on Windows, therefore I ask to switch to aws-lc-rs instead of ring. Overall, this library is maintained by a larger team and resources and is primarily stable and adapts to systems. Amazon is still a big company and who better than them to know networking problems, while ring is mentioned as experimental by the author.

It would be bad to stay on ring because about 50/50 of players in my game encountered this problem worldwide, and this will also lead to problems for others in similar network projects on Windows; I also do not exclude that this may arise for something else.

I looked at the Iroh code and understood that there are already ready flags and this fixes it simply;
cargo

quinn = { package = "iroh-quinn", version = "0.16.1", default-features = false, features = ["rustls-aws-lc-rs"] }
rustls = { version = "0.23.37", default-features = false, features = ["aws-lc-rs"] }
webpki = { package = "rustls-webpki", version = "0.103.7", features = ["aws-lc-rs"] }

And that very line to
let client_private_key = rustls::crypto::aws_lc_rs::sign::any_eddsa_type(&client_private_key)?;

That is, nothing else needs to be changed. aws-lc-rs in this regard will not lose SIMD acceleration or anything like that, it will simply dynamically choose, as I understand, what exists on the system. I also did not notice performance changes for my large game overall or an increase in library size. So, it means that switching can be done without any issues for Iroh and its users right now, which I would recommend for future stability and multi-platform support.

The most compromise solution I could find is simply to add, following the example of webpki, rustls, and your fork of quinn — add a feature flag for using aws-lc-rs. Then users will be able to choose it themselves, especially since everything is already ready for this in the code.

[matheus23]

In general, I see Iroh as a library that is supported on Windows, therefore I ask to switch to aws-lc-rs instead of ring. Overall, this library is maintained by a larger team and resources and is primarily stable and adapts to systems. Amazon is still a big company and who better than them to know networking problems, while ring is mentioned as experimental by the author.

We also support wasm, which aws-lc-rs doesn't compile to unfortunately.

The most compromise solution I could find is simply to add, following the example of webpki, rustls, and your fork of quinn — add a feature flag for using aws-lc-rs. Then users will be able to choose it themselves, especially since everything is already ready for this in the code.

Yes, this is what will happen in the 0.98 release. We'll also add a builder method iroh::endpoint::Builder::crypto_provider() that'll allow you to specify the exact rustls::crypto::CryptoProvider that you want to use - aws-lc-rs, ring, rustls-graviola, etc.
(However that is in addition to the feature flag unfortunately.)

[miruji]

We also support wasm, which aws-lc-rs doesn't compile to unfortunately.

But you can make a flag in features to select aws-lc-rs so that users can specify it manually. I gave an example above, and it did not break WASM. But if you are specifically concerned about it, you can configure it so that ring is used for it.

Yes, this is what will happen in the 0.98 release. We'll also add a builder method iroh::endpoint::Builder::crypto_provider() that'll allow you to specify the exact rustls::crypto::CryptoProvider that you want to use - aws-lc-rs, ring, rustls-graviola, etc.
(However that is in addition to the feature flag unfortunately.)

Yes, I think this is an excellent solution both for support and for fixing the bug that I encountered and that others will encounter.

[DarkmatterVale]

I've put up a more generic solution in #3984 , which enables users to own the full lifecycle of the crypto configuration by exposing the underlying rustls configuration. There may still be some feature flags we need to add, like mentioned above, but this will make the implementation much more flexible