Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm encrypting some files using AES in CBC mode.

I'm also using file's digest (SHA-1) to check that data is decrypted correctly (so I need to store it with file).

Is it safe to use this digest as AES's IV and store it in the header of file? Or it has security issue?

share|improve this question
up vote 14 down vote accepted

By using the file's hash as IV, you also divulge the file's hash. This allows an attacker to make an exhaustive search on the file contents. It is not difficult to imagine situations where there are only a few millions or billions of possible file contents (e.g. the file contents are an encrypted SAN or password), in which case showing the data hash is an intolerable leak.

What you could use as IV is the result of HMAC over the file, using as key the same key than for encryption (or, preferably, derive both the HMAC key and the encryption key with a suitable PRF). The result would probably be quite hard to prove secure in any way, so don't do it for production; but it seems like a promising way to achieve context-free deterministic encryption.

"Context-free" means "without any memory". Some encryption modes require a random, unpredictable IV, while others just need nonces (e.g. a counter); you can obtain the former from the latter by encrypting the nonces with a block cipher, using a specific secret key for that. A counter still requires a bit of memory, which, depending on the situation, may or may not be easy to obtain. Some embedded systems would have difficulty updating a stored counter (permanent storage update draws a bit of current, a scarce resource on passive RFID systems). Since embedded systems rarely own a reliable source of randomness, they need deterministic encryption. Context-free deterministic encryption is thus an important niche functionality. Using HMAC to compute the IV for encryption may be a way to achieve that (with the important drawback of requiring a first pass on the whole file, before obtaining the IV which is need to begin encrypting it).

share|improve this answer
As a side note, if you store the HMAC-derived IV and use it as an authentication token, you do in fact have a provably secure deterministic authentaction scheme (DAE): SIV. (See the DAE paper by Rogaway and Shrimpton.) Of course, barring restrictions like the ones Thomas mentions, a standard (non-deterministic) AE scheme would be better. – Seth Sep 9 '12 at 19:24

It depends on the mode of operation. With counter mode, predictable IV's are fine. Of course, a collision in file hashes would result in easy plain-text recovery.

It's probably better to fill the high order 64-bits with the number of microseconds since the unix epoc, pad the rest of the 64-bits with random numbers and the use the low order 64-bits as the counter. It'd be pretty hard for IVs to collide in that set-up if encrypting stuff on a local PC.

With CBC they really need to be randomly selected. Predictable CBC IVs can lead to attacks, as BEAST demonstrated.

share|improve this answer
I'm using CBC but how file's hash is predictable? the attacker doesn't have original file to generate hash! – 4r1y4n Sep 8 '12 at 18:59
A predictable IV for CBC-mode is mainly a problem when the attacker can do a chosen plaintext attack (adapt the plaintext to the IV). In this case the IV depends on the (full) plaintext, so a chosen plaintext attacker has to try a while to get "good" ciphertext-IV combinations. (But I suppose a chosen plaintext attack is not really a problem for a file encryption scheme.) – Paŭlo Ebermann Sep 8 '12 at 20:08

You obviously lose semantic security when you use deterministic encryption. This means an attacker can tell if two files are identical. publishing the unencrypted hash also leaks which file you encrypted, if the attacker knows the hash from elsewhere.

You end up with something similar to convergent encryption, which has a few issues. Check the question Is Convergent Encryption really secure? for details. I recommend using this scheme only if you want the properties of convergent encryption. Use a random IV otherwise.

I also recommend using standard MACs instead of a homebrew SHA-1 construction. When using CBC it's essential to first verify the MAC, and only then attempt to decrypt the message. Else you'll probably vulnerable to padding-oracle attacks.

The easiest solution is using authenticated encryption such as AES-GCM with a random IV.

share|improve this answer

Your Answer


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.