Remove some Windows oriented crypto from Standard?

[danmoseley]

The following API are not implemented in netcoreapp for Unix targets. This appears to be the case for Xamarin also. If that's so we should remove from Standard if dependencies allow as we can't "make the Standard promise". If that's not so (Xamarin has them) we should invesitgate whether we should impelment them for Unix.

System.Security.Cryptography.Csp
System.Security.Cryptography.AesCryptoServiceProvider
System.Security.Cryptography.CspKeyContainerInfo
System.Security.Cryptography.CspParameters
System.Security.Cryptography.CspProviderFlags
System.Security.Cryptography.DESCryptoServiceProvider
System.Security.Cryptography.DSACryptoServiceProvider
System.Security.Cryptography.ICspAsymmetricAlgorithm
System.Security.Cryptography.KeyNumber
System.Security.Cryptography.MD5CryptoServiceProvider
System.Security.Cryptography.PasswordDeriveBytes
System.Security.Cryptography.RC2CryptoServiceProvider
System.Security.Cryptography.RNGCryptoServiceProvider
System.Security.Cryptography.RSACryptoServiceProvider
System.Security.Cryptography.SHA1CryptoServiceProvider
System.Security.Cryptography.TripleDESCryptoServiceProvider

System.Security.Cryptography.Cng
Microsoft.Win32.SafeHandles.SafeNCryptHandle
Microsoft.Win32.SafeHandles.SafeNCryptKeyHandle
Microsoft.Win32.SafeHandles.SafeNCryptProviderHandle
Microsoft.Win32.SafeHandles.SafeNCryptSecretHandle
System.Security.Cryptography.AesCng
System.Security.Cryptography.CngAlgorithm
System.Security.Cryptography.CngAlgorithmGroup
System.Security.Cryptography.CngExportPolicies
System.Security.Cryptography.CngKey
System.Security.Cryptography.CngKeyBlobFormat
System.Security.Cryptography.CngKeyCreationOptions
System.Security.Cryptography.CngKeyCreationParameters
System.Security.Cryptography.CngKeyHandleOpenOptions
System.Security.Cryptography.CngKeyOpenOptions
System.Security.Cryptography.CngKeyUsages
System.Security.Cryptography.CngProperty
System.Security.Cryptography.CngPropertyCollection
System.Security.Cryptography.CngPropertyOptions
System.Security.Cryptography.CngProvider
System.Security.Cryptography.CngUIPolicy
System.Security.Cryptography.CngUIProtectionLevels
System.Security.Cryptography.ECDsaCng
System.Security.Cryptography.RSACng
System.Security.Cryptography.TripleDESCng

/cc @bartonjs

[weshaggard]

I'm interested in opinions from @terrajobst @marek-safar @akoeplinger

Before we decide on this I want to do some analysis about usage and which platforms currently have these.

[marek-safar]

We have API surface for most of them (some of them are very easy to support) but not all API is working.

[PaulHigin]

@danmosemsft We (PowerShell) need the System.Security.Cryptography.RSACryptoServiceProvider for remoting key exchange, but we also need support for ephemeral keys (support for CRYPT_VERIFYCONTEXT) that doesn't appear to be supported in .NET. Will support for ephemeral keys be added?

[bartonjs]

@PaulHigin RSACryptoServiceProvider is the least useful implementation of RSA we have in .NET, so you should really try to wean off of it. And I don't know what you mean by not supporting ephemeral keys, but if it's something not working that'd be an issue to file in dotnet/corefx.

[weshaggard]

We should also look at https://github.com/dotnet/standard/issues/221 as part of this. In general we need to try and rationalize these Crypto APIs. We should do a diff and review to see if we have an set that we can at least rationalize in our heads.

[PaulHigin]

@bartonjs What do you suggest? PowerShell remoting currently uses RSACryptoServiceProvider (via Windows API PInvoke) and requires use of ephemeral keys. It is my understanding that .NET does not support this. Please correct me if I am wrong (and point me to documentation).

[terrajobst]

Looking at the usage, it looks like we want to do the following:

1. *CryptoServiceProvider types. Those are around since .NET Framework 1.0, and are widely used. They were also implemented by Mono, because it was the only way to support crypto until we added CNG.
2. *Cng* types. CNG is the current Windows crypto API stack and was created in Vista/Win7 time frame. The types were added in .NET Framework 3.5. The usage is generally fairly low usage (max 1%). It's a Windows only technology and cannot be reasonably implemented everywhere.

It looks like we want to do the following:

• Expose (1) in .NET Standard and implement them as wrappers over the OS specific crypto stack.
• Remove (2) from .NET Standard and expose these APIs in a package built for .NET Standard, similar to Registry.

Follow-ups:

• @weshaggard will create a full diff of crypto between .NET Framework 4.6.1 and .NET Standard 2.0.

[danmoseley]

@karelz can someone on your team sign up to cost (1)?

[bartonjs]

@danmosemsft It's already tracked via https://github.com/dotnet/corefx/issues/16585.

[weshaggard]

@weshaggard will create a full diff of crypto between .NET Framework 4.6.1 and .NET Standard 2.0.

The APIs that are in .NET 4.6.1 that aren't part of the standard now (including my CNG removals) can be seen https://github.com/dotnet/standard/pull/272/files#diff-e31cb612517bf61cc7841e90885fca62.

I also did a diff of the API's that are still part of the standard against 4.6.1 and looked for member differences and the only ones that are missing things are removed because of CAS. So there isn't really anything more to expose there.

[weshaggard]

I believe the work targeting the standard repo is now complete so closing.