I am aware of the requirement of an IV to be unique in CTR mode (Why must IV/key-pairs not be reused in CTR mode?). However I wonder if I can use an IV depending on the plaintext deterministically. This means, of course, that the whole encryption is deterministic, which is what I want.

In the following scenario:

$C_1 = ENC_{AES-CTR}(K, P_1, IV(P_1))$

$C_2 = ENC_{AES-CTR}(K, P_2, IV(P_2))$

If $P_1 = P_2$

then $C_1 = C_2$

then $C_1 \oplus C_2 = C_1 \oplus C_1 = 0$, which essentially doesn't mean anything other than $P_1 = P_2$, which we already knew, as we're talking about deterministic encryption.

The question is: Is, by definition, the use of an IV for the same plaintext a re-use? If not, will a strong hash function be suitable to derive an IV from the plaintext? (Similar question: Security of this deterministic encryption scheme)

I'd like to use SIV mode, but it's not available in neither of the different platforms involved.

Edit: Some more information about my plaintext: I want to encrypt filenames. This means the plaintext is short, might consist of known words, has little entropy and sometimes fits into a single block. As already said before, I want equal plaintext filenames to result in equal ciphertexts.

Edit 2: All information needed for decryption must be contained in the resulting ciphered filename, e.g. as a prefix. Due to length constraints on certain file systems this prefix should be as short as possible.

  • $\begingroup$ Search for BEAR, LION, LIONESS. Might be relevant $\endgroup$ Commented Jan 2, 2015 at 11:49
  • 1
    $\begingroup$ Since you'll need to publish the IV, it's essential that the derivation function is keyed. $\endgroup$ Commented Jan 2, 2015 at 16:34
  • $\begingroup$ @CodesInChaos Thanks for your advice, using HMacSha256 now. $\endgroup$ Commented Jan 3, 2015 at 13:07
  • $\begingroup$ What do you mean by SIV not available? What you're using is almost SIV. $\endgroup$ Commented Jan 6, 2015 at 8:51
  • $\begingroup$ @DmitryKhovratovich by not available I mean, I didn't find well tested libraries for Java and iOS yet. BouncyCastle will add it soon. On iOS I may consider linking against OpenSSL. $\endgroup$ Commented Jan 6, 2015 at 9:16

2 Answers 2


I cannot prove that your scheme is secure, but as far as I know, a non-cryptographic hash function would work fine as there is an infinite number of inputs to any given hash, making it impossible to bruteforce all but the shortest messages (which would be an issue for short messages, you may want to append some sort of 128-bit padding).

However, that said, 128-bit block ciphers begin to lose security after $2^{64}$ blocks, as the number of collisions increase. In CBC mode, subsequent blocks use the previous block as an IV. If two blocks have the same output, that means that the two previous blocks XORed together will equal the two plaintexts XORed together.

  • $\begingroup$ I forgot to say: My messages are rather short (less than 50 blocks usually) $\endgroup$ Commented Jan 2, 2015 at 11:30
  • 3
    $\begingroup$ Not all non-cryptographic hash functions are suitable; there are many that leak partial information about the plaintext. To be on the safe side, one would definitely use a cryptographic hash function. $\endgroup$
    – yyyyyyy
    Commented Jan 2, 2015 at 11:32
  • $\begingroup$ For example when using SHA256, would it be ok to use the first n out of 256 bits from the hash? As long as 2^n is significantly larger than the number of encrypted messages? $\endgroup$ Commented Jan 2, 2015 at 12:01
  • 2
    $\begingroup$ @SebastianS: Be warned about the birthday paradoxon. The number of messages should not exceed 2^(n/2). $\endgroup$
    – Nova
    Commented Jan 2, 2015 at 13:00
  • $\begingroup$ @Nova Yes thank you, should have written it that way ;) $\endgroup$ Commented Jan 2, 2015 at 13:02

You want convergent encryption. I recommend you use an existing scheme for convergent encryption, such as the scheme used by Tahoe-LAFS, rather than trying to invent your own. There are multiple such schemes.

See also https://tahoe-lafs.org/hacktahoelafs/drew_perttula.html.

  • 1
    $\begingroup$ No, drew pertulla isn't really it. symmetric_key = H(added_secret, plaintext) means I need the plaintext or store the per-file-key somewhere. But I will take a look at some others. $\endgroup$ Commented Jan 5, 2015 at 8:26
  • $\begingroup$ @SebastianS, I can't understand what you are saying. (If you generate the IV as a hash of the plaintext, you'll still need to store it somewhere too, so I don't understand what your requirements/objections are.) $\endgroup$
    – D.W.
    Commented Jan 5, 2015 at 23:18
  • 1
    $\begingroup$ That is correct, but an IV is meant to be public. However storing a secret key is not possible without wrapping it, which adds complexity. Edit: Of course the IV must not reveal anything. Thats why the keyed MAC comes into play, as it is designed to do such things. $\endgroup$ Commented Jan 6, 2015 at 0:13
  • 1
    $\begingroup$ I don't refuse convergent encryption in general. And I do appreciate your suggestion. But storing one key per file is in my specific situation not suitable due to limitations, I just added in the question: I need to store all information needed for decryption in the filename itself. A 256 bit key, even when wrapped without any authentication tag, would need 55 chars in base32 encoding (which I need for case-insensitive file systems). Using a 80 bit IV (enough to avoid collisions in my case) needs just 16 chars and - as I already said before - doesn't need encryption itself. $\endgroup$ Commented Jan 6, 2015 at 1:04
  • 1
    $\begingroup$ That’s why I said in my first comment, that the one suggestion made by Drew Pertulla is not suitable, but I will look at other schemes ;) $\endgroup$ Commented Jan 6, 2015 at 8:22

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.