Is your data secured? Are you confident that the prying eyes of your competitors can't view sensitive information being stored on or transmitted from your applications? Are you sure that the data you receive from vendors and partners was actually sent by them?

More important, are you so certain the data your application protects will stay protected that you are willing to risk your reputation, or your company's reputation?

If you are like some of the developers I've spoken to in the past about cryptography, you were just about to turn the page to the next article thinking, "Well, I really don't need to know this stuff" or "Crypto is just boring, why would I put myself through the pain of reading an ENTIRE article about it?" Well just hold on there and continue reading, for I assure you the following will be fun, informative, and may save you from an angry herd of screaming managers! OK, perhaps not that last part, but at least fun and informative.

Terminology
We are not at the fun part yet. To have an intelligent conversation about crypto we first need to make sure we are all using the same terms.

• Cipher: A process or algorithm used to substitute values in a block or stream of data such that they are transposed or substituted.
• Ciphertext: The output of a cipher. The plaintext processed by a cipher is the ciphertext.
• Hash: The result of a hash algorithm.
• Hash Algorithm: Used to take an unknown amount of data and reduce it to a fixed length of unique bytes.
• Initialization Vector (IV): A set of bytes that will add entropy to your ciphertext.
• Key: A series of bytes used to encrypt or decrypt a message.
• Plaintext: An original message, text, or binary data before it is encrypted.

Cryptographic Ciphers
Cryptography comes in two basic flavors: asymmetric and symmetric. To determine if a cipher is asymmetric or symmetric you need to examine how the keys are used. If the same key(s) are used to encrypt and decrypt data then the cipher is symmetric. If you have two different keys, one for encryp-tion and one for decryption, then you have asymmetric encryption.

Both symmetric and asymmetric algorithms have their strengths and weaknesses. Dealing with those weaknesses, for example, "How do we transmit keys securely?" or "Where do we store the keys when we have them?" will be more trouble to you as a developer than actually using cryptography in .NET to encrypt and decrypt data.

Symmetric Cryptographic Ciphers
The System.Security.Crypto-graphy namespace currently supports four symmetric ciphers:

• DES: Used by financial institutions to hold volatile data. DES is used for anything that needs to be secure in a measure of hours, not days. This algorithm uses a 56-bit key and a 64-bit block size. This cipher has been proven to be breakable in 3.5 hours.
• 3DES (Triple DES): This uses 3 keys. The first key is used to encrypt the data using the normal DES algorithm. The second key then decrypts the encrypted data, essentially decrypting it into mush as you are attempting to decrypt with the nonencrypting key. Then the third key reencrypts the data output from the second key's decryption. One of the problems with Triple DES is that it takes three times as long as DES.
• RC2: Invented in 1987 by Ron Rivest (the R in RSA), RC2 can use a key of 8 to 128 bits and uses a 64-bit block size. One thing to note is that RC2 is actually twice as fast as DES. RC2 is only cryptographically as strong as your key. Since you have the ability to use an 8-bit key you could make this easy prey to brute force cracks.
• Rijndael (or AES): This is the current replacement candidate for DES. It will work with key sizes of up to 256 bits. However you can also alter the block sizes that are used during the encryption to 128, 192, or 256 bits. Due to the flexibility of this algorithm it has no known vulnerabilities.

All of the above ciphers are known as block ciphers. This means that when data is being encrypted or decrypted it is processed in chunks of bits and not on each individual bit. There are other ciphers, such as an RC4, that operate on data byte by byte and not in blocks. This article will focus on the block ciphers that are provided by the .NET framework.

Each of the above algorithms has a specified block size of data it will encrypt or decrypt. For example, the DES and 3DES algorithms encrypt data in blocks of 64 bits. This poses a problem. There is fun and interesting stuff ahead so pay close attention!

Imagine if you will, we have created a system that is communicating with our B2B partner over the Internet. We are using 3DES as our algorithm and we're sending information about orders and clients. The first block of data in each message is a definition of the columns of data that will be contained in the message.

If anyone were to intercept this message and try to crack it there are several things he or she would do. Brute force cracking 3DES, RC2, or Rijndael with current computing technology would take too long. The alternative would be to start looking for patterns. A big part of cryptanalysis is to look for patterns in the encrypted data. If our algorithm just takes blocks of a defined size and encrypts them, any two messages that had the same plaintext in a block would look the same when encrypted. This would create a pattern that could be used to crack your encrypted data.

To protect against ciphers creating recognizable patterns Chain Block Ciphering (CBC) was invented. CBC is one of the modes that can be set on your symmetric algorithm class. CBC takes the encrypted data from the first block and uses part of the digest of that data to encrypt the second block of data. This continues until all of the data is encrypted; this way, even if you had two blocks of data that contained the same plaintext they would not look the same once encrypted.

So now the only problem would be the first block of data. There is no previous block of data from which to get a digest to use in encrypting the first block. This is where our need for an Initialization Vector appears. An Initialization Vector (IV) is used to help encrypt the first block of data. IVs do not have to be kept a secret because they are not a key and are not relatedin any way to the key used to encrypt the data.

The IV, however, is necessary to decrypt the data once received. You can transmit the IV along with the encrypted data. Think of the IV as a pre-block-one block of data. Just something that can be used to keep the first block from looking the same if the same plaintext is contained within the data over multiple message transmissions. Most of the time the IV will be a hash of data that will be unique with each message transmission.

Asymmetric Cryptographic Ciphers
The cryptographic provider you will use for asymmetric encryption will be the RSA provider. The RSA provider allows you to encrypt, decrypt, digitally sign, and validate digital signatures. While we're talking about digital signatures, there is a second provider called DSA. This provider is not used for encryption or decryption; rather it is used for signing and verifying digital signatures.

The two keys that are used in asymmetric cryptography are known as a public and private key. The two keys are mathematically related. I will refrain from going into the details of how but just keep in mind that a private key you keep…well, private. This will be the key you use to decrypt all messages coming to you. You give your public key to…well, the public. Man, this crypto stuff is hard! The public key is used to encrypt data that can then be sent over the Internet.

One of the side effects of having two keys that are the mathematical inverses of each other is that you can encrypt and decrypt using either key. I have explained that data can be securely transmitted over the Internet by encrypting with the public key and can therefore only be decrypted with the private key. What happens if I encrypt with the private key and send data across the wire? Is it secure? If anyone can grab the public key and decrypt the data, then what is the point? The answer to these questions lies in the fact that my public key is the only key that matches its private key inverse. Given this fact, if I encrypt a message with my private key and you use my public key to decrypt it, you now know that I was the one who sent the original message. My private key is the only key that could have been used to encrypt that message. Now we have a digital signature. I can sign a message and anyone who consumes that message can guarantee that it came from me.

Write Some Code Already!
Now that we have all of the boring stuff out of the way we can finally get to the fun stuff. Listing 1 shows you how, in very few lines, you can leverage the full power of cryptography in .NET. For this example I will show you how to encrypt a message using 3DES, which means we will use the same key to encrypt and decrypt our message.

The code in Listing 1 has two functions, EncryptMessage and DecryptMessage. The EncryptMessage function takes a string, the key, and an initialization vector. The return is a byte array of encrypted data. To display the value from the byte array to the screen or to a text-box you would use the following code.

txtEncrypted.Text = Encoding.
 UTF8.GetString(EncryptMessage
 (szSomeMessageToEncrypt, baKey, baIV));
txtDecrypted.Text = Encoding.UTF8.GetString(DecryptMessage
(baEncryptedData, baKey, baIV))

Keys. . . Now Where Did I Put Those Keys?
Key management is the bane of all cryptographic systems. In the symmetric ciphers you have one key, and potentially an initialization vector, that are needed to encrypt as well as decrypt our messages. In the asymmetric cipher you have a pair of keys, public and private, that need to be housed somewhere. How do you allow your applications access to these keys? Where can they be securely stored and only retrieved by your application? How do these keys get to your B2B partners or clients to use to encrypt data to send to you and decrypt data coming from you?

Unfortunately the answer to the question of key storage is a much longer topic then we have time for in a single article. In a future article I will be able to illuminate the dark that seems to shroud the answers to the questions about key management.

Conclusion
Cryptography is not as scary as it seems at first. It is up to you as a developer and/or architect to make sure that your applications maintain data integrity, secrecy, and authenticity. With .NET's built-in support for symmetric and asymmetric ciphers your application should be able to protect data in a variety of different situations. Protecting a single field in a database or protecting-large scale B2B communications has now been made much easier with .NET.

My parting advice would be that you should not wait until the day before delivery of a project to say, "Oh yeah, perhaps we should wire in some crypto or something." Cryptography, like any security planning, needs to be done up front in the architectural phase of the project.