Combining CTR and ECB modes to prevent attacks

Question

In Reusing AES-CTR Keys and IVs for File Encryption, the OP was asking about a composite encryption scheme $$C_i = E_K\left(P_i \oplus E_K\left(IV + i\right)\right)$$ which is basically just a CTR followed an ECB.

Now, while their intent was to use this for disk encryption (where the IV is just the unique (but known) location of a block on disk), this approach came with certain weaknesses due to the attack capabilities of an attacker in disk encryption theory. However, I was wondering if there are significant advantages to this CTR-then-ECB outside of necessarily a disk encryption context -- such as encrypting data in a database, for example.

Specifically, any reuse of (IV/nonce + counter) in CTR (for the same key) can trivially lead to a known-plaintext attack if the attacker knows the plaintext of any other blocks also encrypted with that (IV/nonce + counter). And not only just one (IV/nonce + counter) block, but also any "nearby" blocks belonging to those messages as well (due to counter overlap!).

However, if we encrypt with CTR-then-ECB, then the attacker will only know the plaintext of blocks if they are encrypted with the same IV+counter and also contain the same ciphertext as well. In contrast, an attacker of a CTR-only encryption scheme requires only matching IV + counter (to a known block), and an attacker of an CBC-only encryption scheme requires only matching ciphertexts (to a known block).

But is this a significant advantage, or are the probabilities involved here so minute -- especially if using random IV's -- that CTR-then-ECB fails to provide any real benefit? (for example, with AES)

Answer 1

There are a few problems that spring to mind:

1. this is a double-pass scheme, which is computationally expensive;
2. the leakage of blocks that are identical is unnecessary, there are schemes that only leak fully identical plaintext;
3. ECB mode requires padding, so you would create some overhead.

Now you could argue that 1. is not a problem on current computers. However, that would only be a good argument if there weren't any schemes out there that would present the same properties without requiring a double pass.

As for 2, there are schemes such as Format Preserving Encryption that don't leak any information other than fully identical plaintext. FPE is generally rather expensive when it comes to implementation (on the other hand, not having to store an IV is generally not a problem for large binaries as they would generally have a VARiable size). Another option is to perform a block encrypt on the index and use that as unpredictable IV for CBC mode (possibly with ciphertext stealing if you don't like the padding overhead). Existing disk encryption routines such as XTS and ESSIV have already been mentioned.

As for 3, ciphertext stealing (CTS) for ECB mode can of course be implemented, but it definitely doesn't help with ease of implementation, which would be the major benefit over other schemes (ECB is generally available in e.g. SQL, and CTR is relatively simple to implement using ECB, although I definitely would not like doing so in SQL).

Finally, if you have room for an authentication tag, then a SIV mode (such as AES-GCM-SIV) could be used to remove the need for an explicit IV. If you've got room for both then just a generic AES-GCM would make sense of course.

All in all, I think that - while the scheme has merits - there are better options out there - preferably ones that are build into the DB engine.