Frequently Asked Questions
1. What cryptography resources are available in the .Net Framework?
The .Net Framework Base Class Library’s System.Security.Cryptography namespace contains support for the most common symmetric (ie.DES, 3DES, RC2, Rijndael/AES), asymmetric (ie. RSA, DSA) and hash algorithms (ie. MD5, SHA1, SHA256, SHA384, SHA512). We also ship minimal support for public certificates in the System.Security.Cryptography.X509 namespace. Furthermore we ship a full implementation of the W3C standard for digitally signing XML. The classes supporting this standard can be found in the System.Security.Cryptography.XML namespace.
2. Can I use the cryptography resources from Visual Basic 7?
Yes. Like any other resources in the .Net Framework Base Class Library, the cryptography classes can be accessed and used from Visual Basic 7 without special preparations or precautions.
3. Do you ship with support for strong encryption?
Yes, we support the use of “strong” key lengths in all our encryption algorithms. However, for encryption algorithms that are implemented on top of CryptoAPI you may need to install a High Encryption Pack to upgrade your version of Windows:
For Windows 2000 users, Service Pack 2 includes the High Encryption pack. If you do not have Service Pack 2 installed you need to either (a) install the Windows 2000 High Encryption Pack from http://www.microsoft.com/windows2000/downloads/recommended/encryption/ or upgrade to Service Pack 2.
For Windows NT 4.0 users, Service Packs are distributed in both “standard” and “high” encryption versions. If you do not have a high encryption service pack already installed you can download the high encryption version of Service Pack 6a from this location: http://www.microsoft.com/ntserver/nts/downloads/recommended/SP6/allSP6.asp
For Windows ME, Windows 98 and Windows 95 users, Internet Explorer 5.5 includes the High Encryption Pack. If you are running a version of Internet Explorer earlier than 5.5 you can obtain the corresponding High Encryption Pack for your version of Internet Explorer here:
http://www.microsoft.com/windows/ie/ie6/downloads/recommended/128bit/default.mspx
4. Are the cryptography algorithms in System.Security.Cryptography implemented in managed code.
Most of the algorithms found in System.Security.Cryptography are implemented as managed wrappers on top of Microsoft CryptoAPI implementations. For, instance the RSACryptoServiceProvider class is a managed wrapper around the unmanaged RSA implementation provided by CryptoAPI. However, we ship a number of crypto algorithm implementations (SHA256, SHA384, SHA512, RijndaelManaged) that are not currently available in CryptoAPI. These algorithms are all implemented directly in managed code. We also ship a managed SHA1 implementation (the SHA1Managed class).
5. Is the programming model exposed in System.Security.Cryptography different from Microsoft CryptoAPI?
Yes. Our model is stream-based (see the CryptoStream class, which derives from the System.IO.Stream class). Cryptographic transformations, except for uses of asymmetric algorithms, are always performed on a stream (such as a file stream or another CryptoStream). The CryptoStream class takes care of all necessary buffering.
Furthermore, the default constructors for all our crypto algorithms always populate the algorithm parameters with strong defaults, subject to the availability of strong cryptography on the platform, so that users will get a strong crypto algorithm by simply instantiating the respective class.
6. Do I need to explicitly set algorithm parameters to securely use the crypto algorithms provided in
System.Security.Cryptography?
No. As mentioned in question 6, the default constructors for all our cryptography algorithms will populate the algorithm parameters with strong defaults (for instance, by default we set strong key size and chaining modes). All our cryptography algorithm classes when simply instantiated will represent strong versions of that algorithm. We furthermore always generate a random key when symmetric algorithm classes are instantiated and a random key pair when asymmetric algorithm classes are instantiated.
7. How do I generate an asymmetric key pair?
You do not explicitly need to generate an asymmetric key pair. As mentioned in question 7, on instantiation of the RSA or DSA algorithm classes in System.Security.Cryptography we will automatically generate a random key pair for that instance. Therefore, for randomly generating an asymmetric key pair, simply create a new instance of the asymmetric algorithm you wish to generate keys.
8. How can I reuse an asymmetric key pair?
You can instantiate asymmetric algorithms with the key container name of an existing key pair in CAPI key storage. In order to do this simply fill in the key container name in the CspParameters object and supply this object to the constructor of the asymmetric algorithm. For an example of how to store and retrieve asymmetric key pairs in CAPI key storage please see the sample on this site (www.gotdotnet.com/team/clr/about_security.aspx.).
9. How do I generate a symmetric key?
As is the case for the generation of asymmetric keys (see question 7), creating a new instance of an asymmetric algorithm will automatically generate a random key and initialization vector (IV) for that instance.
10. Does the crypto library have a key management system different from CryptoAPI?
No, we internally use CryptoAPI key storage and you can reference keys stored in CryptoAPI key containers by using the CspParameters object. For a sample of how to store and retrieve your own asymmetric key pair in CryptoAPI key storage see the sample on www.gotdotnet.com/team/clr/about_security.aspx.
11. Can I change the default algorithm instantiated by the abstract classes?
Yes.We ship with a configuration system for cryptography that maps algorithm names to their default implementation in our object hierarchy. You can change these settings by introducing a cryptography configuration section in the machine.config file.
12. Are the crypto algorithms in System.Security.Cryptography FIPS-140 compliant?
Yes, but only for those algorithms that (a) are FIPS-certifiable, and (b) that we implement by calling CryptoAPI on a platform that has been FIPS 140-1 certified. In practice, what this means is that the following managed classes are FIPS 140-1 compliant because they call FIPS 140-1 compliant implementations:
RSACryptoServiceProvider
DSACryptoServiceProvider
SHA1CryptoServiceProvider
DESCryptoServiceProvider
TripleDESCryptoServiceProvider
You can view Microsoft's FIPS 104-1 certificates here: http://csrc.nist.gov/cryptval/140-1/1401vend.htm
For the other algorithms, no FIPS 140-1 certification program currently exists.
This article was originally written by barnseyboy |
Copyright Open Source Institute, 2006 