Whenever you design a piece of software, a good rule of thumb is, "Simple is better." Sure, we can't always make our applications as simple as we'd like, but it is an ideal that designers have been chasing for a long time. In this spirit, I am writing a series of blog postings relating to application security based upon some very simple principles most of us remember from elementary school. It is the intent of this series that you, the developer, will be able to apply good, solid security principles in your software design.
Part 2: Don’t Pass Notes If You Don’t Want Them Read Aloud
Many times in software development we have information we need to keep hidden. This could be because of legislative, personal, or professional reasons. There is always a question of the best way to handle this. There are, after all, a lot of tools available to developers which make encryption readily available to us.
So, what types of encryption are out there, and which one is the most appropriate to use? Encryption comes in two different flavors: symmetric and asymmetric. Both have their uses and drawbacks.
Symmetric Encryption (or Secret Key Encryption):
Symmetric Encryption is very similar to the well-known “password” concept. All data is encrypted by a “password” (or, more appropriately, a key). Once encrypted, the data can be sent to anyone, but only those people who possess the key can read the data. The longer the key is, the stronger the encryption that is provided. This is form of encryption actually has historic roots going back as far as the Roman Empire, with the advent of the Caesar cipher.
The .NET Framework 3.5 possesses a number of symmetric encryption classes available for use. It is best to use the Rjindael class whenever possible, as it uses one of the strongest encryption methods available. The other classes provide different degrees of strength. One example: TripleDESCryptoServiceProvider is little more than the DESCryptoServiceProvider being ran three times.
The main weakness of the symmetric encryption is in key management: once you generate your key, how do you give it to your clients without others being able to read it? On the plus side, symmetric encryption is very quick, from a software performance perspective. This alone makes symmetric encryption a very appropriate means of securing data.
Asymmetric Encryption (or Public Key Encryption):
Asymmetric Encryption is a relative newcomer to the cryptography field. Its roots trace back to the late 1800s, and a working implementation, known as Diffie-Hellman, was published in 1976. It solves the key-swapping problem of the symmetric encryption routines, although its mechanism can be a little more difficult to understand.
With this type of encryption, there are two or more parties involved with a message. Each party has two keys: a public key and a private key. The public key can encrypt a message, but only a private key can decrypt the message. Conversely, a private key message can encrypt a message, but only the public key can decrypt the message. Mathematically speaking, it is impossible for a public key to both encrypt and decrypt the same message. Nor can a private key perform both actions: the two keys work as a team. One key, by itself, has no value. Public/Private key encryption also have the added benefit of non-repudiation. This means they can be used to verify a specific sender. When combined with security hashes (a future blog post), they act as digital signatures.
With that being said, the public key can be sent out to anyone who requests it without any worries of information being compromised. All parties will then freely give out their public keys. Then, any message that needs to be sent to a given party is encrypted with that party’s public key. Then, once it is sent, only the party’s private key can decrypt the message.
There are a few asymmetric providers available in the .NET Framework 3.5. Specifically, the DSACryptoServiceProvider, the RSACryptoServiceProvider, and the ECDiffieHelmanCng classes can be used for public/private key pairs. The weakness of asymmetric encryption is in processing speed. Computationally speaking, it is expensive to perform public/private key encryption.
Therefore, a common means of implementing encryption involves using both asymmetric and symmetric encryption. A “password” is randomly generated by one party of a transaction. This password is then sent to another party via public key encryption. Once decrypted with the corresponding private key, future messages (for a specified amount of time) is encrypted via a computationally cheap symmetric encryption algorithm.
By properly using symmetric and asymmetric encryption techniques, you have a great means of keeping your information secure:
* Use a random number generator to create a password.
* Use a form of asymmetric encryption to share the random password.
* Use Symmetric encryption to handle data exchange.
* Be sure to create an 'expiration date' for your password, and thus repeating these steps.
Be sure to try out different methods to determine which one (or ones) works the best for your situation. Never, ever attempt to create your own algorithm or implement your own versions of algorithms when encrypting data. The .NET Framework's classes have been thoroughly tested and are efficient. If you implement your own encryption algorithm and make a coding mistake, you have likely caused your application to be less secure.
Good luck with your cryptography!
Link to Part 1: Look Both Ways Before Crossing The Street
0 comments:
Post a Comment