1

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.

Community
  • 1
Sebastian S
  • 125
  • 6

2 Answers2

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.

e-sushi
  • 17,891
  • 12
  • 83
  • 229
user3201068
  • 701
  • 1
  • 5
  • 18
  • I forgot to say: My messages are rather short (less than 50 blocks usually) – Sebastian S Jan 02 '15 at 11:30
  • 3
    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. – yyyyyyy Jan 02 '15 at 11:32
  • 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? – Sebastian S Jan 02 '15 at 12:01
  • 2
    @SebastianS: Be warned about the birthday paradoxon. The number of messages should not exceed 2^(n/2). – Nova Jan 02 '15 at 13:00
  • @Nova Yes thank you, should have written it that way ;) – Sebastian S Jan 02 '15 at 13:02
1

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.

D.W.
  • 36,365
  • 13
  • 102
  • 187
  • 1
    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. – Sebastian S Jan 05 '15 at 08:26
  • @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.) – D.W. Jan 05 '15 at 23:18
  • 1
    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. – Sebastian S Jan 06 '15 at 00:13
  • @SebastianS, I can't understand what you are saying (your requirements do not seem to be stated very clearly, and I can't understand why you are rejecting convergent encryption), so I'm afraid I don't know how to help you. If you would like further help, I encourage you think about how to formulate your problem more precisely, and then edit the question. – D.W. Jan 06 '15 at 00:25
  • 1
    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. – Sebastian S Jan 06 '15 at 01:04
  • @SebastianS, if you have requirements on how much expansion is allowed (how much longer the ciphertext can be than the plaintext), then state that in the quesiton. Don't assume that convergent encryption cannot meet those requirements; there are certainly convergent encryption schemes with relatively small expansion. Nothing forces you to have 256 bits of expansion. Don't judge all of convergent encryption by one particular scheme with one particular set of parameters. – D.W. Jan 06 '15 at 05:18
  • 1
    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 ;) – Sebastian S Jan 06 '15 at 08:22