1

How much would using AES-CTR like 3DES improve security?

Like so (Using a 512-bit key split into two; $K_1$ & $K_2$, and seperate nonces for all stages):

  • Encrypt plaintext $P$ with key $K_1$
  • Decrypt ciphertext $C$ with key $K_2$
  • Encrypt muddled text $M$ with key $K_1$

How much would this improve AES's security?

EDIT: After being asked to clarify my idea pseudocode (python like) is available below:

nonces = urandom(16), urandom (16), urandom(16)
key = 'legorooj'*8 # Example purposes, IRL I use Scrypt

msg = 'random message'

data1 = aes_ctr.encrypt(msg, key[:32], nonces[0])
data2 = aes_ctr.decrypt(data1, key[32:], nonces[1])
final_data = aes_ctr.encrypt(data2, key[:32], nonces [2])

Decryption would be the reverse operation of course.

Legorooj
  • 484
  • 5
  • 18

3 Answers3

3

It would not improve security at all.

For AES-CTR mode, encryption and decryption use the same algorithm: generate the key stream using the counter and then XOR the plaintext with it. Because of that, step 1 and 3 would completely cancel each other out, and you would be left with the "decryption" in step 2.

If you'd just use the first two steps then you would actually two independent keystreams. However, as they both rely on the AES algorithm then if the algorithm is broken, your scheme may still be broken as well. This is why usually that kind of construction is created with two algorithms that are rather distinct from each other.

You keep trying to "improve" a cryptographic primitive that is already considered secure. Why not try to improve one of the many problematic schemes? Preferably you would try and first understand the scheme before trying to improve it, like you tried to do for AES-CTR.

Maarten Bodewes
  • 96,351
  • 14
  • 169
  • 323
1

I assume you were thinking about changing the block cipher inside the CTR construction, i.e., instead of encrypting each counter with AES, you would encrypt with "3AES".

First, notice that 3DES normally uses three keys and not two. Three-keys 3DES has 112-bit security level, while two-keys 3DES has around 80-bit.

So, I'm assuming you want to use CTR mode with three-keys "3DES" as the block cipher.

If that's the case, then you would double the security level. If you use 128-bit AES, then you would get 256-bit security (but it would be much simpler and faster to simply use 256-bit AES). If you use 256-bit AES, then you would get 512-bit security (which is ridiculously huge and a complete waste).

The reason why it just doubles the security even though it uses three keys is due to the meet-in-the-middle attack.

Conrado
  • 6,614
  • 1
  • 30
  • 45
1

TLDR: from a theoretical standpoint counting the number of block encryptions for known plaintext attack, what's proposed increases security by less than 3 keys bits (or less assuming many messages). From a practical standpoint, what's proposed is pointless, because one layer of AES-256 is more than safe enough against all except attacks targeting the implementation rather than the crypto.

I'll assume the simplest: that the aes_ctr.encrypt and aes_ctr.decrypt considered in the question are length-preserving, and perform the exact same thing.

That previous answer considered that the nonces for the three stages are identical. It makes the first and third layers cancel entirely, because XOR used to combine plaintext and keystream is associative, commutative, and XOR with a constant is an involution. $K_1$ has no effect on the final ciphertext!

The question now clarifies that the nonces are independent, thus this cancellation occurs only if the first and third nonces happen to be equal. This occurs with probability 2-128 at each use, and detectably so. In that case, we are back to attacking only the center key $K_2$.

Independently: 5 blocks of known plaintext (80 bytes, that is like a line of text) is enough for a meet-in-the-middle attack. It builds a table of the values of the center pad XOR plaintext XOR ciphertext over 3 blocks for all values of $K_2$, then tests a value of $K_1$ with typically 4 or 6 AES block encryptions and a fetch of that table. The extra 2 known plaintext blocks allow ruling out false matches with negligibly little extra work. From the standpoint of brute force, security is improved only by a small factor (<6, thus less than 3 keys bits since 6<23) compared to a single layer. Methods exist to vastly lower the required memory.

fgrieu
  • 149,326
  • 13
  • 324
  • 622