2

To help ensure uniqueness of IV's used in a CFB AES-256 cipher, software I know of gathers bits from various sources including the plaintext being enciphered, and runs that through an SHA-256 hash. The resulting 128 bits are used as an IV. I suppose, because CFB is used, this only occurs for the first block.

The plaintext changes over time, and is enciphered many times over its lifetime. An attacker may well have access to multiple ciphertexts of plaintexts which only differ by as little as 1 bit in 4096.

Is this likely to adversely affect the cryptographic strength of the ciphertexts by much?

Improve this question
6
  • The software is a backup application which stores deltas of hard-disk images 'in the cloud'.
    – David Bullock
    Jun 10, 2013 at 5:45
  • I am a crypto newbie and might not have expressed myself correctly. Am happy to take correction.
    – David Bullock
    Jun 10, 2013 at 5:46
  • 2
    Why are you using SHA-256 as a cipher? It's primarily a hash function. Why not AES or some other function designed as cipher?
    – CodesInChaos
    Jun 10, 2013 at 6:19
  • Correction: the cipher is AES-256. Also, I see that CFB uses the output of the last encrypted block as an IV. So that would mean that only the "initial IV" uses any private data, and then only from the initial block.
    – David Bullock
    Jun 10, 2013 at 7:19
  • 1
    I'm not able to see why you want to do this. What is the problem with generating a cryptographically-secure random IV?
    – Adi
    Jun 10, 2013 at 7:52

1 Answer 1

Reset to default
4

If your IV is derived from the plaintext, so that encrypting the same plaintext twice leads to the same IV, then you lose semantic security: someone can tell whether two plaintexts are equal by comparing the ciphertexts.

Other than that, for CFB, it is ok to use a predictable IV; what is critical is that the IV is not reused (or at least not reused for distinct messages, with the caveat above).

So a cryptographic hash of the whole plaintext, or of the plaintext plus other data, is a suitable IV as long as you don't mind exposing plaintext equality. Note that if you include data other than the plaintext (e.g. IV = hash(plaintext || moredata)), then this also exposes the equality of moredata if you have the same plaintext multiple times with different moredata.

Source: Is using a predictable IV with CFB mode safe or not? On the danger of reusing an IV, see Will varying plaintext compensate for a fixed initialisation vector?

Improve this answer
2
  • So you're not worried at all if the attacker knows the initial IV is hash(plaintext||moredata)? He can't exploit that knowledge to reduce the key-space to search for brute-force?
    – David Bullock
    Jun 10, 2013 at 13:14
  • @DavidBullock This is my understanding of the threads I cite on Cryptography. While I would recommend using the standard method, if this is impossible due to implementation constraints, a predictable IV is valid for CFB. Note that this does not apply to CBC, which requires a uniform, unpredictable IV.
    – Gilles 'SO- stop being evil'
    Jun 10, 2013 at 13:18

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .