Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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!

share|improve this question
    
I was right there with you right up until you said "C#", and then, Oh lawd have mercy on dis poor soul. Best of luck to you. –  tylerl Jan 30 '13 at 9:43
add comment

2 Answers

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.
share|improve this answer
    
Thanks for your answer! I'm new to implementing encryption. What could I google for when looking for an existing, well tested and reviewed solution that allows me to practically encrypt(data, password)? Or perhaps a bit more complicated to provide integrity checking, but you get the idea. –  Luc Jan 28 '13 at 0:18
1  
This is good advice. Also, it is important to use a secure mode of operation, i.e. not ECB. You then provide an IV for each file, not each block - it is an initialization vector. The IV for the next block is derived from the previous block (depending on the cipher mode). For turning a password into a key, you will probably want to use a PBKDF. You also may want to use that key to encrypt a master key, encrypt individual (e.g. file keys) with that master key, and store the encrypted individual keys. –  Jan Schejbal Jan 28 '13 at 13:03
add comment

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.

share|improve this answer
    
Thanks for your answer. It's clear by now, also with the other answer, that I shouldn't implement all of this myself. But where could I find existing implementations, and how do I know they're secure and well-tested? –  Luc Jan 30 '13 at 14:56
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.