Improve DSA digest handling on macOS

[vcsjones]

Fixes#28634

If you use DSA.CreateSignature on macOS with a digest that is bigger than 160 bits, you get a fairly obscure error that is hard to diagnose. Something like this:

Interop+AppleCrypto+AppleCFErrorCryptographicException: The operation couldn’t be completed. (Internal CSSM error error -2147415807 - Internal error #80010901
at SignTransform_block_invoke /AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/Security/Security-59306.101.1/OSX/libsecurity_transform/lib/SecSignVerifyTransform.c:324)

This is because Apple only supports FIPS-186-2, or SHA1 digests. Using a SHA2 family digest will result in this error.

I am marking this as a draft pending feedback on this is also a breaking change with digests less than 160 bits. It seems that right now, CreateSignature works on any number of bytes <= 20. I'm not entirely sure what the underlying platform is actually doing with a 19-byte hash, but it doesn't throw an error.

However, it seems the intention of the code was that it is always 20 bytes. Furthermore, SignData, which takes raw data and hashes it for you, does not accept MD5.

[ghost]

Tagging subscribers to this area: @bartonjs, @vcsjones, @krwq
Notify danmosemsft if you want to be subscribed.

[vcsjones]

Huh. Those failures are me, but, unexpected. I'll dig in.

[vcsjones]

This is also a breaking change; but it makes DSACryptoServiceProvider consistent across all platforms.

[bartonjs]

Looks reasonable to me, is there still some discovery going on (draft mode)?

[vcsjones]

@bartonjs nothing else that I'm aware of, as long as you're okay with the breaking changes.

[bartonjs]

Yeah, DSACryptoServiceProvider is just around as a compatibility type. It having more functionality than the type it's providing compatibility for seems weird; and I doubt it'll really affect anyone... though we should still doc it as a breaking change.

[vcsjones]

@bartonjs sorry, this isn't quite ready yet -- some of the failures are a result of this change and I need to find time to work through them.

Notably, Windows 7, despite lacking FIPS 186-3, appears to accept digests of any size, so I am trying to figure out what it is actually doing.

[vcsjones]

@bartonjs

The behavior of DSA.CreateSignature on Windows and Linux seems problematic. Consider the following code:

usingvardsa=DSA.Create();varfirst=newbyte[1]{1};varsecond=newbyte[20];second[^1]=1;varsig=dsa.CreateSignature(first);Console.WriteLine(dsa.VerifySignature(second,sig));

This will print true even though there were different inputs. It appears that it zero-extending inputs that are too short.

Perhaps more concerning, it truncates the data, so inputs that are different past the expected digest size are ignored. Consider:

usingvardsa=DSA.Create();dsa.KeySize=2048;varfirst=newbyte[33];first[^1]=0xFF;varsecond=newbyte[33];second[^1]=0x01;varsig=dsa.CreateSignature(first);Console.WriteLine(dsa.VerifySignature(second,sig));

Developers might be using CreateSignature expecting to account for the whole input, not aware that it is truncated.

I'm not exactly sure what the logic for CreateSignature should be since it doesn't accept the expected hash algorithm. At a glance, it seems it should be:

if (KeySize <= 1024 && rgbHash != 20) throw;
if (KeySize > 1024 && rgbHash != 32) throw;

[bartonjs]

I'm not exactly sure what the logic for CreateSignature should be

FIPS 186-3 section 4.6. The input parameter represents Hash(M):

• z = the leftmost min(N, outlen) bits of Hash(M).

Truncation and zero-extension are built-in. (Truncation is important for DSA-1024 using SHA-512)

Developers might be using CreateSignature expecting to account for the whole input, not aware that it is truncated.

Yep. But, there's nothing we can really do about it. Except on the types that only support FIPS 186-1/-2, which can restrict it to 20 bytes. (FIPS 186-2 section 5, specifically says SHA-1)).

[vcsjones]

Hmm, "yikes" that this is exposed on the public API, but alright.

[vcsjones]

@bartonjs I'm going to close this for now while I ponder an alternative change that might be better. Sorry for taking your time with the review of this one.

[vcsjones]

Fixes#28634

If you use DSA.CreateSignature on macOS with a digest that is bigger than 160 bits, you get a fairly obscure error that is hard to diagnose. Something like this:

Interop+AppleCrypto+AppleCFErrorCryptographicException: The operation couldn’t be completed. (Internal CSSM error error -2147415807 - Internal error #80010901
at SignTransform_block_invoke /AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/Security/Security-59306.101.1/OSX/libsecurity_transform/lib/SecSignVerifyTransform.c:324)

This is because Apple only supports FIPS-186-2, or SHA1 digests. Using a SHA2 family digest will result in this error.

I am marking this as a draft pending feedback on this is also a breaking change with digests less than 160 bits. It seems that right now, CreateSignature works on any number of bytes <= 20. I'm not entirely sure what the underlying platform is actually doing with a 19-byte hash, but it doesn't throw an error.

However, it seems the intention of the code was that it is always 20 bytes. Furthermore, SignData, which takes raw data and hashes it for you, does not accept MD5.

[ghost]

Tagging subscribers to this area: @bartonjs, @vcsjones, @krwq
Notify danmosemsft if you want to be subscribed.

[vcsjones]

Huh. Those failures are me, but, unexpected. I'll dig in.

[vcsjones]

This is also a breaking change; but it makes DSACryptoServiceProvider consistent across all platforms.

[bartonjs]

Looks reasonable to me, is there still some discovery going on (draft mode)?

[vcsjones]

@bartonjs nothing else that I'm aware of, as long as you're okay with the breaking changes.

[bartonjs]

Yeah, DSACryptoServiceProvider is just around as a compatibility type. It having more functionality than the type it's providing compatibility for seems weird; and I doubt it'll really affect anyone... though we should still doc it as a breaking change.

[vcsjones]

@bartonjs sorry, this isn't quite ready yet -- some of the failures are a result of this change and I need to find time to work through them.

Notably, Windows 7, despite lacking FIPS 186-3, appears to accept digests of any size, so I am trying to figure out what it is actually doing.

[vcsjones]

@bartonjs

The behavior of DSA.CreateSignature on Windows and Linux seems problematic. Consider the following code:

usingvardsa=DSA.Create();varfirst=newbyte[1]{1};varsecond=newbyte[20];second[^1]=1;varsig=dsa.CreateSignature(first);Console.WriteLine(dsa.VerifySignature(second,sig));

This will print true even though there were different inputs. It appears that it zero-extending inputs that are too short.

Perhaps more concerning, it truncates the data, so inputs that are different past the expected digest size are ignored. Consider:

usingvardsa=DSA.Create();dsa.KeySize=2048;varfirst=newbyte[33];first[^1]=0xFF;varsecond=newbyte[33];second[^1]=0x01;varsig=dsa.CreateSignature(first);Console.WriteLine(dsa.VerifySignature(second,sig));

Developers might be using CreateSignature expecting to account for the whole input, not aware that it is truncated.

I'm not exactly sure what the logic for CreateSignature should be since it doesn't accept the expected hash algorithm. At a glance, it seems it should be:

if (KeySize <= 1024 && rgbHash != 20) throw;
if (KeySize > 1024 && rgbHash != 32) throw;

[bartonjs]

I'm not exactly sure what the logic for CreateSignature should be

FIPS 186-3 section 4.6. The input parameter represents Hash(M):

• z = the leftmost min(N, outlen) bits of Hash(M).

Truncation and zero-extension are built-in. (Truncation is important for DSA-1024 using SHA-512)

Developers might be using CreateSignature expecting to account for the whole input, not aware that it is truncated.

Yep. But, there's nothing we can really do about it. Except on the types that only support FIPS 186-1/-2, which can restrict it to 20 bytes. (FIPS 186-2 section 5, specifically says SHA-1)).

[vcsjones]

Hmm, "yikes" that this is exposed on the public API, but alright.

[vcsjones]

@bartonjs I'm going to close this for now while I ponder an alternative change that might be better. Sorry for taking your time with the review of this one.

[vcsjones]

Fixes#28634

If you use DSA.CreateSignature on macOS with a digest that is bigger than 160 bits, you get a fairly obscure error that is hard to diagnose. Something like this:

Interop+AppleCrypto+AppleCFErrorCryptographicException: The operation couldn’t be completed. (Internal CSSM error error -2147415807 - Internal error #80010901
at SignTransform_block_invoke /AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/Security/Security-59306.101.1/OSX/libsecurity_transform/lib/SecSignVerifyTransform.c:324)

This is because Apple only supports FIPS-186-2, or SHA1 digests. Using a SHA2 family digest will result in this error.

I am marking this as a draft pending feedback on this is also a breaking change with digests less than 160 bits. It seems that right now, CreateSignature works on any number of bytes <= 20. I'm not entirely sure what the underlying platform is actually doing with a 19-byte hash, but it doesn't throw an error.

However, it seems the intention of the code was that it is always 20 bytes. Furthermore, SignData, which takes raw data and hashes it for you, does not accept MD5.

[ghost]

Tagging subscribers to this area: @bartonjs, @vcsjones, @krwq
Notify danmosemsft if you want to be subscribed.

[vcsjones]

Huh. Those failures are me, but, unexpected. I'll dig in.

[vcsjones]

This is also a breaking change; but it makes DSACryptoServiceProvider consistent across all platforms.

[bartonjs]

Looks reasonable to me, is there still some discovery going on (draft mode)?

[vcsjones]

@bartonjs nothing else that I'm aware of, as long as you're okay with the breaking changes.

[bartonjs]

Yeah, DSACryptoServiceProvider is just around as a compatibility type. It having more functionality than the type it's providing compatibility for seems weird; and I doubt it'll really affect anyone... though we should still doc it as a breaking change.

[vcsjones]

@bartonjs sorry, this isn't quite ready yet -- some of the failures are a result of this change and I need to find time to work through them.

Notably, Windows 7, despite lacking FIPS 186-3, appears to accept digests of any size, so I am trying to figure out what it is actually doing.

[vcsjones]

@bartonjs

The behavior of DSA.CreateSignature on Windows and Linux seems problematic. Consider the following code:

usingvardsa=DSA.Create();varfirst=newbyte[1]{1};varsecond=newbyte[20];second[^1]=1;varsig=dsa.CreateSignature(first);Console.WriteLine(dsa.VerifySignature(second,sig));

This will print true even though there were different inputs. It appears that it zero-extending inputs that are too short.

Perhaps more concerning, it truncates the data, so inputs that are different past the expected digest size are ignored. Consider:

usingvardsa=DSA.Create();dsa.KeySize=2048;varfirst=newbyte[33];first[^1]=0xFF;varsecond=newbyte[33];second[^1]=0x01;varsig=dsa.CreateSignature(first);Console.WriteLine(dsa.VerifySignature(second,sig));

Developers might be using CreateSignature expecting to account for the whole input, not aware that it is truncated.

I'm not exactly sure what the logic for CreateSignature should be since it doesn't accept the expected hash algorithm. At a glance, it seems it should be:

if (KeySize <= 1024 && rgbHash != 20) throw;
if (KeySize > 1024 && rgbHash != 32) throw;

[bartonjs]

I'm not exactly sure what the logic for CreateSignature should be

FIPS 186-3 section 4.6. The input parameter represents Hash(M):

• z = the leftmost min(N, outlen) bits of Hash(M).

Truncation and zero-extension are built-in. (Truncation is important for DSA-1024 using SHA-512)

Developers might be using CreateSignature expecting to account for the whole input, not aware that it is truncated.

Yep. But, there's nothing we can really do about it. Except on the types that only support FIPS 186-1/-2, which can restrict it to 20 bytes. (FIPS 186-2 section 5, specifically says SHA-1)).

[vcsjones]

Hmm, "yikes" that this is exposed on the public API, but alright.

[vcsjones]

@bartonjs I'm going to close this for now while I ponder an alternative change that might be better. Sorry for taking your time with the review of this one.

[vcsjones]

Fixes#28634

If you use DSA.CreateSignature on macOS with a digest that is bigger than 160 bits, you get a fairly obscure error that is hard to diagnose. Something like this:

Interop+AppleCrypto+AppleCFErrorCryptographicException: The operation couldn’t be completed. (Internal CSSM error error -2147415807 - Internal error #80010901
at SignTransform_block_invoke /AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/Security/Security-59306.101.1/OSX/libsecurity_transform/lib/SecSignVerifyTransform.c:324)

This is because Apple only supports FIPS-186-2, or SHA1 digests. Using a SHA2 family digest will result in this error.

I am marking this as a draft pending feedback on this is also a breaking change with digests less than 160 bits. It seems that right now, CreateSignature works on any number of bytes <= 20. I'm not entirely sure what the underlying platform is actually doing with a 19-byte hash, but it doesn't throw an error.

However, it seems the intention of the code was that it is always 20 bytes. Furthermore, SignData, which takes raw data and hashes it for you, does not accept MD5.

[ghost]

Tagging subscribers to this area: @bartonjs, @vcsjones, @krwq
Notify danmosemsft if you want to be subscribed.

[vcsjones]

Huh. Those failures are me, but, unexpected. I'll dig in.

[vcsjones]

This is also a breaking change; but it makes DSACryptoServiceProvider consistent across all platforms.

[bartonjs]

Looks reasonable to me, is there still some discovery going on (draft mode)?

[vcsjones]

@bartonjs nothing else that I'm aware of, as long as you're okay with the breaking changes.

[bartonjs]

Yeah, DSACryptoServiceProvider is just around as a compatibility type. It having more functionality than the type it's providing compatibility for seems weird; and I doubt it'll really affect anyone... though we should still doc it as a breaking change.

[vcsjones]

@bartonjs sorry, this isn't quite ready yet -- some of the failures are a result of this change and I need to find time to work through them.

Notably, Windows 7, despite lacking FIPS 186-3, appears to accept digests of any size, so I am trying to figure out what it is actually doing.

[vcsjones]

@bartonjs

The behavior of DSA.CreateSignature on Windows and Linux seems problematic. Consider the following code:

usingvardsa=DSA.Create();varfirst=newbyte[1]{1};varsecond=newbyte[20];second[^1]=1;varsig=dsa.CreateSignature(first);Console.WriteLine(dsa.VerifySignature(second,sig));

This will print true even though there were different inputs. It appears that it zero-extending inputs that are too short.

Perhaps more concerning, it truncates the data, so inputs that are different past the expected digest size are ignored. Consider:

usingvardsa=DSA.Create();dsa.KeySize=2048;varfirst=newbyte[33];first[^1]=0xFF;varsecond=newbyte[33];second[^1]=0x01;varsig=dsa.CreateSignature(first);Console.WriteLine(dsa.VerifySignature(second,sig));

Developers might be using CreateSignature expecting to account for the whole input, not aware that it is truncated.

I'm not exactly sure what the logic for CreateSignature should be since it doesn't accept the expected hash algorithm. At a glance, it seems it should be:

if (KeySize <= 1024 && rgbHash != 20) throw;
if (KeySize > 1024 && rgbHash != 32) throw;

[bartonjs]

I'm not exactly sure what the logic for CreateSignature should be

FIPS 186-3 section 4.6. The input parameter represents Hash(M):

• z = the leftmost min(N, outlen) bits of Hash(M).

Truncation and zero-extension are built-in. (Truncation is important for DSA-1024 using SHA-512)

Developers might be using CreateSignature expecting to account for the whole input, not aware that it is truncated.

Yep. But, there's nothing we can really do about it. Except on the types that only support FIPS 186-1/-2, which can restrict it to 20 bytes. (FIPS 186-2 section 5, specifically says SHA-1)).

[vcsjones]

Hmm, "yikes" that this is exposed on the public API, but alright.

[vcsjones]

@bartonjs I'm going to close this for now while I ponder an alternative change that might be better. Sorry for taking your time with the review of this one.

[vcsjones]

Fixes#28634

If you use DSA.CreateSignature on macOS with a digest that is bigger than 160 bits, you get a fairly obscure error that is hard to diagnose. Something like this:

Interop+AppleCrypto+AppleCFErrorCryptographicException: The operation couldn’t be completed. (Internal CSSM error error -2147415807 - Internal error #80010901
at SignTransform_block_invoke /AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/Security/Security-59306.101.1/OSX/libsecurity_transform/lib/SecSignVerifyTransform.c:324)

This is because Apple only supports FIPS-186-2, or SHA1 digests. Using a SHA2 family digest will result in this error.

I am marking this as a draft pending feedback on this is also a breaking change with digests less than 160 bits. It seems that right now, CreateSignature works on any number of bytes <= 20. I'm not entirely sure what the underlying platform is actually doing with a 19-byte hash, but it doesn't throw an error.

However, it seems the intention of the code was that it is always 20 bytes. Furthermore, SignData, which takes raw data and hashes it for you, does not accept MD5.

[ghost]

Tagging subscribers to this area: @bartonjs, @vcsjones, @krwq
Notify danmosemsft if you want to be subscribed.

[vcsjones]

Huh. Those failures are me, but, unexpected. I'll dig in.

[vcsjones]

This is also a breaking change; but it makes DSACryptoServiceProvider consistent across all platforms.

[bartonjs]

Looks reasonable to me, is there still some discovery going on (draft mode)?

[vcsjones]

@bartonjs nothing else that I'm aware of, as long as you're okay with the breaking changes.

[bartonjs]

Yeah, DSACryptoServiceProvider is just around as a compatibility type. It having more functionality than the type it's providing compatibility for seems weird; and I doubt it'll really affect anyone... though we should still doc it as a breaking change.

[vcsjones]

@bartonjs sorry, this isn't quite ready yet -- some of the failures are a result of this change and I need to find time to work through them.

Notably, Windows 7, despite lacking FIPS 186-3, appears to accept digests of any size, so I am trying to figure out what it is actually doing.

[vcsjones]

@bartonjs

The behavior of DSA.CreateSignature on Windows and Linux seems problematic. Consider the following code:

usingvardsa=DSA.Create();varfirst=newbyte[1]{1};varsecond=newbyte[20];second[^1]=1;varsig=dsa.CreateSignature(first);Console.WriteLine(dsa.VerifySignature(second,sig));

This will print true even though there were different inputs. It appears that it zero-extending inputs that are too short.

Perhaps more concerning, it truncates the data, so inputs that are different past the expected digest size are ignored. Consider:

usingvardsa=DSA.Create();dsa.KeySize=2048;varfirst=newbyte[33];first[^1]=0xFF;varsecond=newbyte[33];second[^1]=0x01;varsig=dsa.CreateSignature(first);Console.WriteLine(dsa.VerifySignature(second,sig));

Developers might be using CreateSignature expecting to account for the whole input, not aware that it is truncated.

I'm not exactly sure what the logic for CreateSignature should be since it doesn't accept the expected hash algorithm. At a glance, it seems it should be:

if (KeySize <= 1024 && rgbHash != 20) throw;
if (KeySize > 1024 && rgbHash != 32) throw;

[bartonjs]

I'm not exactly sure what the logic for CreateSignature should be

FIPS 186-3 section 4.6. The input parameter represents Hash(M):

• z = the leftmost min(N, outlen) bits of Hash(M).

Truncation and zero-extension are built-in. (Truncation is important for DSA-1024 using SHA-512)

Developers might be using CreateSignature expecting to account for the whole input, not aware that it is truncated.

Yep. But, there's nothing we can really do about it. Except on the types that only support FIPS 186-1/-2, which can restrict it to 20 bytes. (FIPS 186-2 section 5, specifically says SHA-1)).

[vcsjones]

Hmm, "yikes" that this is exposed on the public API, but alright.

[vcsjones]

@bartonjs I'm going to close this for now while I ponder an alternative change that might be better. Sorry for taking your time with the review of this one.

[vcsjones]

Fixes#28634

If you use DSA.CreateSignature on macOS with a digest that is bigger than 160 bits, you get a fairly obscure error that is hard to diagnose. Something like this:

Interop+AppleCrypto+AppleCFErrorCryptographicException: The operation couldn’t be completed. (Internal CSSM error error -2147415807 - Internal error #80010901
at SignTransform_block_invoke /AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/Security/Security-59306.101.1/OSX/libsecurity_transform/lib/SecSignVerifyTransform.c:324)

This is because Apple only supports FIPS-186-2, or SHA1 digests. Using a SHA2 family digest will result in this error.

I am marking this as a draft pending feedback on this is also a breaking change with digests less than 160 bits. It seems that right now, CreateSignature works on any number of bytes <= 20. I'm not entirely sure what the underlying platform is actually doing with a 19-byte hash, but it doesn't throw an error.

However, it seems the intention of the code was that it is always 20 bytes. Furthermore, SignData, which takes raw data and hashes it for you, does not accept MD5.

[ghost]

Tagging subscribers to this area: @bartonjs, @vcsjones, @krwq
Notify danmosemsft if you want to be subscribed.

[vcsjones]

Huh. Those failures are me, but, unexpected. I'll dig in.

[vcsjones]

This is also a breaking change; but it makes DSACryptoServiceProvider consistent across all platforms.

[bartonjs]

Looks reasonable to me, is there still some discovery going on (draft mode)?

[vcsjones]

@bartonjs nothing else that I'm aware of, as long as you're okay with the breaking changes.

[bartonjs]

Yeah, DSACryptoServiceProvider is just around as a compatibility type. It having more functionality than the type it's providing compatibility for seems weird; and I doubt it'll really affect anyone... though we should still doc it as a breaking change.

[vcsjones]

@bartonjs sorry, this isn't quite ready yet -- some of the failures are a result of this change and I need to find time to work through them.

Notably, Windows 7, despite lacking FIPS 186-3, appears to accept digests of any size, so I am trying to figure out what it is actually doing.

[vcsjones]

@bartonjs

The behavior of DSA.CreateSignature on Windows and Linux seems problematic. Consider the following code:

usingvardsa=DSA.Create();varfirst=newbyte[1]{1};varsecond=newbyte[20];second[^1]=1;varsig=dsa.CreateSignature(first);Console.WriteLine(dsa.VerifySignature(second,sig));

This will print true even though there were different inputs. It appears that it zero-extending inputs that are too short.

Perhaps more concerning, it truncates the data, so inputs that are different past the expected digest size are ignored. Consider:

usingvardsa=DSA.Create();dsa.KeySize=2048;varfirst=newbyte[33];first[^1]=0xFF;varsecond=newbyte[33];second[^1]=0x01;varsig=dsa.CreateSignature(first);Console.WriteLine(dsa.VerifySignature(second,sig));

Developers might be using CreateSignature expecting to account for the whole input, not aware that it is truncated.

I'm not exactly sure what the logic for CreateSignature should be since it doesn't accept the expected hash algorithm. At a glance, it seems it should be:

if (KeySize <= 1024 && rgbHash != 20) throw;
if (KeySize > 1024 && rgbHash != 32) throw;

[bartonjs]

I'm not exactly sure what the logic for CreateSignature should be

FIPS 186-3 section 4.6. The input parameter represents Hash(M):

• z = the leftmost min(N, outlen) bits of Hash(M).

Truncation and zero-extension are built-in. (Truncation is important for DSA-1024 using SHA-512)

Developers might be using CreateSignature expecting to account for the whole input, not aware that it is truncated.

Yep. But, there's nothing we can really do about it. Except on the types that only support FIPS 186-1/-2, which can restrict it to 20 bytes. (FIPS 186-2 section 5, specifically says SHA-1)).

[vcsjones]

Hmm, "yikes" that this is exposed on the public API, but alright.

[vcsjones]

@bartonjs I'm going to close this for now while I ponder an alternative change that might be better. Sorry for taking your time with the review of this one.

[vcsjones]

Fixes#28634

If you use DSA.CreateSignature on macOS with a digest that is bigger than 160 bits, you get a fairly obscure error that is hard to diagnose. Something like this:

Interop+AppleCrypto+AppleCFErrorCryptographicException: The operation couldn’t be completed. (Internal CSSM error error -2147415807 - Internal error #80010901
at SignTransform_block_invoke /AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/Security/Security-59306.101.1/OSX/libsecurity_transform/lib/SecSignVerifyTransform.c:324)

This is because Apple only supports FIPS-186-2, or SHA1 digests. Using a SHA2 family digest will result in this error.

I am marking this as a draft pending feedback on this is also a breaking change with digests less than 160 bits. It seems that right now, CreateSignature works on any number of bytes <= 20. I'm not entirely sure what the underlying platform is actually doing with a 19-byte hash, but it doesn't throw an error.

However, it seems the intention of the code was that it is always 20 bytes. Furthermore, SignData, which takes raw data and hashes it for you, does not accept MD5.

[ghost]

Tagging subscribers to this area: @bartonjs, @vcsjones, @krwq
Notify danmosemsft if you want to be subscribed.

[vcsjones]

Huh. Those failures are me, but, unexpected. I'll dig in.

[vcsjones]

This is also a breaking change; but it makes DSACryptoServiceProvider consistent across all platforms.

[bartonjs]

Looks reasonable to me, is there still some discovery going on (draft mode)?

[vcsjones]

@bartonjs nothing else that I'm aware of, as long as you're okay with the breaking changes.

[bartonjs]

Yeah, DSACryptoServiceProvider is just around as a compatibility type. It having more functionality than the type it's providing compatibility for seems weird; and I doubt it'll really affect anyone... though we should still doc it as a breaking change.

[vcsjones]

@bartonjs sorry, this isn't quite ready yet -- some of the failures are a result of this change and I need to find time to work through them.

Notably, Windows 7, despite lacking FIPS 186-3, appears to accept digests of any size, so I am trying to figure out what it is actually doing.

[vcsjones]

@bartonjs

The behavior of DSA.CreateSignature on Windows and Linux seems problematic. Consider the following code:

usingvardsa=DSA.Create();varfirst=newbyte[1]{1};varsecond=newbyte[20];second[^1]=1;varsig=dsa.CreateSignature(first);Console.WriteLine(dsa.VerifySignature(second,sig));

This will print true even though there were different inputs. It appears that it zero-extending inputs that are too short.

Perhaps more concerning, it truncates the data, so inputs that are different past the expected digest size are ignored. Consider:

usingvardsa=DSA.Create();dsa.KeySize=2048;varfirst=newbyte[33];first[^1]=0xFF;varsecond=newbyte[33];second[^1]=0x01;varsig=dsa.CreateSignature(first);Console.WriteLine(dsa.VerifySignature(second,sig));

Developers might be using CreateSignature expecting to account for the whole input, not aware that it is truncated.

I'm not exactly sure what the logic for CreateSignature should be since it doesn't accept the expected hash algorithm. At a glance, it seems it should be:

if (KeySize <= 1024 && rgbHash != 20) throw;
if (KeySize > 1024 && rgbHash != 32) throw;

[bartonjs]

I'm not exactly sure what the logic for CreateSignature should be

FIPS 186-3 section 4.6. The input parameter represents Hash(M):

• z = the leftmost min(N, outlen) bits of Hash(M).

Truncation and zero-extension are built-in. (Truncation is important for DSA-1024 using SHA-512)

Developers might be using CreateSignature expecting to account for the whole input, not aware that it is truncated.

Yep. But, there's nothing we can really do about it. Except on the types that only support FIPS 186-1/-2, which can restrict it to 20 bytes. (FIPS 186-2 section 5, specifically says SHA-1)).

[vcsjones]

Hmm, "yikes" that this is exposed on the public API, but alright.

[vcsjones]

@bartonjs I'm going to close this for now while I ponder an alternative change that might be better. Sorry for taking your time with the review of this one.

[vcsjones]

Fixes#28634

If you use DSA.CreateSignature on macOS with a digest that is bigger than 160 bits, you get a fairly obscure error that is hard to diagnose. Something like this:

Interop+AppleCrypto+AppleCFErrorCryptographicException: The operation couldn’t be completed. (Internal CSSM error error -2147415807 - Internal error #80010901
at SignTransform_block_invoke /AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/Security/Security-59306.101.1/OSX/libsecurity_transform/lib/SecSignVerifyTransform.c:324)

This is because Apple only supports FIPS-186-2, or SHA1 digests. Using a SHA2 family digest will result in this error.

I am marking this as a draft pending feedback on this is also a breaking change with digests less than 160 bits. It seems that right now, CreateSignature works on any number of bytes <= 20. I'm not entirely sure what the underlying platform is actually doing with a 19-byte hash, but it doesn't throw an error.

However, it seems the intention of the code was that it is always 20 bytes. Furthermore, SignData, which takes raw data and hashes it for you, does not accept MD5.

[ghost]

Tagging subscribers to this area: @bartonjs, @vcsjones, @krwq
Notify danmosemsft if you want to be subscribed.

[vcsjones]

Huh. Those failures are me, but, unexpected. I'll dig in.

[vcsjones]

This is also a breaking change; but it makes DSACryptoServiceProvider consistent across all platforms.

[bartonjs]

Looks reasonable to me, is there still some discovery going on (draft mode)?

[vcsjones]

@bartonjs nothing else that I'm aware of, as long as you're okay with the breaking changes.

[bartonjs]

Yeah, DSACryptoServiceProvider is just around as a compatibility type. It having more functionality than the type it's providing compatibility for seems weird; and I doubt it'll really affect anyone... though we should still doc it as a breaking change.

[vcsjones]

@bartonjs sorry, this isn't quite ready yet -- some of the failures are a result of this change and I need to find time to work through them.

Notably, Windows 7, despite lacking FIPS 186-3, appears to accept digests of any size, so I am trying to figure out what it is actually doing.

[vcsjones]

@bartonjs

The behavior of DSA.CreateSignature on Windows and Linux seems problematic. Consider the following code:

usingvardsa=DSA.Create();varfirst=newbyte[1]{1};varsecond=newbyte[20];second[^1]=1;varsig=dsa.CreateSignature(first);Console.WriteLine(dsa.VerifySignature(second,sig));

This will print true even though there were different inputs. It appears that it zero-extending inputs that are too short.

Perhaps more concerning, it truncates the data, so inputs that are different past the expected digest size are ignored. Consider:

usingvardsa=DSA.Create();dsa.KeySize=2048;varfirst=newbyte[33];first[^1]=0xFF;varsecond=newbyte[33];second[^1]=0x01;varsig=dsa.CreateSignature(first);Console.WriteLine(dsa.VerifySignature(second,sig));

Developers might be using CreateSignature expecting to account for the whole input, not aware that it is truncated.

I'm not exactly sure what the logic for CreateSignature should be since it doesn't accept the expected hash algorithm. At a glance, it seems it should be:

if (KeySize <= 1024 && rgbHash != 20) throw;
if (KeySize > 1024 && rgbHash != 32) throw;

[bartonjs]

I'm not exactly sure what the logic for CreateSignature should be

FIPS 186-3 section 4.6. The input parameter represents Hash(M):

• z = the leftmost min(N, outlen) bits of Hash(M).

Truncation and zero-extension are built-in. (Truncation is important for DSA-1024 using SHA-512)

Developers might be using CreateSignature expecting to account for the whole input, not aware that it is truncated.

Yep. But, there's nothing we can really do about it. Except on the types that only support FIPS 186-1/-2, which can restrict it to 20 bytes. (FIPS 186-2 section 5, specifically says SHA-1)).

[vcsjones]

Hmm, "yikes" that this is exposed on the public API, but alright.

[vcsjones]

@bartonjs I'm going to close this for now while I ponder an alternative change that might be better. Sorry for taking your time with the review of this one.