One of the biggest challenges when dealing with the security and encryption for a system, is the determination of the correct ciphering paradigm. In .NET, there is a copious amount of libraries available for use in the System.Cryptography namespace. A significant amount of these libraries have been deprecated, usually, due to vulnerabilities being subsequently exposed, so it is very easy to use something that may be as watertight as a sieve.
This is further compounded by the fact that the cryptography API’s are very detailed and low level – they are not easy to use for a novice – the consequences of setting a single parameter incorrectly results in a security implementation that may as well not exist. Consequently, it is imperative that this subject never be approached in a typical agile/sprint manner – security should definitely be approached using a waterfall model. Have no hesitation to advise any manager or architect that your solution “will be ready, when it is ready”. The agile methodology is typically about adding units of functionality in a YAGNI way, accruing technical debt that can be paid back later, and refactoring applied, this just simply not a correct or acceptable approach when dealing with the security of a system. Do ensure you take the time to do a lot of research, understanding the pitfalls of various implementations is vital to a robust security implementation.
The Advanced Encryption Standard (AES)
The abundance of so many different types of cryptography, implemented using Symmetric (same key is used to encrypt and decrypt) and Asymmetric (public key and private key used to encrypt and decrypt) algorithms has necessitated that Governments try and standardise implementations across departments, sites and even countries. The AES was released in 2001 as a replacement for the Data Encryption Standard (DES) which had been found to be susceptible to backdoors. This new standard has been widely adopted in commercial environments, as it had a requirement to be able to protect information for a minimum of 20 years or 30 years.
A number of papers were submitted in the application process for the AES by various academic institutions, with the winning cipher named Rijndael (pronounced rain-dahl) a play on the names of the authors of the paper, Joan Daemen and Vincent Rijmen (paper available here). I am sure you will agree that comprehension and implementation of the paper is better suited to domain experts. The algorithm was written by two gifted PhD calibre researchers, so your time as a developer is better suited to try and resolve the domain problems that your business is trying to solve (unless you are a cryptographer of course). You can be sure that researchers at Microsoft have done all the time consuming work of implementing and testing the algorithm, rather than to trying to implement the Rijndael Block Cipher yourself.
To this end, Microsoft have implemented the Rijndael Block Cipher in two in .NET classes which, incidentally, both inherit from the SymmetricAlgorithm abstract base class
- The AES algorithm essentially, is the Rijndael symmetric algorithm with a fixed block size and iteration count. This class functions the same way as the RijndaelManaged class but limits blocks to 128 bits and does not allow feedback modes. Most developers tend to favour using the RijndaelManaged class directly, as that is the one that is used in the FIPS-197 specification for AES but there are a couple of caveats. If you want to use RijndaelManaged as AES and adhere to the specification ensure
- You set the block size to 128 bits
- You do not use CFB mode, if you do, ensure the feedback size is also 128 bits
Unlike some of the asymmetric implementations by Microsoft, the AES implementation allows you to work at a very high level of abstraction, reducing the amount of parameters you have to configure, hence the scope for error. I have created a class that allows you to encrypt and decrypt strings (your password), and then use this to encrypt a files from anywhere on your machine.
Thus far, the only way this algorithm can be broken is by using a technique known as brute force. This is done by a supercomputer(s) trying every known word in a language, and various password to try and generate the correct password. Typically, these types of programs run over weeks or even months, but can be increased to millennia if the end user chooses a strong password to begin with, which is why having a well defined password policy is vital.
I am using 256 bit (you can change this to 128 or 192)
If you have found this post useful, please take the time to rate this post by clicking on the stars for this blog post, or to say thanks in the comments.
You can download source code for the AesApp here.