crypto api's about standard HOT 4 CLOSED

@bartonjs could you please list the problematic APIs in this issue?

from standard.

Things we were asked to omit if possible:

• T:System.Security.Cryptography.HMACRIPEMD160
• T:System.Security.Cryptography.RIPEMD160
• T:System.Security.Cryptography.MACTripleDES

Things we were asked to be Browsable(Never) though usage data says we needed to support:

• T:System.Security.Cryptography.DES
• T:System.Security.Cryptography.RC2
• T:System.Security.Cryptography.Rijndael
  • This can only work as AES (limit BlockSize to 128 bit).
• T:System.Security.Cryptography.PasswordDeriveBytes

Things we were asked to have their usage throw PNSE, and be Browsable(Never):

• F:System.Security.Cryptography.CipherMode.CFB
• F:System.Security.Cryptography.CipherMode.OFB

Bad factories that showed 0 usage that I'd like to keep out if possible:

• M:System.Security.Cryptography.Aes.Create(System.String)
• M:System.Security.Cryptography.AsymmetricAlgorithm.Create(System.String)
• M:System.Security.Cryptography.HMAC.Create(System.String)
• M:System.Security.Cryptography.MD5.Create(System.String)
• M:System.Security.Cryptography.RSA.Create(System.String)
• M:System.Security.Cryptography.SHA1.Create(System.String)
• M:System.Security.Cryptography.SHA256.Create(System.String)
• M:System.Security.Cryptography.SHA384.Create(System.String)
• M:System.Security.Cryptography.SHA512.Create(System.String)
• M:System.Security.Cryptography.SymmetricAlgorithm.Create(System.String)
• M:System.Security.Cryptography.TripleDES.Create(System.String)
• M:System.Security.Cryptography.KeyedHashAlgorithm.Create(System.String)
  • This one showed small amounts of usage, but since the caller is providing their algorithm name as the input they should just switch to using the right ctor and avoid the CryptoConfig (hijackable) dependency.

Overly general factories which never should have existed because they force casting:

• M:System.Security.Cryptography.AsymmetricAlgorithm.Create
• M:System.Security.Cryptography.HMAC.Create
• M:System.Security.Cryptography.KeyedHashAlgorithm.Create
• M:System.Security.Cryptography.SymmetricAlgorithm.Create
  • This showed epsilon usage

No-usage types and members which don't make sense:

• T:System.Security.Cryptography.CryptoAPITransform
  • There's nothing guaranteeing that any of the *CSP types return an ICryptoTransform deriving from this type, and it's not publically constructable, so why have it?
• P:System.Security.Cryptography.CryptoAPITransform.KeyHandle
  • (If the type has to exist, this member makes no sense x-plat)
• P:System.Security.Cryptography.HMACSHA384.ProduceLegacyHmacValues
  • This enables a .NET 2.0 (pre-SP1) bug compatibility mode. Since we no longer have a managed implementation of HMAC we can't make this work in core.
• P:System.Security.Cryptography.HMACSHA512.ProduceLegacyHmacValues
  • Ditto
• T:System.Security.Cryptography.RijndaelManagedTransform
  • Same as CryptoAPITransform
• M:System.Security.Cryptography.X509Certificates.X509Chain.Create
  • We don't have pluggable chain builders. Nothing internal or external uses this, so it doesn't make sense to support. (Though it is easily implemented)
• P:System.Security.Cryptography.AsymmetricAlgorithm.KeyExchangeAlgorithm
  • Very inconsistent answers across the hierarchy, can't really be used for anything. Note that RSA is actually the only Key Exchange algorithm we have.
• P:System.Security.Cryptography.AsymmetricAlgorithm.SignatureAlgorithm
  • Very inconsistent answers across the hierarchy, can't really be used for anything. Note that ECDiffieHellman is neither a signature algorithm nor a key exchange algorithm.

Low-usage members that don't make sense:

• M:System.Security.Cryptography.RSA.DecryptValue(System.Byte[])
  • There has never been an inbox type that didn't throw here.
  • Since we've never had an implementation it is unclear if this is "unpadded Decrypt", "raw private key RSA", or "decrypt with whatever padding you like".
• M:System.Security.Cryptography.RSA.EncryptValue(System.Byte[])
  • Ditto

No-usage members that I just don't like:

• P:System.Security.Cryptography.CspParameters.KeyPassword
  • SecureString
• M:System.Security.Cryptography.X509Certificates.X509Certificate2.Verify
  • Like Dictionary.ContainsKey this is almost always used wrong. If this returns true, life is good. If it returns false then many applications repeat the work it does to turn the boolean into the X509ChainElementStatus failure code to decide if it's an acceptable reason.
  • It also secretly (sometimes) uses the Internet.
• M:System.Security.Cryptography.X509Certificates.X509Store.AddRange(System.Security.Cryptography.X509Certificates.X509Certificate2Collection)
  • The behavior on an exception is dangerous, the application should decide how to handle it.
    • It can end up deleting certs from a store which it didn't add.

Low-usage members I just don't like:

• M:System.Security.Cryptography.X509Certificates.X509Store.RemoveRange(System.Security.Cryptography.X509Certificates.X509Certificate2Collection)
  • The behavior on an exception is dangerous, the application should decide how to handle it.
    • It can end up adding certs to a store which it didn't remove.
• The ctors of X509Certificate and X509Certificate2 which take SecureString.
  • They just create plumbing problems
• M:System.Security.Cryptography.X509Certificates.X509Certificate.Export(System.Security.Cryptography.X509Certificates.X509ContentType,System.Security.SecureString)
  • If we bring back the SecureString ctors, then this should come back, too.
• M:System.Security.Cryptography.X509Certificates.X509Chain.#ctor(System.Boolean)
  • True means "don't honor user certificates". But on Unix we don't have the ability to programmatically add to the machine trust list. Do we ignore it on Unix, creating problems down the line, or throw on true, or make up some middle ground.
    • Do we ignore just user roots, or also user intermediates?
    • If we didn't read user intermediates we shouldn't write them.
    • Since we can't write to the machine context that means any chain built under (true) has to download intermediates from the Internet every time.

Big buck, little bang:

• P:System.Security.Cryptography.CspParameters.CryptoKeySecurity
  • No Xamarin usage because it's a Windows feature.
  • Catalog usage says 0.1% of scanned desktop apps
  • This is a DACL feature for CAPI, when we're moving everything to CNG.
• M:System.Security.Cryptography.CspParameters.#ctor(System.Int32,System.String,System.String,System.Security.AccessControl.CryptoKeySecurity,System.IntPtr)
  • (Doesn't make sense without the CryptoKeySecurity feature)
• M:System.Security.Cryptography.CspParameters.#ctor(System.Int32,System.String,System.String,System.Security.AccessControl.CryptoKeySecurity,System.Security.SecureString)
  • Ditto
• P:System.Security.Cryptography.CspKeyContainerInfo.CryptoKeySecurity
  • This is the "what is already there" half of the DACL feature.
• All overloads of X509Certificate.Import
  • The .NET Core implementation caches values loaded out of the native system, this invalidates that caching.
  • It also fails user expectations that a certificate is read-only-or-disposed, because this allows an existing reference to suddenly be talking about a different certificate.
  • Most of the overloads have 0 usage, the biggest one is 0.2%

Low usage, Desktop-only:

• M:System.Security.Cryptography.PasswordDeriveBytes.CryptDeriveKey(System.String,System.String,System.Int32,System.Byte[])
  • The formula is secret, we can't return the same values on non-Windows
  • It's also not on the UWP allow list.
  • 0.1% usage per the catalog
  • No x-plat usage because it throws there.

Windows-only, no/low usage:

• M:System.Security.Cryptography.X509Certificates.X509Chain.#ctor(System.IntPtr)
• P:System.Security.Cryptography.X509Certificates.X509Chain.ChainContext

Windows-only, can't really work on x-plat, but has usage:

• M:System.Security.Cryptography.X509Certificates.X509Store.#ctor(System.IntPtr)
  • This is barely used, but it's the other side of StoreHandle, which has ~15x the usage of this.
• P:System.Security.Cryptography.X509Certificates.X509Store.StoreHandle

Things I probably can't justify cutting, but should be cut:

• M:System.Security.Cryptography.AsymmetricAlgorithm.FromXmlString(System.String)
  • This requires taking a dependency on an XML processor.
  • I don't expect us to add a JSON form.
• M:System.Security.Cryptography.AsymmetricAlgorithm.ToXmlString(System.Boolean)
  • This isn't hard, though not all of our answers conform to standards (we sort of make it up for ECDiffieHellman); but this is the peer to FromXmlString. (Writing XML for constrained data is easy; reading XML is hard)

Super-complicated:

• P:System.Security.Cryptography.X509Certificates.X509Certificate2.PrivateKey
  • Windows Desktop:
    • Returns a RSACryptoServiceProvider, DSACryptoServiceProvider, or throws.
    • If the key is stored in CNG, this fails.
  • Mono:
    • Returns an "RSACryptoServiceProvider" or "DSACryptoServiceProvider", which in reality are managed implementations of the algorithms
  • Windows UWP:
    • This is Windows, so should RSACryptoServiceProvider be CAPI? (Disallowed) or a wrapper over CNG (somewhat dishonest, but close to what we have to do for Unix).
    • If we wrap CNG, do we impose CAPI limits, or make code that works on UWP and/or Unix occasionally fail on Desktop?
  • Meta:
    • RSACryptoServiceProvider has frequently-battled problems with SHA-2 signatures, so a good number of these callers are then going to cast the return value, read the key info parameters (which will have to throw on non-Desktop) and then coerce it into something that works for SHA-2. So adding this property for "compat" creates a runtime problem on practically the next line.
• P:System.Security.Cryptography.X509Certificates.PublicKey.Key
  • Very similar to the X509Certificate2.PrivateKey property.
  • The complication for this one, aside from everyone knowing to cast to the legacy CSP types, is that CAPI can't load an RSA public key whose Exponent value is > uint.MaxValue. While this is very, very rare in the wild this property will fail for those keys on Desktop but could work (unless explicitly blocked) by wrapper types for UWP and Unix. (And CAPI probably can't load a DSA key whose keysize is > 1024, but I haven't personally encountered that error)

from standard.

@bartonjs thanks for the detailed information. However as we chatted offline our intent is to avoid subsetting types if we can help it to maximize compatibility. So for these crypto APIs what I've done is make netstandard compatible with net461 and xamarin. I also did filter out the first group of classes you mentioned as we don't have any native implementation for those. Commit 6d04955 does that.

What we currently have in netstandard is what we currently expect to support for 2.0, if you run into any troubles implementing these on .NET Core please let me know and we can discuss options.

from standard.

.net Standard 2.03 fails to see certificates in X509Store for StoreLocation.CurrentUser. Running in UWP on WIndows 10 version 1803. running as Administrator does not change result. What permissions does cross platform application need to execute to support seeing personal certificate store certificates?

code sample to illustrate:
int certCountInStore = 0;
int certCountInMyStore = 0;
//=======Sees machine certs
X509Store machStore = new X509Store(StoreName.TrustedPublisher, StoreLocation.LocalMachine);
machStore.Open(OpenFlags.ReadOnly);
X509Certificate2Collection machcollection = (X509Certificate2Collection)machStore.Certificates;
certCountInStore = machcollection.Count;
machStore.Close();
//==========does not see Current User Certs
X509Store myStore = new X509Store(StoreName.My,StoreLocation.CurrentUser);
myStore.Open(OpenFlags.ReadOnly);
X509Certificate2Collection mycollection = (X509Certificate2Collection)myStore.Certificates;
certCountInMyStore = mycollection.Count;
myStore.Close();

from standard.