# Are there any issues to doing 2 rounds of AES128? How is the security compared to AES256?

I have a SoC with hardware AES128 encryption, which is obviously quite efficient in terms of power usage and memory used. However, we would like to have AES256 encryption (half for commercial reasons, half for post-quantum security). To achieve this, we consider:

• Using software encryption (which will be slower, use more power, and at the least require more code and hence flash space).

• Using 2 rounds of AES128 one on the other, with different keys, effectively giving us a key length of 256 bits.

I am aware that 2 round of 128 bits is not the same as 1 round of 256 bits, but as I'm not an expert, I was wondering if anyone knows about drawbacks or vulnerability introduced by such practice, and ultimately if this would be equivalent to the security brought by AES 256 (ie, take a similar amount of time to break the encryption).

Also, I use AES CTR. The planned implementation would be create 1st cypher block, XOR it with 2nd, and XOR this with the plain text.

Thanks!

• It suffers from a meet-in-the-middle attack. Read up on why we used 3DES instead of 2DES. Though if Bernstein is right quantum computers might not speed meet-in-the-middle attacks, so you'd still get 128 bits of security against QCs (If he's wrong, you get 85 bits). – CodesInChaos Jun 5 '17 at 8:17
• Xor in that case might be a safe combiner and not affected by meet in the middle. – eckes Jun 5 '17 at 9:16
• @eckes: actually, xor would most certainly be subject to MitM attacks. On the other hand, as any such attack would involve $2^{128}$ operations, it really is not of practical interest... – poncho Jun 5 '17 at 13:41
• Hm, I said it is not vulnerable since it is a secure combiner. – eckes Jun 5 '17 at 16:35

Double encryption with 128-bit AES and two different keys does not give 256-bit security. In particular, a classic Meet-in-the-Middle attack applies, with expected cost $2^{128}$ encryptions and $2^{127}$ decryptions. As is, the attack requires ridiculously large amounts of memory, but improvements (using cycle finding with distinguished points) exist that greatly reduce memory requirement. See section 5.3 on MitM in Paul C. van Oorschot and Michael J. Wiener: Parallel Collision Search with Cryptanalytic Applications (in Journal of Cryptology, January 1999, Volume 12, Issue 1).