4

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?

e-sushi
  • 17,891
  • 12
  • 83
  • 229
UnlistTed
  • 43
  • 5
  • 5
    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 08 '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 08 '17 at 22:11
  • 1
    not all AES rounds are the same, the last round is different – Richie Frame Nov 09 '17 at 05: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 09 '17 at 14:41
  • 2
    AES wth 28 rounds does not exist - because AES (in contrats to Rijndael) refers to the standardized versions. – tylo Nov 09 '17 at 15:03
  • @tylo There are only 10, 12 and 14 rounds in the Rijndael specification as well. In that sense there is no difference, except that for, for instance a block size of 32 bytes that the number of rounds is always 14, independent of the key size. So anything outside those numbers is out of spec, period. – Maarten Bodewes Nov 10 '17 at 01:26
  • That for the responses, I think Poncho hit is on the head for me in the next post. This was more of an understanding of what the term "double encryption" would mean from the sense of literally doubling the strength. Yes of course 14 round AES is the largest round count, but I wasn't certain is AES256+AES256 actually delivered double encryption. Again thanks for all your replies. – UnlistTed Nov 10 '17 at 17:46
  • Regarding "double the strength", that is wrong for double encryption. Example: double DES is almost as insecure as single DES, because you can just do a meet-in-the-middle attack (well, almost. It requires a lot of space, but time complexity is very close). On the other hand, it is quite pointless to improve a system, which is practically impossible to break within the limits of humanity (w.r.t. our currently best known attacks; and AES withstood a lot of cryptanalysis over the past years). – tylo Nov 13 '17 at 12:21

2 Answers2

4

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) Camellia-256 encryption, then the resulting cipher is strong unless both AES-256 and Camellia-256 are 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.

Community
  • 1
poncho
  • 147,019
  • 11
  • 229
  • 360
  • 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 01: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
-1

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.

daniel
  • 912
  • 5
  • 15
  • there are notes in here 15.8 Combining Multiple Block Algorithms about this, but I don't know if this is a legit copy https://mrajacse.files.wordpress.com/2012/01/applied-cryptography-2nd-ed-b-schneier.pdf – daniel Nov 09 '17 at 11:27
  • 2
    '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 09 '17 at 13:38
  • @poncho even that's not certain, depending on sneaky algorithms, the order, and chosen plaintext attacks. – daniel Nov 09 '17 at 13:43
  • 3
    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 09 '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 09 '17 at 14:07
  • You're saying that if both are weak, then the combination may be weak; that doesn't contradict what I said. – poncho Nov 09 '17 at 14:12
  • I'm saying if both are weak the combination may be weaker, this contradicts what you said. – daniel Nov 09 '17 at 14:16
  • This is kinda silly. If a second round of AES encryption with a different key could weaken AES, then attackers could just do a second round of AES encryption themselves to weaken ciphertext's security. – Nat Nov 09 '17 at 14:53
  • @Nat AES has Ciphertext indistinguishability (it isn't horrid), as Schneier says " 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. " – daniel Nov 09 '17 at 14:59
  • To phrase it another way: if you single-AES-encrypt, then attackers can trivially access both the single-AES-encrypted ciphertext and that same ciphertext encrypted with any second key of their choice. If you double-AES-encrypt, then attackers have access only to the ciphertext encrypted with two keys of your choice that they don't know. There's no way in which the second scenario could be beneficial to the attacker. – Nat Nov 09 '17 at 14:59
  • Just consider the following encryption as one of the encryptions: $Enc_k(x) = x$. This one is obviously quite vulnerable. If the composition of a cipher with this one makes the other cipher more vulnerable, then the other cipher had that vulnerability on its own already. If you require both encryptions to be the same, just consider a fixed key, e.g. all-zero, and the same argument is valid. – tylo Nov 09 '17 at 15:13
  • @tylo that's a good example of the security being as strong as the strongest. The example I gave in the comments and what Schneier is talking about is when you design one to weaken the other, which can happen when we aren't specifying which algorithms are used. In these cases the security of the cascade is weaker than either on their own. – daniel Nov 09 '17 at 15:20
  • @daniel Schneier's argument points out that inner algorithms can weaken outer algorithms; however, the reverse isn't true (under the obvious caveat of the outer encryption not using knowledge unavailable to the attacker). – Nat Nov 09 '17 at 17:03
  • Actually, you might mention Schneier's argument in your answer. It's not really directly related to the question (which is about AES+AES, and Schneier's argument doesn't at-all relate to the idea that a second round of AES could weaken the first round), but the observation that inner-encryption schemes can hypothetically (though not really practically, unless you let the attacker pick a really outrageous one) weaken the outer-encryption scheme. So, AES+AES is great; but [Attacker-Chosen-Encryption]+AES could be weak. – Nat Nov 09 '17 at 17:17