This goes from being a single set of keys for ECDSA (with a
purposeful mix of curves) to a set of keys per curve.
That means we can avoid P521 chains in tests when it is not supported.
In those tests, reflect this as additional `KeyType` variants.
This code was meant to strip unnecessary information from the start of a
cachegrind diff. However, for some versions of cachegrind it results in
a completely blank string. Instead of making it work for all cachegrind
versions, it is probably better to get rid of it altogether (it does not
make enough of a difference that the complexity of a proper solution
would be worth it).
When running the comparison locally, we do not have access to past
results and are unable to categorize them as significant or negligible.
Instead of hardcoding a 0.2% threshold, we remove the threshold
altogether and tell users to rely on the CI when they are interested in
the significance of the results.
This commit replaces the existing `CryptoProvider` trait with
a `CryptoProvider` struct. This has several advantages:
* it consolidates all of the cryptography related settings into one API
surface, the `CryptoProvider` struct members. Previously the provider
had methods to suggest default ciphersuites, key exchanges etc, but
the builder API methods could override them in confusing ways.
* it allows removing the `WantsCipherSuites` and `WantsKxGroups` builder
states - the "safe defaults" are automatically supplied by the choice
of a crypto provider. Customization is achieved by overriding the
provider's struct fields. Having fewer builder states makes the API
easier to understand and document.
* it makes customization easier: the end user can rely on "struct update
syntax"[0] to only specify fields values for the required
customization, and defer the rest to an existing `CryptoProvider`.
Achieving this requires a couple of additional changes:
* The cipher suite and key exchange groups are now expressed as `Vec`
elements. This avoids imposing a `&'static` lifetime that would
preclude runtime customization (e.g. the tls*-mio examples that
build the list of ciphersuites at runtime based on command line
flags).
* As a result of the `Vec` members we can no longer offer the concrete
`CryptoProvider`s as `static` members of their respective modules.
Instead we add `pub fn default_provider() -> CryptoProvider` methods
to the `ring` and `aws-lc-rs` module that construct the `CryptoProvider`
with the safe defaults, ready for further customization.
[0]: https://doc.rust-lang.org/book/ch05-01-defining-structs.html#creating-instances-from-other-instances-with-struct-update-syntax
The usage of black box was originally introduced to to ensure the optimizer didn't take advantage of
knowing both the client and the server side of the configuration. However, in this case, the server
and the client run in different processes, so each side of the connection has no compile-time
information about the other side.
Naming cipher suites individually seems like a "detail" feature, and
therefore having to name the provider too is not a large imposition.
Naturally this is a breaking change.
Instead of the type `rustls::crypto:💍:Ring`, the value
`rustls::crypto:💍:RING` implements this, and is more
entertaining to write.
`ServerConfig::builder()` references this by default, and
is equivalent to `ServerConfig::builder_with_provider(crypto:💍:RING)`.
The diffs produced tend to be noisy here because two separate
compilations have different per-type and per-compilation uniqueness. eg:
```
29,792 (124.8%) ???:_ZN5alloc7raw_vec11finish_grow17h463b2c6f0ba30854E.llvm.2614985587368234107
-29,792 (-124.8%) ???:_ZN5alloc7raw_vec11finish_grow17h463b2c6f0ba30854E.llvm.3375118279659775674
```
This diff line is here because some per-compilation unique value (after the '.llvm.') changed, not
because the instruction count changed.
We can chop these out by giving a regular expression to cg_diff.
Joseph Birr-Pixton
Adolfo Ochagavía
Jacob Hoffman-Andrews
Daniel McCarney
Dirkjan Ochtman
Jorge Aparicio