Playing with Cryptography, Part 1
Some though about cryptography and .NET
Cryptography is a fascinating subject, surely complex, but as a developer you probably have some predefined libraries in your language/environment of choice that you can use. DotNet is not an exception, so I’ve decided to create a sample repository to play a little bit with all cryptography primitives to show how easy is to use them https://github.com/alkampfergit/DotNetCoreCryptography.
This is not a tutorial, it is more a repository where I played with API to gain more confidence with .Net Core version of the API. The purpose is also to understand if you can wrap Crypto API to make them simple to use for a developer, avoiding people to use them in different ways across a same software and to make them simpler to use.
This is not a tutorial, is some experiments I’ve done with Cryptography in .NET feel free to fork and made criticism, suggestions and point out any error you spot in the code.
First of all I’d like to abstract the real algorithm used to simplify migration to a different one if it will break in the future. I do not think that 256 bit AES will be broke in the near future, but 128 bit key could be made weak by Quantum Computing so I prefer an approach where I wrap the real key/algorithm in a custom class.
Here we have a simple EncryptionKey class that wraps some symmetric key, and will create an AesEncryptionKey as default key (actually it is the only one in the code :) ). Base class allows me to specify a series of behavior that I’m expecting for a symmetric key, this allows me to swap a real implementation with another one if I decide to change it.
When I have a key, one of the problem is where to securely store it, so I’d like all my concrete keys implementations to be able to serialize the key to a simple byte array and deserialize it from there.
I prefer to do this operation myself, because I use the first byte to mark the type of key I’m using, thus providing me the ability to mix different algorithms without any risk of breaking the code. Thanks to this way of serializing stuff, it is simple to create a generic method in base class to retrieve the correct key from serialized version.
This gave me the ability to convert potentially different type of keys into a byte array and be able to deserialize them back into the correct class. EncryptionKey base class is able to read the first byte and restore the correct version of the key based on it. If I’ll need to change the algorithm I can create another concrete implementation of EncryptionKey and use a different first byte to identify it.
Once I have this ability my next question is how to store the key safely somewhere. To achieve this result I can create a simple interface called IKeyEncryptor. I’m not pretty sure of the name, but the concept is that I can encrypt the key and decrypt with the help of another object that is supposed to be secure. I started with a concept of IKeyVault, a place where I can safely store keys, but actually I’d like to explore a different strategy, once a key is encrypted it is supposed to be secure and you can store the encrypted version everywhere, because it cannot be decrypted with the original IKeyEncryptor used to encrypt it. This makes me think that I do not really need a Vault, a place where the key is stored, what I really need is some object that is capable to encrypt my key so I can store it anywhere.
This approach gives me the ability to create a super simple helper class that to encrypt stream of bytes that is extremely simple to use.. It is called SecureEncryptor and has only two super simple methods.
This interface is super simple to use, just specify source and destination Stream for encrypt and decrypt, you do not need anything else. This kind of approach leaves no decision to the user on what algorithm to use or how to manage keys, the user does not even know where the key are stored. This kind of interface is nice because leaves all complexity and risky code in just one place, the SecureEncryptor class.
If you look at SecureEncryptor class you can find that it relies on the IKeyEncryptor class to encrypt keys. This approach concentrates most of the risk into the concrete implementation of IKeyEncryptor, if you have an implementation that is super secure, you cannot decrypt keys encrypted with it and all the rest of the code is supposed to be more secure. The less decision you leave to the user of your class, the better.
This class internally encrypt stuff with a super simple approach: it generates a new key each time you encrypt a stream, then encrypt the encryption key with the help of IKeyEncryptor, and store the encrypted version of the key at the start of the encrypted stream, finally it uses the key to encrypt the original stream to the destination stream. This approach will produce a single destination encrypted stream that contains the encrypted version of the key used to encrypt the rest of the stream. To decrypt the stream you first retrieve the encrypted key from the stream, then decrypt with IKeyEncryptor, then use the decrypted key to decrypt the rest of the stream.
Here you have a simple test that shows how you can use the class.
I’ll deal with the implementation of IKeyEncryptor in a subsequent post.