Rework KDF interface #1551
Rework KDF interface #1551
Conversation
Codecov Report
@@ Coverage Diff @@
## main #1551 +/- ##
==========================================
- Coverage 96.51% 96.34% -0.18%
==========================================
Files 75 75
Lines 15355 15521 +166
==========================================
+ Hits 14820 14953 +133
- Misses 535 568 +33
... and 1 file with indirect coverage changes 📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
ctz
force-pushed
the
jbp-kdf-interface
branch
from
27667ef
to
a5b4b8b
Compare
ctz
force-pushed
the
jbp-kdf-interface
branch
from
a5b4b8b
to
0e5a64f
Compare
| @@ -2422,6 +2422,54 @@ fn test_tls13_exporter() { | |||
| } | |||
| } | |||
|
|
|||
| #[test] | |||
| fn test_tls13_exporter_maximum_output_length() { | |||
There was a problem hiding this comment.
nb. this test uncovers a panic against rel-0.21. Since nobody has reported it, and I think it's highly unlikely to be reachable except deliberately writing this code (in which case, why not write panic!() and save some effort) I don't think it's a pressing concern. However this test could be a backport candidate if we choose to fix that.
| @@ -15,6 +15,9 @@ pub struct Tls13CipherSuite { | |||
| /// How to compute HMAC with the suite's hash function. | |||
| pub hmac_provider: &'static dyn crypto::hmac::Hmac, | |||
|
|
|||
| /// How to complete HKDF with the suite's hash function. | |||
| pub hkdf_provider: &'static dyn crypto::tls13::Hkdf, | |||
There was a problem hiding this comment.
It looks like hmac_provider has only one user left after this. Is there a way to get rid of it here?
There was a problem hiding this comment.
It would be a slight confusion of the tls13::Hkdf interface to add it there, but on the other hand it would be a much simpler result than requiring the whole of hmac::Hmac when only a tiny proportion of it is actually used. Hmm.
There was a problem hiding this comment.
Have added a final commit which tries this. Seems a bit simpler, but I think it might need a bit of renaming of trait Hkdf to look sensible?
There was a problem hiding this comment.
Yeah, I like the changes but can't think of a better name either -- I guess maybe something like HmacOperations or HashOps? Just leave it for now?
ctz
force-pushed
the
jbp-kdf-interface
branch
2 times, most recently
from
7d4a0d8
to
e8997f9
Compare
ctz
force-pushed
the
jbp-kdf-interface
branch
from
5ec056f
to
ed5b577
Compare
This replaces the HMAC trait in Tls12CipherSuite (there were no other uses of HMAC). Provide an implementation of the new PRF trait in terms of HMAC, for convenience of providers that have a HMAC (common) but not a separate TLS1.2 PRF (relatively uncommon). The *ring* and `provider-example/` providers use this.
Have an impl of this for hmac::Hmac
This means `Hkdf` covers the entire use of TLS1.3 for HMAC/HKDF, and that avoids having to implement the HMAC traits just for this.
ctz
force-pushed
the
jbp-kdf-interface
branch
from
ed5b577
to
82f1ccc
Compare
|
Consistent but relatively small perf regression for handshake latency. @aochagavia should maybe get a run for wall clock benchmarks? |
I think this was due to the extra |
Now we no longer have a depedency on hmac, we can avoid that and save some heap allocations. This marginally improves TLS1.3 handshake performance.
ctz
force-pushed
the
jbp-kdf-interface
branch
from
57ade5b
to
1fd7697
Compare
|
Great to see the icount stuff is paying off :) |
Previously we implemented the TLS1.2 PRF and HKDF ourselves given something that
impl rustls::crypto::hmac::Hmac. As outlined in #1540 (comment) this isn't the right approach for FIPS.This puts both those dependencies behind new traits, referenced from the cipher suite types. The existing implementations we have are recast to be in terms of these traits, and continue to take an
dyn hmac::Hmac. That means writing a crypto provider continues to be as easy as it was previously.