.NET And Triple DES Security
 
Published: 21 Sep 2004
Unedited - Community Contributed
Abstract
Triple DES has grown into an industry standard in terms of encrypting and decrypting data. In this article we'll cover a very shallow layer of the history and methodology of Triple DES and show how to implement Triple DES in our .NET applications. This article will dig a little deeper than some care to go for those readers that are just learning how to use encryption in their applications and aren't satisfied with saying "it just works."
by Kay Lee
Feedback
Average Rating: This article has not yet been rated.
Views (Total / Last 10 Days): 40348/ 67

What Is Triple DES?

[ Download Code ] | [ Download Help ]

A Little History

Data Encryption Standard (DES) was originally called Lucifer.  The first publicly known version of DES was introduced by IBM in 1974.  It was submitted to the National Institute of Standards and Technology (NIST) as a cryptographic algorithm for protecting information.  Its purpose was not for the more top secret of information.  It was submitted in cases where only a frugal security measure was needed.  After being modified by the National Security Agency (NSA - Big Brother) in 1976, it was renamed to Data Encryption Standard (DES).  In 1977, it was introduced to the population, and that's when the battle began over DES.  In 1997, NIST abandoned DES, and searched for a new standard called Advanced Encryption Standard (AES).  The growing need for security caused the need for an enhancement to make DES a worthy algorithm in systems where an overhaul was not logical due to many legacy systems.

 

What Is DES?

DES is a private-key encryption that encrypts and decrypts data in 64 bit blocks.  It's been proven that the DES algorithm is only 56 bit strong because of the way it calculates the bits (only 7 of the bits are used therefore making the key only 56 bits in reality rather than 64).  The DES algorithm is iterated 16 times to achieve its goal.  What makes DES difficult to break by brute force is that the security of the algorithm is said to be exponentially increased per iteration.  The benefits of those implementing DES as their encryption method is that it's decrypted in almost the same fashion it's encrypted.  Making the decrypt method similar enough to share the same supporting methods gives the application a less complicated set of processing instructions.

The weakness in DES is in the collisions (similar outputs between the iterations).  These weaknesses become evident when you notice groups formed while brute force attacking.  Even though we talk about a potential hack, we must focus on the fact that the potential may not be feasible in most scenarios.  Everything is breakable, but will take a considerable amount of time (sometimes years) of constant processing.  The best way to gauge your security is in the type of data you're encrypting and the scale of deciphering your encryption. Furthermore, it's highly advised to avoid using the same private key for every encryption.  By jumbling up the keys used, you will avoid having a break-one break-all scenario.


What is Triple DES?

Triple DES was brought out after the fall of DES as the standard encryption practice.  Since a lot of companies and agencies utilized DES to store sensitive data, it wasn't feasible to alter the means of encryption completely as it would affect current data accumulated over several years.  Triple DES is the same series of DES iterations but is most commonly Encrypt-Decrypt-Encrypt (EDE) per iteration.  With three keys, the application will encrypt with the first key, decrypt with the second key, and encrypt again with the final key.  You may utilize only two separate keys, but it’s advised to keep all three keys completely different to maximize the security of the encryption. 

As mentioned previously, DES will run through 16 iterations to achieve its desired cipher text (final output).  With Triple DES, it will Encrypt-Decrypt-Encrypt the block and a completely different output is generated with a final combination.  It’s said that the security is 192 bit encryption, but also argued that regardless of the keys, the security is only 168 bit.  This debate is clearly beyond the scope of this article/writer. If you wish to participate with the scientists in their discussions, it’s your humility at stake.  It's a safe bet that Triple DES is exponentially stronger than the previous DES.

 

Why should I use Triple DES when it’s not the most secure?

In applications development, it is almost impossible to do everything with the most secure, proper, and advanced edge.  When you factor in scalability as well as overall performance, you must find a middle ground between all factors.  The more complex encryption you use the longer it will take to execute per request.  Even though Triple DES is not as secure as AES (Rijndael), it is a very powerful encryption that is more than enough for our everyday to enterprise applications.  As a developer, you should always evaluate what are the pro’s and con’s of a technology prior to utilizing it.  It will save you hours to days in creating work-around methods and poor explanations.
Triple DES is not as fast as its ancestor DES, but it is faster than the other complex algorithms.  The implementation is not difficult and can be very flexible and concrete with the right methods.  The following excerpt describes the feasibility of the possible hack of a Triple DES implementation.

"One thing to remember is that in cryptography there's a difference between a theoretic attack and a real one. Let's suppose, for example, I came up with an attack that needed 2^80 cipher blocks, and then could always make three-key Triple DES be no stronger than 112 bits.
That's worthy of publication, but it's not practical. A tera block (eight terabytes) is 2^40 blocks. With this attack, you need eight-tera-tera-bytes of memory and a CPU that can address that much. Also, you could defend against this attack by re-keying after a mere few million terabytes of data."
~
http://searchsecurity.techtarget.com/tip/0,289483,sid14_gci968714,00.html

It might not be the best encryption on a broad theoretical situation, but for what you will probably need to do, it is usually better than what you actually need.

In the next page, we'll cover the sample code.  To see it in it's entire solution, just download the code, and open the files in your favorite editor (Visual Studio .NET 2003 right?).

Show Me Some Code! I Love Code!

[ Download Code ] | [ Download Help ]

The example contained in this article is fully capable of being run in a production environment; however it is not the absolute standard in how to use the Triple DES algorithm in your .NET applications.  It's a very simple easy to use assembly that can be attached to any application.  It's primary focus was to assist in explanation, and it is highly advised to research in greater detail prior to final implementation.

Simply download the code, and open it with your favorite editor.  It would be best if you compiled the solution to see it in action as well.  In the next few pages, we'll discuss each portion of the class, and finally implement the Triple DES Encryption into our applications. 

Definitions and Objects

[ Download Code ] | [ Download Help ]
Rather than going straight to the code to just show you how it's done, we're going to opt to explain some of these objects along with how to code.  In this article, it’s assumed you know what regions are and you’re aware that comments are there to assist other developers in understanding the code. 

Basic Definitions

Initialization Vector (IV):

A block of bits (64 for DES), that is combined with the first block of data depending on the mode of the encryption.  Sometimes it is random, and it can also be sent with the encrypted outcome. 

Private-Key:

A secret block of bits used to encrypt.  Depending on the type of encryption, the size of the blocks of bits may differ.  The size of the Private-Key does not directly reflect the strength of the encryption.  The specific algorithm mixed with the size of the Private-Key determines the overall strength of the encryption: for example, you may have a 192 bit Triple DES encryption, and it won’t be as secure as a 128 bit Rijndael encryption.

Cipher Modes:

Basically different methods on how the blocks of data are processed.  Often 64 to 128 bits, the mode determines the encryptions confidentiality and integrity. 

Stream:

A flow of data of some sort is considered a stream.  The flow’s length may be undetermined, but it usually has an end.

Memory Stream:

A stream object that will read bytes is used commonly in byte-based encryption algorithms.  It is commonly used with files, but may be used with any type of byte collection.

What are the Objects Used?

The objects used in this article are bytes, Encoding, Memory Streams, regular base streams, Cryptographic Transformations, Cryptographic Streams, and enumerators.  For the most part, you should have a good grasp on some of these objects, but we’ll go over them briefly.

  • A byte is 8 bits.  If that’s news to you, I suggest opening up a more beginner’s tutorial so you don’t get overwhelmed with information.  For the rest of us, a byte is a small integer with a value between 0 and 255.  A single character is usually calculated as one or two bytes depending on the language.  A collection of bytes or a byte array is just what the name describes.  It contains any number of bytes in a specified order. 
  • Encoding objects are used to easily convert to different types.  Typically used with base types such as Booleans (bits), bytes, integers, strings, and the rest of the common types we use everyday.  The use of the encoding objects help keep our data integrity and give a forgiving method of translation rather than having a clutter of functions to manually do the conversions.
  • Memory Streams are found under the namespace System.IO, and has several overloaded constructors.  Memory Streams differ from the normal stream object as it specifically uses RAM as a backing store instead of disk or network transfer. 
  • A base Stream object is also found under the namespace System.IO, and is usually what most other streams are inherited from, and is an abstract base class.  It’s and abstraction of a sequence of bytes of any sort.
  • Cryptographic Transformations are found under the namespace System.Security.Cryptography implementing the ICryptoTransform interface, and they are algorithms and processes stored to assist in ease of development. 
  • Cryptographic Streams are found in System.Security.Cryptography, and are used by the common language runtime (CLR) of the .NET framework’s design for cryptography. 
  • Enumerators are essentially a distinct type of named constants.  Usually starts with values 0, but may be specifically created to start with any integer, it’s used primarily to add a language to the constant values. 

With the basics out of the way, we can start looking into the underlying code to see how the Triple DES Encryption is implemented in our .NET applications. 

Variables, Properties, and Enumerator Explained

[ Download Code ] | [ Download Help ]
To reiterate a very important message, it’s highly advised to continue your research on encryption on a broad scale and Triple DES intimately.  Your awareness of the methodology and algorithm of the encryption technology you choose essentially determines how secure your data is.  With definitions and all the tedious portions of the article out of the way, we'll start covering what each method actually does and why it's done in that fashion.
  


On a broad scale, the example uses a single provider class that wraps the TripleDES class found in System.Security.Cryptography namespace.  The TripleDESCryptoServiceProvider is gracefully given to us by the .NET framework, and it opens us to an easy to use class for Triple DES encryption.  With a single glance over in the documentation provided in the version 1.1 SDK, the TripleDESCryptoServiceProvider’s example is not very exciting.  However, it does show a good example of how easy it is to implement if you have the right idea.

Class Level Variables

private TripleDESCryptoServiceProvider des;
private byte[] key;
private byte[] iv;

By declaring the TripleDESCryptoServiceProvider on a class level scope, it gives us the freedom to create specialized methods to modularize the process.  Most of the process is similar in that only the ICryptoTransform implementation is different from encryption and decryption.  This is a luxury of some cryptographic algorithms, and DES is one of them. 

The two major objects stored are "key" and "iv".  Both are byte arrays of different lengths and both are needed in this class.  The "key" for a DES-based algorithm is always in multiples of 64 bits or 8 bytes.  For our example, we are maximizing the key’s strength by using 24 byte keys, so we can safely declare the array to store 24 values.  The byte array "iv" is also always going to be 64 bits or 8 bytes in length, so it is safe to lock in the length of the array. 

Constructor

public TripleDES()
{
   des = new TripleDESCryptoServiceProvider();
   iv = new byte[8];
   key = new byte[24];
}

By design, we avoid instant instantiation of the object.  When a new instance of the class is created, we’ll instantiate the objects in the constructor, and unless the object has a static declaration, this is considered by many as better practice.

Properties

public byte[] Key 
{
     get { return key; }
     set { key = value; }
}
public byte[] IV 
{
     get { return iv; }
     set { iv = value; }
}

We’re giving more control of operations on the assembly itself than the application calling the class by using private declarations on the objects, and public properties.  You may choose to publicly allow the members to be accessed, but it’s of no real value to the application or the assembly in this scenario.  

public string SetKeys 
{
     set 
     {
          byte[] md5key;
          byte[] hashedkey;


          md5key = MD5Encryption(value);
          hashedkey = MD5SaltedHashEncryption(value);

          for (int i=0; i < hashedkey.Length; i++) 
          {
               key[i] = hashedkey[i];
          }

          int startcount = hashedkey.Length; /* always 128 */
          int midcount = md5key.Length / 2; /* always 64 */

          for (int i = midcount; i < md5key.Length; i++) 
          {
               key[startcount + (i - midcount)] = md5key[i];
               iv[i - midcount] = md5key[i - midcount];
          }

          md5key = null;
          hashedkey = null;
     }
}

Most of the properties are very straight forward, but SetKeys is a little different.  Given a situation where the application will not have the code to create its own key or iv, the SetKeys property was created to utilize an MD5 algorithm to create a write-only key/iv combination.  In this implementation, the value is run through both a simple MD5 and Salted MD5 hashing algorithm to generate a 24 byte arrays. 

The way SetKeys creates the key is by using the salted hash output, and appending the first 8 bytes of the regular hashed output.  The IV is the remaining 8 bytes of the regular hashed output.  This makes the private key a little more difficult to crack if the string version is unknown.

Enumerators

public enum CipherMode 
{
   CipherBlockChaining = 1,
   ElectronicCodebook = 2,
   OutputFeedback = 3,
   CipherFeedback = 4 
}


private System.Security.Cryptography.CipherMode TranslateCipherMode(KraGiE.TripleDES.CipherMode ciphermode) 
{
   return (System.Security.Cryptography.CipherMode)Convert.ToInt32(ciphermode);
}

Before going into the CipherMode-based properties, it’s best to examine the new enumerator (enum) we created in the class.  This enumerator is a mirror to the System.Security.Cryptography.CipherMode in the values.  The only difference is the definition used to describe the numeric constants.  System.Security.Cryptography.CipherMode uses abbreviations for describing the constants, and the enum in our example will use the full names of the modes.  It’s later mapped back to become the correct CipherMode enum value by converting to an integer, and returned as the type System.Security.Cryptography.CipherMode

The 4 available Cipher Modes for the DES algorithms are:

  • Cipher Block Chaining (CBC)
  • Electronic Codebook (ECB)
  • Output Feedback (OFB)
  • Cipher Feedback (CFB)

For more information on Cipher Modes, and what they are specifically, you may view the differences at http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation.

public System.Security.Cryptography.CipherMode GetCipherMode 
{
   get { return des.Mode; }
}
public KraGiE.TripleDES.CipherMode SetCipherMode 
{
   set { des.Mode = this.TranslateCipherMode(value); }
}

The two CipherMode-based properties are GetCipherMode and SetCipherMode.  The GetCipherMode property will return the current mode from the TripleDESCryptoServiceProvider, and SetCipherMode will convert the class’ enum version to the correction System.Security.Cryptography.CipherMode version, and set the TripleDESCryptoServiceProvider’s Mode property.  By setting the Cipher Mode of the encryption, you may jumble up the output even further  After researching the differences of modes, you may implement the mode that best fits your applications needs.



So far, everything's pretty straight forward, and we can take a look at the meat of the code.  The methods are described in the next page.

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. 

The Transform Method Exposed

[ Download Code ] | [ Download Help ]

Transform the Input and Get an Output

The transform method was designed to handle both encryption and decryption since symmetric algorithms are very similar in terms of how to encrypt and how to decrypt.  That's one of the advantages of implementing symmetric encryption in your application.  The example's Transform method was adopted from http://www.developer.com/net/vb/article.php/3077901 when the original implementation was written a couple of months ago.  Since then, it was expanded to fit the mold a little better using C# and more of the System.Security.Crypography.TripleDESCryptoServiceProvider

private byte[] Transform(byte[] inputvar, ICryptoTransform transform) 
{
   System.IO.MemoryStream stream = 
      new System.IO.MemoryStream(2048);
  CryptoStream encryptstream = 
        new CryptoStream(stream, transform, CryptoStreamMode.Write);
   encryptstream.Write(inputvar, 0, (int)inputvar.Length);
   encryptstream.FlushFinalBlock();
   stream.Position = 0;     
   byte[] returnvar;
   returnvar = new byte[(int)stream.Length];
   stream.Read(returnvar, 0, (int)returnvar.Length);
   encryptstream.Close();
   stream.Close();
   encryptstream = null;
   stream = null;
   return returnvar;
}

The Transform method has two parameters that require a brief examination.  As mentioned before, DES-based encryptions are byte encryptions and will alter bytes through the DES algorithm.  The first parameter is a byte array holding the value that's to be transformed.  The second parameter is the ICryptoTransform implementing class that we pass in via Encrypt or Decrypt.  That's where most of the logic is and is a very important part of the processes.  This method was set to a private declaration since it should only be used by the Encrypt or Decrypt methods.  By making it public, it would defeat the purpose of having all the operations in a specific class or assembly, and it's also bad practice.   

CryptoStream encryptstream = 
 new CryptoStream(stream, transform, CryptoStreamMode.Write);

The CryptoStream object is found in the System.Security.Cryptography namespace and is used in most encryption implementations.  It requires three parameters: System.IO.Stream, ICryptoTransform, and CryptoStreamMode.  The Stream object we use is the MemoryStream since the value of the parameter will be filled as the input byte array is fed in.  The ICryptoTransform containing the algorithm instructions is passed in directly by the calling methods (Encrypt and Decrypt), and the CryptoStreamMode we use is Write.  We use System.Security.Cryptography.CryptoStreamMode.Write because we want to write the outcome into the MemoryStream.

// Write the input array values into the crypto stream, and transform.
encryptstream.Write(inputvar, 0, (int)inputvar.Length);
encryptstream.FlushFinalBlock();

It's safe to assume many are shaking their heads thinking "lazy."  We're using CryptoStream.Write to write the transformation into the stream.  The first parameter is the byte array storing what's to be read into the CryptoStream.  The next two are integer based indicating the start and how many to read and transform into the CryptoStream.  We use the FlushFinalBlock method to clear the remaining space in the MemoryStream.

In English, we're sending in a byte array, telling it to get the first to last items, and destroy whatever is left of the stream after it's been filled with the transformed bytes.

stream.Position = 0;     
byte[] returnvar;
returnvar = new byte[(int)stream.Length];
stream.Read(returnvar, 0, (int)returnvar.Length);

Next on the plate is to retrieve the output from the transformation.  To achieve this, we first set the stream to rewind back to the beginning by setting the property Position to 0.  We declare the output byte array (this can be declared at the beginning of the method if you prefer), and we set the output byte array to a new byte array with the size of the stream.  Using the Read method, we read the stream into the byte array in a similar fashion as we wrote previously.

All that's left is to close the streams and return the output byte array.


This example is a fairly easy implementation and can be altered to meet your application's needs.  The best bet is to avoid making the methods more complicated than they need to be.  The .NET Framework offers a lot of high-level objects that will do most of the work for you.  It's obvious that 90% of the time, a custom implementation can be faster by using lower-level objects.  However, in the case of Cryptography, it's best to let the scientist do what they're good at, and let the programmers do what they're best at.

Good, Now How Do I Use It?

[ Download Code ] | [ Download Help ]
When using the encryption assembly, you may refer to the windows form example attached to the solution.

The way you use this article's implementation is quite simple. 

string password = "MyPassword1s123";

KraGiE.TripleDES des = new KraGiE.TripleDES();
des.SetKeys = "Whatever your Private-Key Is";
des.SetMode = KraGiE.TripleDES.CipherMode.CipherBlockChaining;
string encrypted = des.Encrypt(password);

System.Diagnostics.Debug.WriteLine(encrypted);

string decrypted = des.Decrypt(encrypted);

if (password == decrypted)
     System.Diagnostics.Debug.WriteLine("Success");
else
     System.Diagnostics.Debug.WriteLine("Kay doesn't know what he's talking about.");

des = null;

Just remember that you need to either use the SetKeys property or manually set the Key and IV properties with 24 byte and 8 byte arrays respectively.  Based on the parameter type of the Encrypt and Decrypt method, you'll receive the same type back.

In Conclusion

[ Download Code ] | [ Download Help ]
Many programmers out there in the code wise community, and those that are in your everyday office life, may state that implementing a strong encryption is a very difficult chore.  It is a difficult task, but with a little ground work, any difficult task becomes easy.  We've covered most of the aspects of the DES and Triple DES encryption.  In a total of 350 lines of code including comments, we've implemented one of the most widely-used encryption algorithms available. 

Key points to remember:

  1. Triple DES is as secure as your Private-Key and Initialization Vector.
  2. It is best to research the different types of encryption algorithms to ensure your choice is the right one for the job.
  3. The DES-base algorithms have been broken in the past.  However, realistically, Triple DES is more than enough in terms of encryption strength for most of our applications.
  4. NEVER lose the Private-Key, Initialization Vector, and Cipher Mode combination per encryption.  Without all three parts absolutely correct, you may never decrypt the original data.
  5. The example source may work as is but may require some alterations to fit your applications needs.
  6. Read, read, read.  Test, fail, test again.  Always try what you've read, and continue to keep your knowledge up to date. 

Salted MD5, Triple DES, Rijndael (AES), Blowfish, and RSA are common encryption algorithms used in the programming world today to safely store sensitive information.  Prior to jumping on a technology, it's to your best interest to know the overall details of each encryption algorithm including their flaws before deciding on the exact one you wish to implement.

For further reading on cryptography with the .NET Framework, you may visit the following sites.

  1. http://msdn.microsoft.com/library/en-us/cpqstart/html/cpsmpnetsamples-howtocryptography.asp?frame=true
  2. http://www.gotdotnet.com/team/clr/cryptofaq.htm
  3. http://www.ftponline.com/vsm/2003_03/magazine/features/vandersypen/
  4. http://www.developer.com/net/net/article.php/1548761
  5. http://csrc.nist.gov/CryptoToolkit/aes/rijndael/
  6. http://labmice.techtarget.com/security/crypto.htm
  7. http://searchsecurity.techtarget.com/tip/0,289483,sid14_gci968714,00.html
  8. http://www.itl.nist.gov/fipspubs/fip46-2.htm
  9. http://www.laynetworks.com/des.htm (JavaScript source)
  10. http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation
  11. http://msdn.microsoft.com/library/en-us/cpref/html/frlrfsystemsecuritycryptographytripledesclasstopic.asp?frame=truehttp://www.tropsoft.com/strongenc/des.htm


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-03-29 9:50:40 AM  AspAlliance Recent Articles RSS Feed
About ASPAlliance | Newsgroups | Advertise | Authors | Email Lists | Feedback | Link To Us | Privacy | Search