Which Cryptographic Operations are Available?

One of the more common problems to creep up when people start using the various cryptographic algorithms in the System.Security.Cryptography namespace is that their app, which works fine on their WinXP dev box suddenly starts throwing CryptographicExceptions when run on down level platforms.  The reasoning behind this is that the various algorithms which have class names ending in CryptoServiceProvider actually are thin wrappers around the native Windows Crypto API.  CAPI gets its algorithms from a Cryptographic Service Provider.

On default Windows 2000 installs, there is only the Microsoft Base Cryptographic Service Provider, which only provides RC2, RC4 and DES encryption.  To get more algorithms such as TripleDES, or RSA that uses larger than 512 bit keys, you need the Microsoft Enhanced Cryptographic Service Provider.  The enhanced CSP installs with upgrades to IE, so usually upgrading to the latest IE (or latest Windows Service Pack) will solve the problem.

To help figure out which algorithms are installed on your computer, Mitch Gallant has written a small utility that lists your CSPs and the algorithms they support.  You can find it here: http://www.jensign.com/JavaScience/ListAlgs/

Comments (7)

  1. This is a good description of the problem (but it’s missing the OAEP padding which is only available to XP/2003). However you didn’t supply a solution to the problem. Mitch’s utility is great but it’s hardly a solution that would help someone to deploy an application to multiple computers (inside or outside an organization). Upgrading (either IE, a service pack or a newer OS) isn’t always a choice available to enterprise customers either.

    So let me give my own suggestion*: using a 100% managed implementation of the algorithms you require. This way you’ll always be sure that the algorithms are available as you can ship the assembly containing the complete implementation. No I’m not avocating that everyone should do it’s own crypto (I’ll get nightmares just because of the idea) because that would be extremely bad, but I would suggest* people to look at what’s already available on the Internet because this solution exists today.

    Anyway this may also be the only way to go multiple platform (e.g. the Compact Framework has no cryptographic support – unless you P/Invoke into it’s own CryptoAPI and make your own CryptoStream and support classes, which sadly would be kind-of writing your own crypto).

    [* disclaimer: I’m a (potentialy biased) Mono developer – http://www.go-mono.com/]

  2. Shawn says:

    Thanks for pointing out OAEP, I’d forgotten to mention that in my post. I pointed out Mitch’s utility only to help debugging these problems, and to increase awareness of different CSPs on different versions of Windows.

    However, as you point out, the only way to guarantee that there’s not going to be a problem is to either insist on minimum platform requirements, or use pure managed algorithms. However, writing crypto algorithms is hard and most people really should use a library. As you point out Mono provides some pure-managed implementations (though I don’t know exactly which algorithms are avaliable, maybe you could provide a list here?) Also, how easy would it be to get the Mono algorithms to compile using the Microsoft toolset and distribute them with an application? Would I need just a .cs file or two, or are there a slew of dependencies to worry about?

    Another option would be to use AES encryption, provided with Microsoft’s implementation in the RijndaelManaged class. This will provide for excellent symmetric encryption, however it does not provide a solution for asymmetric encryption. For hashing, SHA1Managed or SHA512Managed both provide built in managed solutions.

  3. > maybe you could provide a list here?

    Well, thanks for your offer :-). Actually all Fx cryptographic algorithms are supported, including the new one in Fx1.2 – and them some…

    The mscorlib.dll assembly contains the following algorithms.

    – DSACryptoServiceProvider *

    – RSACryptoServiceProvider *, **

    – DESCryptoServiceProvider *

    – RC2CryptoServiceProvider *

    – RijndaelManaged

    – RIPEMD160Managed ***

    – SHA1CryptoServiceProvider *, ****

    – SHA1Managed ****

    – SHA256Managed

    – SHA284Managed

    – SHA512Managed

    – TripleDESCryptoServiceProvider *

    and all HMAC (SHA1, MD5, RIPEMD160, SHA256, SHA384, SHA512)

    * For compatibility we had to keep the <algo>CryptoServiceProvider names but the implementations are fully managed.

    ** Support both PKCS1 and OAEP padding.

    *** To support upcoming Fx 1.2

    **** They are actually the same implementation.

    Mono.Security.dll assembly also have some additional algorithms*

    – RSAManaged

    – DHManaged

    – ARC4Managed **

    – MD2Managed ***

    – MD4Managed ***

    which were required for other "internal" pieces like NTLM authentication and SSL/TLS (both available as managed implementation inside the same assembly).

    * Note the absence of DSAManaged from this assembly! Sadly the DSA abstract class has an internal constructor making it impossible to inherit from it outside mscorlib. I hope this get corrected in Fx 1.2.

    ** Compatible with RSA RC4 stream cipher.

    *** MD2Managed and MDManaged are present but we STRONGLY discourage their use in new applications. Their presence was required to support older X.509 certificates (signed using a MD2 hash) and to support NTLM authentication (which use MD4).

    > Also, how easy would it be to get the Mono algorithms to compile using the Microsoft toolset and distribute them with an application? Would I need just a .cs file or two, or are there a slew of dependencies to worry about?

    Using Mono.Security.dll on Windows should be very easy (i.e. it shouldn’t require any change or I missed my target ;-).

    Other algorithms (corlib) may have dependencies on BigInteger (DSA, RSA) and other internal classes from Mono.* namespaces. However they do not depend on some Mono’s internal (with the notable exception of the RNGCryptoServiceProvider class) so it’s only a matter to include the right files. Some people ported the corlib’s source for the Compact Framework without too much problems (few changes were required because many overloaded methods are missing in CF).

    The licensing is also very friendly as Mono class library use the MIT X.11 license (http://www.opensource.org/licenses/mit-license.php). Finally anyone can follow the current status of Mono’s cryptography by bookmarking this page: http://www.go-mono.com/crypto.html

  4. Shawn says:

    Good information. I think I’ll post this back onto the main thread so that more people can see it. In terms of the DSA constructor, we’re aware of that problem, and it should be fixed for Whidbey (which is now v2.0, not v1.2)

  5. Shelly says:

    Your Articles and comments helped me finish my Paper Today , Many thanks !