Use output size helpers for cryptographic primitives #82800
Conversation
ghost
assigned 
|
Tagging subscribers to this area: @dotnet/area-system-security, @vcsjones Issue DetailsThis updates a few places that can use algorithm output size helpers. Closes #67059
|
There was a problem hiding this comment.
LGTM, thank you @vcsjones !
One day we need to discuss our benchmarks coverage:
https://github.com/dotnet/performance/tree/main/src/benchmarks/micro/libraries/System.Security.Cryptography.Primitives
https://github.com/dotnet/performance/tree/main/src/benchmarks/micro/libraries/System.Security.Cryptography.X509Certificates
https://github.com/dotnet/performance/tree/main/src/benchmarks/micro/libraries/System.Security.Cryptography
src/libraries/Common/src/System/Security/Cryptography/RSACng.EncryptDecrypt.cs
Show resolved
Hide resolved
| // Since it isn't a fatal error to miscalculate the estimatedSize, don't throw an exception. Just truck along. | ||
| _ => KeySize / 4, | ||
| }; | ||
| int estimatedSize = GetMaxSignatureSize(DSASignatureFormat.IeeeP1363FixedFieldConcatenation); |
There was a problem hiding this comment.
Is this more expensive? The implementation of the method isn't trivial, but maybe it doesn't matter?
There was a problem hiding this comment.
Maybe in a micro-benchmark, but ECDSA signing and verifying is going to dominate. For IeeeP1363FixedFieldConcatenation it basically boils down to AsymmetricAlgorithmHelpers.BitsToBytes(KeySize) * 2; Where BitsToBytes just does the "ceiling then divide by 8". I wouldn't be surprised if the JIT inlined BitsToBytes.
This updates a few places that can use algorithm output size helpers.
Closes #67059