Consider caching digest values for SignedCms.VerifySignature

[bartonjs]

Imagine that all 538 US presidential electors parallel-sign their vote tabulation.

Odds are, all 538 only used one data digest algorithm. So, why digest multiple times?

If SHAKE and friends are allowed in SignedCms with parameterized length, then the cache is theoretically unbounded. If only the fixed size outputs of them are defined for CMS, then the cache has a limit of around a dozen algorithms that it could possibly grow to.

The best place for the cache is probably ContentInfo?

[dotnet-policy-service]

Tagging subscribers to this area: @bartonjs, @vcsjones, @dotnet/area-system-security
See info in area-owners.md if you want to be subscribed.

[vcsjones]

If only the fixed size outputs of them are defined for CMS,

ML-DSA is "pure" mode so there is no digest to cache, is another angle to look at this.

[vcsjones]

My 2c: probably not worth it in a PQC world. Both Pure mode and composites built on pure mode can't cache. External-Mu doesn't help because tr is bound to the public key, and I doubt all 538 of them, or hopefully even 2, have the same public key.

[bartonjs]

When the signer signs with attributes the attribute block is what gets signature verified (and we always force ML-DSA signers to use the attribute block).

But each signer verifies content-digest independently. And that's what the cache would be for.

[bartonjs]

I wrote compute, but I really meant Verify, title updated. The cache would help with parallel signing, too, but only when the parallel signatures were happening on literally the same instance (vs sign/send/load/sign/send/etc).

But, basically, something like

partial class ContentInfo {
  internal ReadOnlySpan<byte> GetDigest(oid or HashAlgorithmName or whatever) {
      return _digests.GetOrAdd(key, ComputeHash);
  }
}

[PranavSenthilnathan]

In ML-DSA we always sign the attributes but for verification we need to accept both signed attributes or content signatures. So the caching suggested wouldn't help in content signature verification, but I think signed attributes are more common anyway. This is what the ML-DSA CMS spec, RFC 9882 section 3.2 recommends:

Use of signed attributes is preferred, but the conventions for signed-data without signed attributes is also described below for completeness.

[bartonjs]

Yeah, it's not fool-proof, or even "hardening". It's just a place that we can spend a little bit of memory to save some CPU. The savings only really kicks in as the number of signers goes up (and requires a non-trivially-small document).

And since the maximum number of digests is so small, it's not even worth using Dictionary, probably just a list of (oid, ReadOnlyMemory<byte>).