1
$\begingroup$

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.

Improve this question
$\endgroup$
13
  • $\begingroup$ For AES-CTR, $\operatorname{Enc}\equiv\operatorname{Dec}$, so why make a difference in the description? Why ask if you don't understand CTR mode in the first place? What are $C$ and $M$? The output of the previous operations? Is this an assignment? $\endgroup$ – Maarten Bodewes♦ Oct 14 '19 at 22:06
  • 1
    $\begingroup$ Wait, I'm pretty sure that this is a direct copy of an assignment. I'm closing it for that reason. $\endgroup$ – Maarten Bodewes♦ Oct 14 '19 at 22:09
  • $\begingroup$ @MaartenBodewes No it isn't. I was just wondering how much more secure AES was like described above. I also need to know for performance reasons - security/time increase and all that. Could you please reopen? $\endgroup$ – Legorooj Oct 14 '19 at 22:25
  • $\begingroup$ would this be the process of encrypting the counter or encrypting the plaintext? $\endgroup$ – Richie Frame Oct 14 '19 at 22:34
  • 2
    $\begingroup$ well, with 3DES it is not done on the mode, the 3DES operation replaces the block cipher primitive $\endgroup$ – Richie Frame Oct 14 '19 at 22:46
1
$\begingroup$

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.

Improve this answer
$\endgroup$
5
  • $\begingroup$ So the security increase is minimal? Even though the key/nonce-space is doubled and tripled? $\endgroup$ – Legorooj Oct 17 '19 at 6:18
  • $\begingroup$ @Legorooj: Yes. See TLDR for something slightly more precise; or the full answer. $\endgroup$ – fgrieu♦ Oct 17 '19 at 6:19
  • $\begingroup$ Hmm. Why only three bits? I'm confused why not more. Also, I'm a bit paranoid, in case AES is broken in time - the data I'm protecting I'd like to stay protected until well into 2100 and beyond. $\endgroup$ – Legorooj Oct 17 '19 at 6:30
  • $\begingroup$ @Legorooj: because the meet-in-the-middle attack (hypothetically) succeeds with less than $2^3$ times more work (counted in AES block encryptions) than an (hypothetical) key search attack on AES-CTR with a single key. $\endgroup$ – fgrieu♦ Oct 17 '19 at 11:59
  • $\begingroup$ Ok that makes sense. Thanks! $\endgroup$ – Legorooj Oct 17 '19 at 21:42
3
$\begingroup$

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.

Improve this answer
$\endgroup$
8
  • $\begingroup$ But wouldn't doubling (or tripling) the keyspace mean that it's harder to crack? $\endgroup$ – Legorooj Oct 15 '19 at 2:43
  • $\begingroup$ Also I'd be using seperate nonces for all the encryption/decryption. Also, in response to your comment, $C$ is the result of step one, $M$ of step two. $\endgroup$ – Legorooj Oct 15 '19 at 2:46
  • $\begingroup$ Well, next time you may want to describe your protocol in full then. We cannot answer based on things you make up after the fact. Note that this is why I thought it was an assignment first, to show you that encryption and decryption are the same for CTR mode. $\endgroup$ – Maarten Bodewes♦ Oct 15 '19 at 3:01
  • $\begingroup$ I've edited my question. Would you like me to post my python implementation as well? $\endgroup$ – Legorooj Oct 15 '19 at 6:34
  • $\begingroup$ From "seperate nonces for all stages" and new comments to the question, it looks like the IVs are independent, therefore the first and third encryptions do not cancel. If the IVs are transmitted independently, I still see a meet-in-the-middle attack. But since the system is not precisely defined, it's hard to analyses (and pointless when we have AES-256). $\endgroup$ – fgrieu♦ Oct 15 '19 at 12:55
1
$\begingroup$

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.

Improve this answer
$\endgroup$
2
  • $\begingroup$ From "seperate nonces for all stages" and new comments to the question, it looks like the it is about cascaded AES-CTR, not cascaded AES used in CTR mode as assumed in this answer. $\endgroup$ – fgrieu♦ Oct 15 '19 at 12:58
  • $\begingroup$ Thanks for your answer, it's written well but I've updated my question to be clearer so everyone understands my question better. $\endgroup$ – Legorooj Oct 16 '19 at 10:02

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