Benchmark results

Instruction counts

Significant differences

⚠️ There are significant instruction count differences

Other differences

Wall-time

Significant differences

There are no significant wall-time differences

Other differences

Additional information

Historical results

Checkout details:

• Base repo: https://github.com/rustls/rustls.git
• Base branch: main (834cb11)
• Candidate repo: https://github.com/rustls/rustls.git
• Candidate branch: jbp-rsa-no-params (7ef940a)

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 95.40%. Comparing base (834cb11) to head (7ef940a).
Report is 2 commits behind head on main.

@@           Coverage Diff           @@
##             main    #2505   +/-   ##
=======================================
  Coverage   95.40%   95.40%           
=======================================
  Files          97       97           
  Lines       21881    21881           
=======================================
  Hits        20875    20875           
  Misses       1006     1006           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

This seems reasonable but I'm also not sure I follow what you mean by the commit message for the first commit w.r.t RSA_PKCS1_3072_8192_SHA384 being a "more-restricted" version of the 2048 equivalent.

Can you expand on that a little bit for my own education?

ring's RSA_PKCS1_2048_8192_SHA384 is basically what TLS1.3 calls SignatureScheme rsa_pkcs1_sha384, with the added restriction that public keys must be 2048-8192 bits in size. RSA_PKCS1_3072_8192_SHA384 is the same thing, but public key size restriction is 3072-8192 bits. This is, I assume, intended to meet CNSA standards which require minimum 3072-bit RSA.

So, my argument here is that there are no signatures that are accepted by RSA_PKCS1_3072_8192_SHA384 that are not also accepted by RSA_PKCS1_2048_8192_SHA384. Since this list is additive (every algorithm is allowed a chance to match and verify the signature, and first one accepting the signature wins) having both in the list doesn't make sense.

So, my argument here is that there are no signatures that are accepted by RSA_PKCS1_3072_8192_SHA384 that are not also accepted by RSA_PKCS1_2048_8192_SHA384.

That makes sense. Thanks for the explanation!