How to correctly implement AES in a backup application

Question

I am writing a back-up application which should have the feature of encrypting the back-up. It must encrypt file data, paths and filenames. The application is being written in C# (.NET). Target is Windows systems, but potentially also other platforms under Mono.

It seems that AES should be used with an instance of the RijndaelManaged class. The encryption and decryption functions can be given an IV, a secret key, and of course the data.

The user will get to input a password or passphrase of any length. They'll be advised to choose something reasonable, like between 8 and 50 characters. The password will be stored in some form of hash. I'm not sure yet if this will be scrypt or bcrypt or something. Even though the back-up can be decrypted with this, at least the original password will not be known.

1. Any expansion needed to get a key that AES can work with is done by AES itself, right? Or do I need to expand the input (with some secure function?) to a key length that AES accepts myself?
2. Both the IV and Key must be the same during encryption and decryption in order to succesfully decrypt the data. The key is always the same. What should the IV be?
   I am guessing that the IV could be an incrementing number, which would make the encryption still look random even when the data and key are identical, so that it leaks as little information as possible. Is this assumption right? Does that mean that a good IV would be the file ID (they all get a unique number, or at least that could be generated)?
3. A metafile is kept which maps path and file IDs to the original path and filename. For example path 1, file 3 could expand to C:\Windows\explorer.exe. This metafile will probably be plaintext, only the values (path and filenames) will be encrypted. What should the IV be for the values? Their numeric id? Or a random value that is stored somewhere in plaintext? Or can I use a fixed (hardcoded) IV?
4. Is there anything I should know when running (or attempting to run) the application in Mono? Can I rely on any sources of pseudo-randomness to have enough entropy?
5. Does AES provide integrity by default, or do I need to store a MAC (or something) of each encrypted piece of data (metadata and file data)?

If you know the answer to any of these questions, any help is much appreciated!

Answer 1

This will... not do. AES is a brick. You want a complete house. You will not know whether the construction is sturdy until the roof falls on your head.

I will answer your questions for the sake of knowledge, but, really, don't design your own crypto:

1. AES works with keys of 128, 192 or 256 bits. All key lengths are equivalent (i.e. "cannot be broken with existing technology"). Choose 128 bits if you are smart, 256 bits if you need to appease marketing people, 192 bits if you just want to look like a jerk.

2. Requirements on IV depend on the way you use AES -- the mode of operation which turns AES into something useful. As a rule, never reuse an IV with the same key. Ne-ver. Some modes only need that (unique IV), others need random, uniform IV.

3. You have used "fixed" and "IV" in the same sentence. For that you shall be flogged on the town square.

4. .NET includes System.Security.Cryptography.RNGCryptoServiceProvider, which is fine for producing crypto-quality randomness. Mono also has it. Mono's documentation claims that on Linux /dev/random will be used, with a fallback on /dev/urandom if the former is not available; fortunately, Mono source code does the smart thing and does not implement what the documentation says: instead, Mono uses /dev/urandom, and switches to /dev/random only as fallback.

5. AES is an encryption algorithm; it does confidentiality, not integrity. Some modes of operation do both. Others do not.

Of course, any sufficiently large and complex backup system will leak a lot of information everywhere (size of files, size of file names, dates and patterns of modification...) unless handled with a lot of care. This is a hard problem. By creating an encrypted volume (e.g. with TrueCrypt) and writing files to that volume, you would have at least a non-microscopic chance of evading the most common issues. And it would save you a lot of development time, too.

Answer 2

First and foremost; you should not be implementing your own crypto schemes. Yes, you're using AES, but AES is a cryptographic primitive. Try to find an existing, well tested and reviewed solution. You are probably not a trained cryptographer, and as such will likely make mistakes. In light of that disclaimer, here's what I can remember about AES:

1. If I remember correctly, you'll need to do some work to get the key to be either 128, 192 or 256b. Usually in the form of hashing, but I'd have to check this.
2. The IV should be cryptographically random.
3. Generate a unique IV for each new encryption, and store it somewhere.
4. Pass, the OS should be able to provide reasonable entropy -- Linux usually has /dev/random for this purpose.
5. AES does not provide any integrity checking by itself; as such, you'll have to implement your own integrity checking.