21
$\begingroup$

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?

Improve this question
$\endgroup$

4 Answers 4

Reset to default
23
$\begingroup$

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).

Improve this answer
$\endgroup$
2
  • 2
    $\begingroup$ 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. $\endgroup$
    – Seth
    Commented Sep 9, 2012 at 19:24
  • 2
    $\begingroup$ What do you mean by "seems like a promising way"? What would be the current best practice for context-free deterministic encryption? $\endgroup$
    – aggsol
    Commented Oct 19, 2017 at 7:16
10
$\begingroup$

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.

Improve this answer
$\endgroup$
0
4
$\begingroup$

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.

Improve this answer
$\endgroup$
2
  • $\begingroup$ I'm using CBC but how file's hash is predictable? the attacker doesn't have original file to generate hash! $\endgroup$
    – Ariyan
    Commented Sep 8, 2012 at 18:59
  • 3
    $\begingroup$ 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.) $\endgroup$
    – Paŭlo Ebermann
    Commented Sep 8, 2012 at 20:08
1
$\begingroup$

MS SQL server's "Always Encrypted" functionality uses AES-256 CBC, and they derive the IV from a HMAC-SHA256 of some content that includes the database cell to be encrypted as well as the encryption key (as well as some fixed values).

MS Doc - Data Encryption Algorithm

When using deterministic encryption: IV = HMAC-SHA-256( iv_key, cell_data ) truncated to 128 bits
iv_key = HMAC-SHA-256(CEK, "Microsoft SQL Server cell IV key" + algorithm + CEK_length)

So there is at least some one widely deployed crytosystem taking this approach.

Improve this answer
$\endgroup$
0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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