Improve usage of hashing for trimmer friendliness

[vcsjones]

Currently, when we want one-shot hashes, we offer, in our public API, HashType.HashData. Often enough we expose other APIs that operate off of HashAlgorithmName which is a strongly-typed string. When we wanted to one-shot with HashAlgorithmName were switching over the name, and calling the appropriate static method.

This however is not trimmer friendly. Those APIs that accept a HashAlgorithmName were pulling in all of the hash types, even if HashAlgorithmName.SHA256 (for example) is the only one used.

Our actual one-shot implementations want string of the hash algorithm name. So we were doing something like this:

graph LR HAN[HashAlgorithmName] subgraph Switch HAN --> MD5 HAN --> SHA1 HAN --> SHA256 HAN --> SHA384 HAN --> SHA512 HAN --> SHA3_256 HAN --> SHA3_384 HAN --> SHA3_512 end MD5 --> HashProviderDispenser SHA1 --> HashProviderDispenser SHA256 --> HashProviderDispenser SHA384 --> HashProviderDispenser SHA512 --> HashProviderDispenser SHA3_256 --> HashProviderDispenser SHA3_384 --> HashProviderDispenser SHA3_512 --> HashProviderDispenser 

Loading

Now we are doing

graph LR HashAlgorithmName --> HashProviderDispenser 

Loading

We still need to do some switching to determine hash algorithm sizes, however we are not rooting any types. The only thing we are using are public constants off of the types, which the compiler will inline.

This also, as a small matter of performance, reduces some indirection as well.

Fixes #91181.

[ghost]

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

Issue Details

---

Currently, when we want one-shot hashes, we offer, in our public API, HashType.HashData. Often enough we expose other APIs that operate off of HashAlgorithmName which is a strongly-typed string. When we wanted to one-shot with HashAlgorithmName were switching over the name, and calling the appropriate static method.

This however is not trimmer friendly. Those APIs that accept a HashAlgorithmName were pulling in all of the hash types, even if HashAlgorithmName.SHA256 (for example) is used.

Our actual one-shot implementations want string of the hash algorithm name. So we were doing something like this:

graph LR HAN[HashAlgorithmName] subgraph Switch HAN --> MD5 HAN --> SHA1 HAN --> SHA256 HAN --> SHA384 HAN --> SHA512 HAN --> SHA3_256 HAN --> SHA3_384 HAN --> SHA3_512 end MD5 --> HashProviderDispenser SHA1 --> HashProviderDispenser SHA256 --> HashProviderDispenser SHA384 --> HashProviderDispenser SHA512 --> HashProviderDispenser SHA3_256 --> HashProviderDispenser SHA3_384 --> HashProviderDispenser SHA3_512 --> HashProviderDispenser 

Loading

Now we are doing

graph LR HashAlgorithmName --> HashProviderDispenser 

Loading

We still need to do some switching to determine hash algorithm sizes, however we are not rooting any types. The only thing we are using are public constants off of the types, which the compiler will inline.

This also, as a small matter of performance, reduces some indirection as well.

Fixes #91181.

Author:	vcsjones
Assignees:	-
Labels:	area-System.Security
Milestone:	-

[adamsitnik]

LGTM, thank you for providing the explanation and the mermaid graph, so I could learn something by reviewing this PR. 👍