[ECDsa] Falls back to use BouncyCastle if BCL (Mono) doesn't support

[scott-xu]

Fixes #1406

[Rob-Hague]

Can we use this for .NET Framework (4.6.2) as well? So that we have 2 implementations instead of 3.

Instead of the isMono check, can we wrap the ECDsa.Create(parameter) call in a try-catch and then fall back to BouncyCastle? That should capture all the cases where it doesn't work, and still allow using the BCL if later versions of mono support it.

[scott-xu]

@Rob-Hague @WojciechNagorski Could you please help re-trigger the CI? Or would you mind granting me permission for Appveyor?

[Rob-Hague]

I suppose what I meant was, can we delete the custom CNG implementation so we just have (1) The normal BCL implementation with ECDsa; and if that is not supported then (2) The BouncyCastle implementation

Currently, this does not fix #1406 because #1406 does not use the .NET Framework target (probably .NET Standard instead). You can see that because the failure is on ECDsa.Create which is only called under #if !NETFRAMEWORK

[Rob-Hague]

I suppose what I meant was, can we delete the custom CNG implementation so we just have (1) The normal BCL implementation with ECDsa; and if that is not supported then (2) The BouncyCastle implementation

Since that would cause all .NET Framework applications to use BouncyCastle, that is probably not exactly what we want.

I'm finding it difficult to read and understand what implementation is used when. I think we want:

1. If ECDsa.Create(ECParameters) is supported, use that
2. Otherwise, if running on Windows, use CNG
3. Otherwise, use BouncyCastle

But that does complicate the testing situation...

[scott-xu]

I suppose what I meant was, can we delete the custom CNG implementation so we just have (1) The normal BCL implementation with ECDsa; and if that is not supported then (2) The BouncyCastle implementation

Since that would cause all .NET Framework applications to use BouncyCastle, that is probably not exactly what we want.

I'm finding it difficult to read and understand what implementation is used when. I think we want:

1. If ECDsa.Create(ECParameters) is supported, use that
2. Otherwise, if running on Windows, use CNG
3. Otherwise, use BouncyCastle

But that does complicate the testing situation...

Not sure if anybody uses Mono at Windows... I propose below logic:

1. If NET, use ECDsa.Create(ECParameters) without fallback
2. Otherwise if NETStandard or NET47 above, use ECDsa.Create(ECParameters) and falls back to BouncyCastle
3. Otherwise if NET462, use CNG and falls back to BouncyCastle

[Rob-Hague]

I think we are proposing the same thing, so if it's easy to follow in the code, then sounds good

[scott-xu]

We don't have NET47 as target framework. (Should we? ECDsa.Create(ECParameters) supports .NET Framework 4.7 onwards, see https://learn.microsoft.com/en-us/dotnet/api/system.security.cryptography.ecdsa.create?view=net-8.0#system-security-cryptography-ecdsa-create(system-security-cryptography-ecparameters))

Here's current simplified logic:

• !NET -> Use BouncyCastle as a fallback
• FRAMEWORK -> Use CNG

[scott-xu]

We don't have NET47 as target framework. (Should we? ECDsa.Create(ECParameters) supports .NET Framework 4.7 onwards, see https://learn.microsoft.com/en-us/dotnet/api/system.security.cryptography.ecdsa.create?view=net-8.0#system-security-cryptography-ecdsa-create(system-security-cryptography-ecparameters))

Here's current simplified logic:

• !NET -> Use BouncyCastle as a fallback
• FRAMEWORK -> Use CNG

Update:

• !NET -> Use BouncyCastle as a fallback
• NET462 -> Use CngKey

[Rob-Hague]

Yeah probably makes sense

Is there a way to use the "Impl" pattern here that we have used in other places?

[scott-xu]

Is there a way to use the "Impl" pattern here that we have used in other places?

I tried, but it's a little bit different with others. Anyway it's good to separate into different files.

[Rob-Hague]

I iterated on it a bit and tested with a few different configurations. Will just wait for confirmation from mono...