Asymmetric algorithms
The final example makes use of both symmetric and asymmetric algorithms. Asymmetric algorithms, such as RSA and DSA, deal with two keys, the “public” and “private” keys. Together, they can help securely send data over networks, as the following scenario shows.
If I have a document that I want only you to see, I shouldn’t simply e-mail it to you. I could encrypt it using a symmetric algorithm; then if anybody grabbed it along its way, they wouldn’t be able to read it because they wouldn’t have the single key that was used to encrypt it. But neither would you. I have to somehow get you the key so that you can decrypt the document, but without risking someone else intercepting both the key and the document.
Asymmetric algorithms are the solution. The two keys that these algorithms produce have the following relationship: Anything encrypted with the public key can be decrypted only with the companion private key. So I should first ask you to send me your public key. Anyone else can grab it on its way to me, but it doesn’t matter, since that just enables them to encrypt things for you. I use your public key to encrypt the document then send it to you. You decrypt it with your private key, which is the only thing that can decrypt it, and which you have not sent over the wire.
The asymmetric algorithms are computationally expensive and slower than the symmetric ones, so we don’t want to asymmetrically encrypt everything in our online sessions. Instead, we can go back to using symmetric algorithms. As the next example shows, we merely use asymmetric encryption to encrypt the symmetric key. Then, we use symmetric encryption from that point forward.
Encrypting network data
Although it’s a simplification, the description above is pretty much what the Secure Socket Layer (SSL) does to create secure sessions between browser and server. The idea is also put into practice in Listing B and Listing C.
Listing B is a small TCP server program you can run on your own computer in one process. You can then run the client contained in Listing C in another process (i.e., use two command windows). Near the top of each listing is a comment showing how to invoke the program at the command line.
The server:
- Receives a public key from the client.
- Uses that public key to encrypt a symmetric key that can be used by both.
- Sends the encrypted symmetric key to the client.
- Sends the client a secret message encrypted with the symmetric key.
The client:
- Creates and sends a public key to the server.
- Receives an encrypted symmetric key from the server.
- Decrypts that symmetric key using its private asymmetric key.
- Receives and decrypts a secret message encrypted with the symmetric key.
Upon startup, the client creates its own instance of the RSACryptoServiceProvider class. When instantiated, the object contains strong default keys. The client needs to get the public key out of this RSA object and send it to the server. The public key is extracted using the ExportParameters method, resulting in an RSAParameters object that holds the public key. How do we send this object to the server? We can use .NET’s binary serialisation, from the System.Runtime.Serialization.Formatters.Binary namespace:
NetworkStream ns = client.GetStream();
BinaryFormatter bf = new BinaryFormatter();
bf.Serialize(ns,key); // where key is the RSAParameters object
The BinaryFormatter writes directly to streams, and in this case, it writes the serialised version of the RSAParameters to the network stream. The server receives those bytes and deserializes them into an RSAParameters object:
result = (RSAParameters)bf.Deserialize(ms);
// ms is a memory stream containing the bytes sent by client
// bf is a BinaryFormatter
Now the server creates a symmetric key and IV that both sides can use and encrypts them using the client’s public key:
symKeyEncrypted = rsa.Encrypt(symm.Key, false);
symIVEncrypted = rsa.Encrypt(symm.IV, false);
// symKeyEncrypted and symIVEncrypted are byte arrays
Unlike the symmetric providers, the asymmetric providers encrypt to a byte array, not to a stream. The byte array can then be sent to the client using the NetworkStream.
Once the client receives the encrypted versions of the symmetric key and IV, it decrypts them using its own private asymmetric key. Now both sides have an agreed-upon symmetric key and IV. From this point forward, they send each other data that is encrypted using only the symmetric key; the asymmetric algorithm has served its purpose and need not be used again.
Conclusion
We feel comfortable using the symmetric algorithms to encrypt local data. We can choose from multiple algorithms while keeping the code generic by typing them as the abstract SymmetricAlgorithm class. The algorithms make use of transformer objects to actually encrypt the data as it passes through the special CryptoStream. When we need to send the data over a wire, we first encrypt the symmetric key itself using the recipient’s public asymmetric key.
It’s important to restate in closing that encryption is just one of the services offered in the System.Security.Cryptography namespace. For instance, although the techniques in this article would guarantee that only a certain private key could decode the message encrypted with its companion public key, they do not guarantee anything about who sent the original public key; it could have been an impostor. Classes dealing with digital certificates would also have to be employed to address that risk.
