Members

Technology Zones

IBM Learning Center

Articles

Hosted By

MaximumASP

Info

Rated
Read 54,024 times

Contents

Related Categories

Using Encryption in .NET - Overview

sjjohnson

Overview

Summary

In this article I will explain the classes and code necessary to put encryption to work in your applications.  I will also explain the basic principles of operation of these classes and point out several pitfalls to avoid.

Introduction

In today's hostile, interconnected computing environment, we often find the need to protect data while it is stored on a physical medium or transmitted over a network. To achieve this goal, we turn to cryptography. While the field of cryptography entails much more, in this article we will focus on encryption; specifically the ciphers available in the .NET Framework Class Library (FCL) and how to correctly utilize them.

There exists a group of developers who approach the subject of cryptography with a cavalier attitude, who think they can wave the wand of cryptography at their applications and make them secure. This group of developers mistakenly believes that applying cryptography is fool-proof and rests secure in the fact that their applications utilize "128-bit encryption" or comply with some other such buzzword. I hope that this article will awaken this group to the many pitfalls and subtleties that can silently render your crypto system easily attackable.

While the application of encryption technologies to applications is a subject that must be approached with a modicum of care and understanding, the FCL has made excellent cryptographic technologies more accessible than ever, though there are still a number of principles that must be adhered to and pitfalls to be avoided.

Why use the FCL classes? Can't I just "roll my own"?

Although there are several reasons why you shouldn't do this, I'll just state the primary reason: You'll get it wrong. While the application of standard, public, seasoned algorithms is relatively simple and accessible to the common developer, the design of the cryptographic algorithms themselves is extraordinarily difficult and is best left to the elite of the field. While the output of your cipher may look completely secure to you, a skilled cryptanalyst can likely easily find many weaknesses, such as simple algebraic relationships between input, output and key. The tiniest weakness can reveal information about the plaintext or, worse yet, the key. Unless you happen to be an elite cryptographer, stick with standard, public, seasoned algorithms and proven implementations.

This article was originally published at DotNetDevs.com

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...