Extending the .NET Framework s Cryptography Classes and the Cryptographic Configuration System

for RuBoard

Extending the .NET Framework's Cryptography Classes and the Cryptographic Configuration System

You will recall from our discussion in the "The Cryptographic Object Model of the .NET Framework" section of Chapter 30 that the .NET Framework's cryptographic object model was designed to be easily extended by third parties. While the .NET Framework includes implementations of common symmetric and asymmetric algorithms, hash functions, and keyed hash functions, it may be necessary or desirable for various reasons to add new algorithms or algorithm implementations to the object hierarchy. For example, you might have a cryptographic hardware accelerator that you want to perform RSA decryptions from within the .NET Framework, or you might want to use a symmetric encryption algorithm not included "in the box." In this section, we briefly describe the process of extending the cryptographic object model and modifying the cryptographic configuration system to be aware of new algorithms and implementations.

Extensions to the cryptographic object model fall into one of two categories

  • Additions of new implementations of algorithms already defined in the .NET Framework

  • Additions of new algorithms

An example of the first category would be the addition of a new implementation of the AES/Rijndael algorithm, because the .NET Framework already includes the RijndaelManaged implementation of that algorithm. The addition of an implementation of the hash function RIPEMD-160 is an example of the second category of extension. In both cases, you will need to subclass portions of the cryptographic object model and potentially update the runtime configuration files. We'll walk through an example of the first category first, adding a new implementation, and then show the additional work required for the second category.

Adding a new implementation of a pre-existing algorithm to the .NET Framework is easy ”simply subclass the abstract class that represents the algorithm, supplying concrete implementations for abstract methods in the parent classes. For example, to extend the Framework with your own implementation of the Rijndael algorithm, you would subclass the abstract Rijndael class with your own implementation class ( MyRijndaelImplementation ). Your new class would have to provide implementations for the following abstract SymmetricAlgorithm methods ” CreateEncryptor(byte[], byte[]) CreateDecryptor(byte[], byte[]) , GenerateKey() , and GenerateIV() . After your new class is verified to properly implement Rijndael, you might want to make it the default implementation of Rijndael on the system. By modifying the cryptography portion of the runtime configuration files, you can reconfigure the abstract Rijndael class so that Rijndael.Create() returns an instance of your new MyRijndaelImplementation class instead of the RijndaelManaged class that ships as part of the .NET Framework. (The cryptographic configuration system is discussed in detail in the "Administering Cryptography Settings" section of Chapter 22, "Administering Isolated Storage and Cryptography Settings in the .NET Framework.")

Extending the .NET Framework cryptography classes to support a new algorithm is almost as easy as adding a new implementation of an existing algorithm. The additional work involved to add a new algorithm is to create an abstract subclass that represents all implementations of the new algorithm, similar to the role the Rijndael abstract class plays in the cryptographic object model. Your new abstract class should subclass one of SymmetricAlgorithm , AsymmetricAlgorithm , or HashAlgorithm as appropriate. By convention, the name of your new abstract class should be a short name for the algorithm it represents. For example, if you were adding an implementation of the RC6 block cipher to the .NET Framework, you would first define an abstract subclass of the SymmetricAlgorithm class called RC6 . Your abstract subclass should include definitions of property values that would be constant across all implementations of the algorithm. Continuing our example, the RC6 abstract class should include definitions for the LegalKeySizesValue and LegalBlockSizesValue fields because their values are properties of the RC6 algorithm and not any individual implementation of the algorithm. Your class implementing the new algorithm should now subclass this abstract class as in the first category of the previous bulleted list. Changes to the runtime configuration file (where cryptographic configuration information is stored) can also be necessary, depending on your specific requirements.

for RuBoard


. NET Framework Security
.NET Framework Security
ISBN: 067232184X
EAN: 2147483647
Year: 2000
Pages: 235

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net