Send a suggestion!

We're building a brand new version of the site, and we'd love to hear your ideas

Members

Technology Zones

IBM Learning Center

Articles

Hosted By

MaximumASP

Info

Rated
Read 55,064 times

Contents

Related Categories

Using Encryption in .NET - Choosing a Cipher

sjjohnson

Choosing a Cipher

Choosing a cipher

The first step toward your goal of encrypting data in C# is to choose a cipher. There are 4 ciphers provided by the FCL: DES, RC2, Rijndael and TripleDES. I'll offer a brief explanation of these and offer some advice as to why you would use one over another.

DES – DES stands for Data Encryption Standard. This is an old algorithm that has been shown to be weak by today's standards. The only weakness I'll discuss here is that it uses a short key and block size of 64 bits. We discussed the problem with short keys above, but short blocks are also weak, for reasons that are beyond the scope of this article. If you would like to learn more about why short keys and blocks are bad, search the web for "brute force key attack", "birthday paradox", "birthday attack" and "meet-in-the-middle attack", or read Practical Cryptography, by Schneier & Ferguson. Schneier & Ferguson recommend a key and block length of 256 bits. Another problem with DES is that it was purposely designed to be efficient in hardware and inefficient in software. This makes DES a relatively slow algorithm in any software implementation.

Triple DES – Triple DES is simply a strengthened version of DES. To strengthen the cipher, Triple DES runs the DES algorithm over the plain text three times, hence the "triple" in the name. It also offers stronger key lengths of 128 and 192 bits. However, it still uses a relatively weak block size of 64 bits. Another disadvantage of Triple DES is that, since it must perform the DES algorithm three times, it is a relatively slow cipher.

RC2 – RC2 is generally accepted as a good cipher and it has been around since the mid 1990s. It is also more than twice as fast as DES when implemented in software. However, it still uses a 64 bit block size and a key length (in the FCL implementation) of 40 to 128 bits in 8-bit increments.

Rijndael (a.k.a. AES) – Rijndael is the U.S. government's Federal Information Processing Standard (FIPS) Advanced Encryption Standard (AES) cipher algorithm. The names Rijndael and AES are used interchangeably in cryptography literature. Rijndael offers key lengths and block sizes of 128, 192 and 256 bits. One drawback of Rijndael is it's relative newness. Although it is highly recommended and considered strong by most cryptographers, a new cipher is one that has not withstood the same scrutiny and test of time as an older, more seasoned cipher. Newness not withstanding, the available 256-bit key and block lengths and it's acceptance as a government standard lead me to favor this cipher and I would recommend this cipher to you if you aren't constrained by compatibility or political concerns.

Key Management and Authentication

Key management and authentication are not discussed in detail in this article, but our discussion would be incomplete without mentioning them.

Key Management – To borrow a phase from Keith Brown, in essence, cryptography simply compresses large secrets into small secrets. That is, a large, secret message is rendered unreadable and no longer secret without the use of a much smaller secret, the key. Although your message, if properly encrypted, is no longer secret, you must still maintain the secrecy of the key. If an attacker gains access to the key, your messages are obviously no longer secret. Therefore, it is absolutely essential that you implement a good key management strategy to maintain the security of your keys. Another precaution you must take is to change keys frequently. Keys with a long lifetime not only allow an attacker plenty of time to break the key, but they also increase the amount of damage an attacker can do should he succeed in recovering your key.

Authentication – Even if you properly encrypt messages in your system, you are still left with two problems on the receiving end. First, do you really know who sent the data? Is the data really from the party with whom you think you're communicating, or has an attacker sent the message? Secondly, is the data received really the same as the data that was sent by the other party, or has an attacker modified the contents of the message? These problems are addressed by Message Authentication Codes (MACs) and digital signatures, and you absolutely must implement an authentication strategy in your application so that you can detect bogus messages.

Before you read on, I would highly recommend further study of cryptographic principles if you are new to the subject. An excellent place to start would be with the book I mentioned above, Practical Cryptography, by Schneier and Ferguson.

Steve is a senior developer and consultant for 3t Systems, Inc. in Denver, CO, where he spends his days doing architecture, training, and "in-the-trenches" development. Steve began programming Windows on version 3.1 in 1995 using only C, the SDK, and Petzold's classic "Programming Windows 3.1". He was a hobbyist programmer until February 1999, when he turned professional. Steve particularly enjoys learning internals and behind-the-scenes details and developing low-level infrastructure code. Steve currently resides in Highlands Ranch, CO with his wife Kathleen and two cats.

Comments

  • RE: varbinary

    Posted by bmills on 21 May 2005

    I totally agree that varbinary could have been used. My only problem with that solution is that it seems difficult to work with binary data in ADO.NET and SQL Server. I may be wrong. I haven't trie...

  • Varbinary

    Posted by nuikeoni on 19 May 2005

    Couldn't you also store this in a Varbinary field instead of trying to convert it to a string for a varchar field?

  • File Encrypting

    Posted by nuikeoni on 18 May 2005

    Dear Steve,
    I was wondering if you had some insight as to how to best to file encrypting with the rijndael encryption. Most examples I've found only give info. about how to encrypt messages. I know...

  • Posted by sjjohnson on 24 Apr 2005

    Exactly. If you don't use the same IV for encryption and decryption, the message can't be properly decoded.

  • Fixed

    Posted by wheeldo on 23 Apr 2005

    Problem seems to be fixed now - I'd uncommented the initialisation vector code and it looks like it's mandetory.

    Also - replaced the hex encoding with base64 strings (many thanks to Ben Mills on th...