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 want to encrypt a file with AES in CBC mode (maybe another mode is better for file encryption...I don't know, but suggestions are welcome!).

What I usually do is that I first write a few random data (256 bits, just to muddy the waters), then my salt and my IV (which are both uuid4...or generated from a secure PRNG) at the beginning of the encrypted file, and then, the encrypted blocks.

I wonder if that solution is less secure than an other? Anyway, I really don't know how I could do otherwise!

share|improve this question
2  
You should use a secure PRNG not a GUID as IV. In python, use SystemRandom or os.urandom. –  CodesInChaos Jan 20 at 13:15
    
uuid version 4 is supposed to be a random uuid. The question is about the eventual loss of security when writing it at the beginning of the encrypted file. I want to know if it is potentially insecure and if there is a better way to proceed. –  SuperPython Jan 20 at 13:20
2  
The fact that it's random doesn't mean that it has proper cryptographic properties. To quote wikipedia: "The requirements of an ordinary PRNG are also satisfied by a cryptographically secure PRNG, but the reverse is not true" –  Stephane Jan 20 at 13:29
    
What's the point in adding random data at the beginning of your file ? I could understand (sort of) why you'd want to prepent a random block of data at the begining of your cleartext if you're using CBC (although it is made redundant by using a proper IV) but that's not what you're doing –  Stephane Jan 20 at 13:33
2  
1) uuid v4 is supposed to be random, but most implementations don't guarantee it's cryptographically secure. It also contains several constant, and thus non random bits. 2) salts/IVs are not secret, so storing them in the beginning of a file is secure and pretty common. 3) Using an authenticated mode is usually a good idea, but which mode fits depends on your application. 4) WTF at "muddy the waters". That makes no sense what-so-ever. –  CodesInChaos Jan 20 at 13:34
show 8 more comments

3 Answers

up vote 35 down vote accepted

Salts and IV are not the same thing; salts are for password hashing, IV are for starting up some encryption modes. Neither is meant to be secret, though; otherwise we would call them "keys". It is safe to put the IV and/or salt in file headers.

Your adding of "a few random data (256 bits, just to muddy the waters)" is the computer equivalent of sacrificing a chicken to propitiate the gods. If it takes such rituals to make you feel good, then why not; but believing that it changes anything to your actual security would be somewhat naive.

CBC mode requires a random, unpredictable IV; it is a hard requirement. Using an UUID is dangerous in several ways:

  • Only the "v4" UUID uses a PRNG.
  • Nobody guarantees that the PRNG used for UUID v4 is cryptographically strong.
  • Even if it is strong, there still are six fixed bits in the UUID (the ones which say "this is a v4 UUID"); only 122 bits are random.

CBC is not the best mode in class anymore; we found better. In particular:

  • CBC has strict requirements on IV generation (Chosen-Plaintext Attacks have been shown to be specially effective against poor IV generation).
  • CBC needs padding, and padding handling has been shown to be delicate (decryption can turn into a "padding oracle" if done improperly).
  • CBC does not ensure integrity. Usually, when you need to encrypt (for confidentiality), you also need to reliably detect hostile alterations. For that, you need a MAC. Assembling a MAC and encryption is tricky.

Newer modes solve these issues, by tolerating a simple IV (a non-repeating counter is enough), by not needing padding, and by having an integrated MAC where the integration has been done adequately. See in particular GCM and EAX.

share|improve this answer
    
Thank you! Yes, I use uuid v4...it was inspired from this page (look at "Salt Generation" but I will finally use the os.urandom (I code in Python). About "If it takes such rituals ... but believing that it changes anything to your actual security would be somewhat naive."...as I said, I know it doesn't bring anything more if my code is public, but my code is not necessarily public...and again, it costs nothing. Anyway, now that I have my answer, I don't need it anymore! –  SuperPython Jan 20 at 14:19
1  
I'd like to vote up this answer, but I can't since I don't have enough reputation for it. Sorry! I'll try to vote it up someday! –  SuperPython Jan 20 at 14:20
1  
Are you seriously suggesting I am naive to think all these chicken sacrifices have been in vain? Because it's been a rather mild winter here, actually. –  deed02392 Jan 20 at 15:58
add comment

To answer your question: yes, it is perfectly safe to write the IV at the begining of the cipher text.

I'm not sure what you're referring to when you talk about "salt" here, though: in theory, "salt" is a random value which is mixed with the clear text value before passing it through a one-way hash function. The reason why it exists is to make sure that the same input will not result in the same output in order to defend against birthday attacks as well as against per-computed hash tables.

In the case of encryption, the IV of your mode of operation should provide the same functionality.

As for what mode to pick, it depends a lot on what your requirements are: check this answer and this page which lay down several modes of operation and their advantages/disadvantages.

If you do not know the exact requirements for the final data, you should pick the mode with the most features (CWC or OCM, probably)

share|improve this answer
    
Thank you Stephane! Actually, I have a salt for generating the key that will be used on my AES cipher (the password and the salt are sent through PBKDF2). I hesitated to use the same value for the salt and the IV, but after reading that question, I preferred to have 2 different values. –  SuperPython Jan 20 at 14:07
add comment

An unencrypted, cryptographically secure hash, should in theory not provide any hints about the content of the message, as long as the message is unique. But when an eavesdropper suspects that the message is one of a finite number of known messages, they can compare the hash to the hashes of these known messages and find out that it's one of them.

Example: Let's pressume that I would have obtained an illegal copy of a copyrighted movie, and now I would want to redistribute it to you. The copyright owner is suspecting me of movie piracy, and is thus eavesdropping on our connection. They are aware of all the illegal copies circulating on the internet and obtained them themself to calculate their hashes.

When I use your encryption scheme, they could see the hashs of the files I send and compare them to the hashes of the files they have copies of. When they find out that one of my messages matches one of their hashes, they have proven with extremely high certainty that I distributed their copyrighted content even without having to crack the encryption.

Adding a salt doesn't help much, because when the salt is unencrypted, they can just recalculate the hashes of their files with the salt of each message.

Adding meaningless data to "muddy the water" before the hash isn't adding any security, because it's only security by obscurity. It won't take long for a cryptoanalyst to notice that the data can be ignored.

Conclusion: Better encrypt the hash together with the content.

share|improve this answer
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.