# “Double Encryption” using the same cipher?

When it comes to the words "double encryption", I cringe. What I see is the following scenario play out.

Someone has plain text and they encrypt it with the AES cipher using the 14 round variant, so AES256. Then they run that encrypted information, through again another 14 rounds thinking it is double encrypted.

In my mind, I think of it differently. When I think of encryption and doubling it, I believe the strength of encryption, in the case of AES, as being tied to the number of rounds through the algorithm. So in this scenario, I think of double encryption as 28 rounds through the AES cipher.

In short - AES(28 round) > AES(14 round) + AES(14 round)

I have read some whitepapers on cascading encryption, but they referred to using two different ciphers, not the same cipher twice.

Is there anyone able to shed some light on this for me?

• Changing the round count would require changes to the internals of the cipher (the key schedule). Black-Box double encryption doesn't need that. – SEJPM Nov 8 '17 at 21:41
• Hey, thanks for the response. To clarify, you mean change the round counts would require changing the implementation code, and not the cipher itself, correct? – UnlistTed Nov 8 '17 at 22:11
• not all AES rounds are the same, the last round is different – Richie Frame Nov 9 '17 at 5:14
• Are you asking about double-AES with the same key, or using an inner-key and a separate outer-key? Also what's the block mode for the first encryption step - is it ECB? – Nat Nov 9 '17 at 14:41
• AES wth 28 rounds does not exist - because AES (in contrats to Rijndael) refers to the standardized versions. – tylo Nov 9 '17 at 15:03

When I think of encryption and doubling it, I believe the strength of encryption, in the case of AES, as being tied to the number of rounds through the algorithm.

I don't believe that's the best way to think of things.

The strength of the encryption really is 'how much work does an attacker need to do to perform the attack'.

For a cipher, there are two strategies:

• We can just go through all possible key values, and see which one 'works'

• We can rely on cryptographical weaknesses within the cipher itself

Increasing the number of rounds can plausibly (not always, but in practice, appears to) make the cryptographical weaknesses within the cipher harder to exploit, but (unless increasing the number of rounds also increases the number of key bits), doesn't do anything to slow down brute force attacks (apart from a constant factor).

As far as we know, there are no known cryptographical weaknesses in AES-256 (apart from some related key attacks, typically not applicable), and so adding more rounds doesn't increase security in any meaningful sense.

Now, it would look like running the text through two separately keyed AES-256 would double the number of key bits, and so significantly increase security. However, it turns out that there is a better-than-bruce force attack; this involves encrypting the plaintext with all possible AES-256 keys, decrypting the ciphertext with all possible AES-256 keys, and then searching for a match.

Of course, the amount of work involved is ridiculous; it will never be the case that anything involving $2^{256}$ operations will be feasible; this can be shown by thermodynamics and the minimal amount of energy needed to perform any operation.

This implies that, barring a cryptographical advance that allows us to break AES-256 with significantly less than $2^{256}$ operations, it'll be safe.

Which leads us directly to the next topic:

I have read some whitepapers on cascading encryption, but they referred to using two different ciphers, not the same cipher twice.

This potential cryptographical weakness is precisely why people use distinct ciphers. There might be a weakness in AES-256 that makes the cipher significantly weaker than our current understanding; however, if we perform AES-256 encryption, and then (say) Camelia-256 encryption, then the resulting cipher is strong unless both AES-256 and Camelia-256 is weak. It is possible that there is a weakness in one of the two ciphers; it is considered far less likely that both contain weaknesses.

• Hmm, if I read it correctly it seems that AES-NI can even be used to speed up Camellia (S-box similarity). Those ciphers may be too similar to be used for combining the ciphers. Serpent is often used as second cipher as it was in the last round of the AES competition, was considered to be "build like a tank" and is rather different from AES to boot. – Maarten Bodewes Nov 10 '17 at 1:16
• @MaartenBodewes: I don't think AES-NI can significantly speed up Camellia; the AES instructions of AES-NI are "do an AES round" (4 versions) and "expand AES key schedule", all of which are too specific to be of much use when implementing Camellia. – poncho Nov 10 '17 at 13:50
• There are several sources out there that say that it is possible. There is even a Q/A about it here and there is a paper here. But anyway, if there are mathematical similarities it might be a good idea to use a different cipher - what breaks the one may break the other. That's all I was trying to communicate. – Maarten Bodewes Nov 10 '17 at 14:17

The method you laid out to double encrypt something isn't so good. Sometimes ciphers will interact strangely and could actually make that type of double encryption less secure than just using one (especially if independent keys are not used).

Here is a quote about a sneaky thing to watch out for if you are cascading algorithms, from Applied Cryptography, Second Edition 15.8 Combining Multiple Block Algorithms:

If the second algorithm is vulnerable to a chosen-plaintext attack, then the first algorithm might facilitate that attack and make the second algorithm vulnerable to a known-plaintext attack when used in a cascade. This potential attack is not limited to encryption algorithms: If you let someone else specify any algorithm which is used on your message before encryption, then you had better be sure that your encryption will withstand a chosen-plaintext attack.

The safer way to go is to create a one time pad and encrypt that, and the cipher text (OTP XOR message) and encrypt that as well. Now your encrypted message is twice as long but decoding 1/2 of your double encryption tells you nothing about the other half.

This has some implications on the equivalent number of rounds but also on the equivalent key strength. Its over my head what those implications are but I think Wikipedia's final note is wrong about them (I believe using one weak encryption does not help at all with the second). The story of 3DES is good to show why sometimes cascading the same encryption algorithm does not increase the security in the way you think it should.

• there are notes in here 15.8 Combining Multiple Block Algorithms about this, but I don't know if this is a legit copy mrajacse.files.wordpress.com/2012/01/… – daniel Nov 9 '17 at 11:27
• 'Sometimes ciphers will interact strangely and could actually make that type of double encryption less secure than just using one (especially if independent keys are not used)'; actually, it is easy to show that if independent keys are used, the combination of the two ciphers is at least as strong as the stronger of the two (however, it need not be any stronger...) – poncho Nov 9 '17 at 13:38
• @poncho even that's not certain, depending on sneaky algorithms, the order, and chosen plaintext attacks. – daniel Nov 9 '17 at 13:43
• Actually, that is certain; if we have two ciphers X and Y, where if you encrypt using X and then encrypt using Y (assuming independent keys), you get a breakable cipher, then you can break both X and Y individually; to break X (with access to an oracle that X-encrypts text with an unknown X-key), you select a random Y key, and then for any chosen plaintext, you ask the encryption oracle to X-encrypt it, you Y encrypt the resulting X-ciphertext yourself (using your random Y key), and then that's an X-Y encrypted text; you can break that. – poncho Nov 9 '17 at 14:01
• @poncho I think you are assuming your two algorithms are 'not horrid' meaning it has to have Ciphertext indistinguishability. If X is a cipher that has some known plaintext attack, and cipher Y adds 1000 known bits for every message bit, and is applied before X then you have a problem. So it is not certain that the strong cipher 'stays strong' unless you do the OTP thing or make further specifications. – daniel Nov 9 '17 at 14:07