The .NET Framework provides rich support for cryptography via the following name spaces:
- System.Security Cryptography - Core classes that provide crypto functions
- System.Security Cryptography.Xml - Classes used to encrypt and sign XML documents
- System.Security Cryptography.X509Certificates - Classes used to retrieve certificate information
Like anything to do with Security, the crypto field is full of jargon as well. So a few definitions are in order:
Plaintext or Cleartext is just that, something that is plain and has not had any crypto functions used on it.
Ciphertext is output of using some sort of a crypto function on plaintext.
Encryption is the process of smacking the data around so completely, using a specified key, that it basically looks like a big lump of apparently unrecognizable goo (ciphertext). Decryption is the process of taking that big lump of goo (ciphertext), stirring it with a key, and turning it back into the original data (There.. That should be scientific enough for ya!)
Symmetric encryption
The same key is used for converting plaintext to Ciphertext, and back.
Asymmetric Encryption
This is also known as public-key encryption. Instead of one key, you have a pair of keys (called a key pair) that are created at the same time. One key is called a public key and the other a private key. The interesting thing here is that the conversion to Ciphertext is done with the public key and the reverse can ONLY be done with the corresponding private key. There is no way that you can use a public key to decrypt the information. (UPDATE: This is not true, or the whole concept of digital signatures would fall down. It is more accurate to say that anything encrypted with one key can only be decrypted with the other one). So if you wanted someone to send you an encrypted message, you could very well advertise your public key and anyone could use that to send you a message. And you would be the only person who could decrypt that message, because you would have the only corresponding private key!
Hashing (also called a message digest) is a way of producing a fixed size representation of plaintext, which can be of any size. This is a one way process whereby you turn plaintext into unrecognizable Ciphertext! There really is no way to reconstitute the Ciphertext back into plaintext. A good place where you would use this would be for storing passwords. Instead of storing the passwords in plaintext, you could hash them into Ciphertext and store it. When you needed to verify a password, you would use the same hashing function to process the given plaintext password into Ciphertext and compare it to the stored value. If the hash values match, you are golden! If not, the wrong password was entered.
Salting the Hash comes in because hashing by itself has a vulnerability. Most people, when creating something like a password uses alphanumeric combinations that are memorable. (See my earlier entry about how truly bad most passwords are). Which means those passwords are vulnerable to a dictionary attack. A dictionary attack is an attack in which a cracker tries all words and word combinations in order to get a password match.
A salt is a cryptographically strong random number that is combined with the hash to create the final Ciphertext. So in order to compare the given password to the stored Ciphertext, you also need to provide the salt, which makes dictionary attacks a whole lot harder.
9:11:55 PM 
Comment
This last week I had the pleasure of wandering around Florida speaking with
Dan Sandlin and David LeBlanc at a series of Microsoft architecture councils.
For those who don't know the name David LeBlanc wrote the very popular book Writing Secure
Code with Michael Howard. At each of the session I would do a talk / q&a
on P of EAA (which got a
JavaWorld award
this week) and David would follow on security.
One thing that interested me was that several people found the combination
odd - implying that few people would be interesting in two such diverse topics.
I think this is at the heart of problems about security in the industry.
Security is seen as some separate topic area which sits in its silo. Yet
security isn't something you can just add to an application by putting in a few
encapsulated classes here and there. Security thinking should pervade a whole
team - particularly on applications that are available on the internet or a
large corporate intranet.
To be fair there's room for people to focus on security issues. There's a lot
of stuff to know about on security. But everyone should have a reasonable
knowledge about it. As David points out: many eyeballs don't lead to secure code
- you need many educated eyeballs. One of the things I like about David's
attitude is that educating developers is a key part of the picture, with less
emphasis on review steps with security groups.
[Martin Fowler's
Bliki]
Right On! Security should not
be something that is bolted on but should be part of the application lifecycle
from the start.
BTW, for those not familiar with the name,
Martin Fowler is the author of two amazing books, "Refactoring" and "Patterns of
Enterprise Application Architecture". And David LeBlanc is the co-Author of
"Writing Secure Code"
12:44:38 PM
Comment
Fairly significant update to FxCop was posted today... check it out... Lots
of new rules and bug fixes...http://www.gotdotnet.com/team/fxcop/
[Brad
Abrams]
Indeed.. Just a recap that "FxCop is a code
analysis tool that checks .NET assemblies for conformance to the Microsoft .NET
Framework Design Guidelines. It uses reflection, MSIL parsing, and callgraph
analysis to inspect assemblies for more than 200 defects in the following areas:
naming conventions, library design, localization, security, and performance. The
package includes both GUI and command line versions of the tool, as well as the
SDK to create your own rules."
To see the list of Security related rules
see http://www.gotdotnet.com/team/fxcop/docs/rules/SecurityRules.aspx
12:06:12 PM
Comment
