Introduction

This article gives an insight into Symmetric Encryption and how it can be implemented in .NET. In the sample explained below, we are using the Rijindal symmetric encryption algorithm, which is available in System.Security.Cryptography namespace. It also illustrates the making of secret key using the PasswordDeriveBytes class. I have also provided a simple class which hosts the function for encryption and decryption.

Why We Use Cryptography??

As everyone knows, cryptography is used to preserve some data so that it is not modified or readable to others. There are two types of cryptographic algorithms available: symmetric and asymmetric encryption.

Symmetric (or Private-key) Encryption

Symmetric (or private-key) encryption uses a single key for both encryption and decryption. A compromised key can lead to complete failure of the security of a system. With symmetric algorithms, the security of the key is inversely proportional to the number of people who have the key.

Asymmetric (or Public-key) Encryption

With asymmetric (or public-key) encryption, there are two mathematically related but independent keys, a public key and a private key. Information encrypted with the private key can only be decrypted with the corresponding public key, and information encrypted with the public key can only be decrypted with the corresponding private key.

How Symmetric Algorithms Work ??

Symmetric algorithms of the type discussed in this article are block ciphers. They break cleartext up into blocks of a fixed size (in the case of the Rijndael algorithm, 16, 24, or 32 bytes) and perform iterative rearrangement and substitution on successive blocks. Rijndael is used for the CryptoUtility because it offers the greatest key length of the algorithms available natively from .NET—256 bits.

Options for Symmetric Algorithms

Symmetric algorithms offer a number of options to control their operation. In most cases, you don't have to set these specifically as the chosen defaults are the most secure. However, it helps to understand what they're doing. The options for symmetric algorithms include the following:

Mode sets the cipher mode. For Rijndael, this is either Cipher Block Chaining (CBC) or Electronic Code Book (CB):

CBC, the .NET default, is the most secure cipher mode. CBC performs an XOR operation on each block of cleartext with the previous cipher block before enciphering it. It also requires an Initialization Vector (IV), a random block of the same length as the algorithm's block size. The IV is used as a stand-in to perform Cipher Block Chaining on the first block of cleartext, since at that point there is no previous block. The IV ensures that repetition in the first block of cleartext does not result in similar repetition of the first block of ciphertext when the same key is used.

ECB, the less-secure option, has each block enciphered independently. Repetition in the clear text may produce patterns in the cipher text, thereby weakening security.

Creating Strong Keys

Predictable cryptographic keys, like predictable passwords, badly compromise the security of your application. Don't generate these keys by hand—humans are poor random number generators. Using the System.Random pseudo-random number generator is also not sufficient since its random sequences are deterministic and repeatable (hence the name "pseudo-random").

In the example, we will be creating a cryptographic key from a password which is a string. Starting with a plain-text, easily memorized passphrase, you can use the PasswordDeriveBytes class to generate a cryptographic key. This method is mainly useful when a user will input a passphrase, which will immediately perform encryption or decryption and then be discarded.

Another option is the use of RNGCryptoServiceProvider to generate strong keys. It generates cryptographically strong random numbers and is suitable for key and salt/IV generation. Though RNGCyptoServiceProvider is technically a pseudo-random generator, it is NIST-certified as cryptographically strong.

Creating Strong Salt

NB: In real case, never hard-code a password within your source code. This is because Hard coded passwords can be retrieved from an assembly using the MSIL Disassembler (Ildasm.exe) tool, a hex editor, or by simply opening up the assembly in a text editor like notepad.exe.

The following code snippet illustrates the creation of encrypter/decrypter:

How do you suppose this can be hacked, Paresh? Seems rough to give a vote of 1 based on the fact you didn't bother to understand the article. Looking at your comments I am starting to see a theme. This is the problem with giving everyone a vote,... some people do not use them wisely.

I heard that once the code is deciphered, it is completely exposed to prying eyes of a potential hacker in-memory, because the entire assembly loads into memory in itsMSIL form. This poses a security threat since once the assembly loads in-memory, it can be dumped to a file using standard memory dump tools. When this happens, hackers can retrieve the portion of the code they are interested in exploring.

In .Net 2 it is recommended to use Rfc2898DeriveBytes class instead of PasswordDeriveBytes class.However the Rfc2898DeriveBytes class requres at least 8 bytes in Salt.I ended up with the following function:

From wiki "The salt value may, or may not, be protected as a secret. In either case, the additional salt data makes it more difficult to conduct a dictionary attack against for example, a password file, using pre-encryption of dictionary entries. Each bit of salt used doubles the amount of storage and computation required.

In some protocols, the salt is transmitted as cleartext with the encrypted data, sometimes along with the number of iterations used in generating the key (for key strengthening). Cryptographic protocols which use salts include SSL and Ciphersaber."

When I run your code I get this error: "cryptoStream.Read(PlainText, 0, PlainText.Length) Run-time exception thrown : System.Security.Cryptography.CryptographicException - Length of the data to decrypt is invalid."