.NET And Triple DES Security
page 5 of 8
by Kay Lee
Feedback
Average Rating: This article has not yet been rated.
Views (Total / Last 10 Days): 40220/ 75

Methods

[ Download Code ] | [ Download Help ]
The methods we used in the TripleDES class are directly related to the Triple DES Provider object, and are fairly straight forward except for Transform.   Since the methods are the real reason you are reading this article, we'll spend a little more some quality time with them.

Encrypt

Let's take a look at the Encrypt overloads.  We overload the two methods for one primary reason.  Give the applications an option to use the encryption byte-based or string-based.  The only thing that needs to be encrypted is a series of bytes: Files, Images, and Strings.  The reason we provide a string-based overload is for the cases where only strings are encrypted.  More often than not, passwords and sensitive strings will need encryption, and therefore, we're making it easier on the application by handling the conversion between the type string to a byte array.

The real method that starts the encryption process accepts a byte array as a parameter and returns the encrypted byte array as the output.

public byte[] Encrypt(byte[] inputvar) 
{
   return Transform(inputvar, des.CreateEncryptor(key, iv));
}

des.CreateEncryptor(key, iv).  CreateEncryptor will create an instance of the ICryptoTransform implementing object and contain the algorithm used specifically for encrypting.  The DES algorithm is described as 16 separate blocks that are encrypted in order.  Furthermore, we see Triple DES behaving the same way.  Only difference is it adds two additional processes: Decrypt and Encrypt again.

The CreateEncryptor method in the System.Security.Cryptography.TripleDESCryptoServiceProvider is very important, and it creates a symmetric System.Security.Cryptography.TripleDES encryptor object containing the algorithm as well as internal methods needed to encrypt the input byte array properly.  The encryptor will be created based on the specific Mode provided earlier in one of the properties.   What's very important is that you must use the same key, iv, and mode to decrypt, so randomizing them is not a good idea unless you're willing to save the different combinations.

The overload for Encrypt containing the string parameter and response is fairly straightforward. 

public string Encrypt(string inputvar) 
{
   byte[] inputbytes = Encoding.Default.GetBytes(inputvar);
   return Encoding.Default.GetString(Encrypt(inputbytes));
}

It will first get the bytes using the Encoding class found in System.Text namespace.  Encoding.Default.GetString is a static method, and creating an instance is not necessary.  It is passed into the other Encrypt method that accepts the byte array With the byte output.  It will retrieve the output and again convert it back to a string to return back to the application.  By using this method of encryption, you may save your passwords in SQL Server as nVarChar.  The reason we don't use VarChar is that the binary result may not always be in ASCII, and certain bytes may not convert as easily to a VarChar.  Be smart, and be safe.  Store them as Binary, but if you must use a string-based storage, nVarChar is a better choice.


Decrypt

Looking at the Decrypt overloaded methods, it's safe to assume that they are very much exactly like Encrypt.  The differences may appear minor, but the important difference is its ICryptoTransform implementation passed to the Transform method. 

public byte[] Decrypt(byte[] inputvar) 
{
   return Transform(inputvar, des.CreateDecryptor(key, iv));
}

Similar to the Encrypt method, des.CreateDecryptor(key, iv) stores the algorithm to Decrypt the input value to its original state.  Again, the key, iv, and mode must be identical to the ones used to encrypt, or an exception and/or unknown outputs are likely.  In fact, you'll never get the original input if those three are different when decrypting. 

Always use a safe Private-Key, IV, and Cipher Mode or have a means of retrieving the correct combination of the three!


WAIT! When did we set the second and third key?

The byte array we use to store the Private-Key is 24 bytes large (192 bits).  The three keys are in this array.  As mentioned in the history portion of this article, the key size for a DES encryption is 64 bits or 8 bytes.  (Special note: the 8th bit in each byte is not used, so the real encryption is 56 bits).  The first 8 bytes in the array is the first key, second 8 bytes is the second key, and obviously the last set of 8 bytes is the third key.


Since the Transform method is quite a bit longer than the rest of the methods, it will be blessed with its own page. 


View Entire Article

User Comments

Title: Hai   
Name: mangala
Date: 2008-07-22 7:54:10 AM
Comment:
good
Title: Public Key   
Name: Joe Grant
Date: 2006-12-08 12:12:50 PM
Comment:
How would one go about create a public key to share with someone so they can decrypt without sharing the private key?
Title: Excellent coverage of TripleDES   
Name: Sam
Date: 2005-08-02 9:11:49 PM
Comment:
Great stuff... simple but with enough background information to understand the important elements eg. PK, IV, Cipher etc. I will be using parts of it in my enterprise application.
Title: triple des   
Name: Josh
Date: 2004-10-13 10:12:45 PM
Comment:
we've been looking at different encryption methods in class and lectures have been so boring. i decided to search around and found your article to be a great practical implementation. i wish my class would provide us with pratical examples like this. Thanks.
Title: Thanks   
Name: Kay Lee
Date: 2004-10-13 6:42:03 PM
Comment:
Thanks. I'm glad you like it, and I hope the source works well for you.
Title: Triple DES Encryption   
Name: Brian Chiasson
Date: 2004-10-12 3:35:52 PM
Comment:
Excellent article. I have been looking for a couple of hours for something on encryption. It shed light on the subject and provided me with useful code for my intranet application. Thanks a million...






Community Advice: ASP | SQL | XML | Regular Expressions | Windows


©Copyright 1998-2024 ASPAlliance.com  |  Page Processed at 2024-04-20 10:21:27 AM  AspAlliance Recent Articles RSS Feed
About ASPAlliance | Newsgroups | Advertise | Authors | Email Lists | Feedback | Link To Us | Privacy | Search