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$ – CodesInChaos Jan 2 '15 at 11:49
  • 1
    $\begingroup$ Since you'll need to publish the IV, it's essential that the derivation function is keyed. $\endgroup$ – CodesInChaos Jan 2 '15 at 16:34
  • $\begingroup$ @CodesInChaos Thanks for your advice, using HMacSha256 now. $\endgroup$ – Sebastian S Jan 3 '15 at 13:07
  • $\begingroup$ What do you mean by SIV not available? What you're using is almost SIV. $\endgroup$ – Dmitry Khovratovich Jan 6 '15 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$ – Sebastian S Jan 6 '15 at 9:16

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$ – Sebastian S Jan 2 '15 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 Jan 2 '15 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$ – Sebastian S Jan 2 '15 at 12:01
  • 2
    $\begingroup$ @SebastianS: Be warned about the birthday paradoxon. The number of messages should not exceed 2^(n/2). $\endgroup$ – Nova Jan 2 '15 at 13:00
  • $\begingroup$ @Nova Yes thank you, should have written it that way ;) $\endgroup$ – Sebastian S Jan 2 '15 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$ – Sebastian S Jan 5 '15 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. Jan 5 '15 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$ – Sebastian S Jan 6 '15 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$ – Sebastian S Jan 6 '15 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$ – Sebastian S Jan 6 '15 at 8:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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