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)

  • 2
    $\begingroup$ use, nonce misuse resistant scheme: AES-GCM-SIV. $\endgroup$ – kelalaka Nov 7 '20 at 8:50
  • $\begingroup$ @kelalaka That would still require storage of the IV, which is probably against the idea of this mode. $\endgroup$ – Maarten Bodewes Nov 8 '20 at 14:05
  • $\begingroup$ There's also ESSIV, which hashes the sector number with the encryption key. Should result in a unique and unpredictable to an attacker IV and doesn't require storage of the IV. $\endgroup$ – Swashbuckler Nov 8 '20 at 14:16
  • $\begingroup$ Well, you want to use the scheme on databases. This scheme has no security against the frequency attacks against the encrypted databases. For a proper answer, you may need to provide your data's frequency and the query information. This is because, some may have solutions $\endgroup$ – kelalaka Nov 8 '20 at 15:33

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.

  • 1
    $\begingroup$ Whoops, that CBC thing with non-random IV in the original answer was of course nonsense, the problem is that an adversary can guess a plaintext and then force the encryption of the same block, leaking information about other encrypted messages. This is something that is not not avoided by your scheme either, by the way (and it cannot be fully solved without using probabalistic encryption, but it can be somewhat mitigated by relying on the entire message). $\endgroup$ – Maarten Bodewes Nov 8 '20 at 14:44
  • $\begingroup$ An earlier revision also contained a reference to Bi-IGE mode (infinite garble extension). However, that seems to require a large / random IV (depending on which version of the protocol you reference). So I've removed it for now, using FPE seems to be more relevant here anyway. $\endgroup$ – Maarten Bodewes Nov 11 '20 at 11:25

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.