# Is there a limit on the layers of encryption a file can have?

Consider symmetric GPG encryption of a given file my_file.txt. Something like (in command line)

gpg --symmetric --cipher-algo AES256 my_file.txt


After suppying the prompt with the new password, the above produces my_file.txt.gpg. I could then encrypt again:

gpg --symmetric --cipher-algo AES256 my_file.txt.gpg


(where you would want to set a different password)

And so on. Is there a limit on how many iterations of the above I can do? It seems to me there isn't, as symmetric encryption just takes a piece of text and transforms it into another, without ever asking what the piece of text is in the first place. Is this true?

• Assuming that it uses a mode that requires IV; finally, you will get out of space since every time you will have an output with increased size. Also, one might consider the same if padding is used. – kelalaka Feb 18 '19 at 10:03
• no there's not, not until you run out of harddrive space from the encryption size overhead, anyway. – user1067003 Feb 18 '19 at 12:05
• However, be warned that --all other things being equal-- encrypting a file twice with the same algorithm (and different passwords) will not significantly improve its security: because if someone can break the first layer of encryption, it's most probable that they will be able to break the second layer with the same amount of effort. – A. Hersean Feb 18 '19 at 14:53
• @A.Hersean presumably it still protects against an attacker who has managed to capture one of the passwords? – Chris H Feb 18 '19 at 16:18
• @VLAZ that depends if the passwords are ever kept together, or even in the hands of the same individual. – Chris H Feb 18 '19 at 17:41

Theoretically, there's no limit on the number of times you can encrypt a file. The output of an encryption process is again a file, which you can again pass it on to a different algorithm and get an output.

The thing is, at decryption side, it will have to be decrypted in LIFO (last in, first out) style, with the proper passwords.

For example, if your file was first encrypted with algo1 with password abcde, and then it was encrypted with algo2 with password vwxyz, then it will have to be decrypted first with algo2 (with password vwxyz), and then with algo1 (with password abcde).

This method makes sense if you're sending the keys through different media or channels. This method would be of little use if all the passwords are sent through the same channel.

• Real-world example: You are downloading a password-protected ZIP archive containing DRM-protected media files from a HTTPS url through an IPSec-encrypted network using TOR Browser. – Philipp Feb 18 '19 at 16:55
• LIFO may not be necessary. I'm sure you can design algorithms 1 and 2 where the order of encryptions does not change the resul (so encryptA(encryptB(m)) == encryptB(encryptA(m))). Now I don't think that this necessarily would decrease the encryption strength. AFAIK current algorithms do not support this. – Giacomo Alzetta Feb 18 '19 at 17:55
• @GiacomoAlzetta most stream ciphers actually work this way (if you extract stuff like initialization vectors, padding and MACs out), because they are just XORing the keystream with the plain text. – Paŭlo Ebermann Feb 18 '19 at 22:33
• Combining encryption algorithms may also not improve security; double DES exemplifies this. I imagine it's also possible to actually make the encryption weaker or introduce new attack vectors. – jpmc26 Feb 18 '19 at 23:48
• @Philipp ...that you're accessing remotely via SSH. Over WPA2-protected Wi-fi. And a VPN. And the hard drive is encrypted. And the media files are in an obscure language that you have to translate. – JesseTG Feb 19 '19 at 4:43
• So, sooner or later you will be out of space.

GnuPG uses CFB mode of operation for symmetric encryption (defined in rfc4880). The CFB mode requires an IV with 128-bit size for AES encryption and it doesn't need for a padding.

While theoretically there is no limit as pointed by the other answer; there is a practical limit due to the file size increase. For example, I've encrypted a file with size 163 bytes then the result was 213 bytes, after re-encrypting the previous the result becomes 295 bytes, 382 bytes,473 bytes,...

These bytes also includes packet of GnuPG. So, sooner or later you will be out of space.

• I was going to answer "about 2^64" times for similar concerns. – Joshua Feb 19 '19 at 3:36
• @Joshua I wrote a comment since I've didn't time. When I've come back saw that nobody did, I wrote. Long before 2^64, one will be slower since the file will become hard to manage. – kelalaka Feb 19 '19 at 7:13

It's correct that there's no limit on the number of times you can encrypt a file, but it's not necessarily the case that you must decrypt in LIFO order.

You can always be sure that LIFO decryption will work, but certain multiply encrypted files can be decrypted out of order without affecting the result (depending on which algorithms were used for encryption):

Consider encrypting the same file twice using 1 Time Pad (XOR) with different keys. You can decrypt in either order, because (A xor B) xor C == (A xor C) xor B for every bit.

(This would be a comment if I had 50 rep, feel free to edit the other answer and delete this one.)

EDIT: See this question for more details on this edge case.

• The thing is, XOR (or add mod n) with a one-time pad is pretty much the only algorithm that can be decrypted in an arbitrary order like this. – Martin Bonner supports Monica Feb 18 '19 at 14:21
• @MartinBonner What about the algorithms used for Diffie-Hellman key exchange? – Solomon Ucko Feb 18 '19 at 14:27
• @SolomonUcko Key Exchange is not encryption. What did you have in mind? – Martin Bonner supports Monica Feb 18 '19 at 17:13
• Arbitatry encryption order works for a "plain encryption" with any xor-based stream cipher. However most practical cryptosystems add additional data (IV, integrity checks etc) to the ciphertext which would break out of order decryption. – Peter Green Feb 18 '19 at 20:18
• This "answer" looks to me like it is actually a comment regarding one of the other answers, not an answer to the question... – hft Feb 18 '19 at 22:22

As many have already observed you will have a small increase in the size of your file after each level of encryption, due to the IV that needs to be added to the file after each encryption. Not really relevant.

Rather, I'd like to observe that your motivation for doing that is obviously to increase the robustness of your ciphertext against attacks, including brute-force ones. If you use a key of $n$ bits for each of $h$ levels of encryption, let's say keys $k_1, k_2, \ldots, k_h$, you maybe expect to get the robustness of one unique encryption based on one longer key of $h\times n$ bits. Theoretically speaking, it is possible to run the Meet-in-the-Middle attack, that allows an adversary to reduce the size of the key space to less than $2^{h\times n}$. A practical example is 2-DES, where the plaintext $P$ is first encrypted by a DES key (56 bits), thus obtaining a ciphertext $C'$, and then $C'$ is again encrypted by another DES key, thus obtaing the final ciphertext $C$. However, the expectation of having a size of keyspace equal to $2^112$ is wrong. The actual size will be $2^57$ because the Meet-in-the-Middle attack, that is a known-plaintext attack (meaning that the adversary knows a pair $(P, C)$), will allow the adversary to first build a table of all $2^56$ possible encryptions of $P$ (one for each potential key) and then generate all the possible decryptions of $C$ (again, one for each potential second key) and, for each of them, let's call it $C''$, check whether $C''$ is equal to some of the potential ciphertexts in the table. In case of match we got $C'' = C'$ and we have discovered the two DES keys. Total number of encryptions/decryptions will be $2^56\times 2 = 2^57$.

For similar reasons, 3-DES (three levels of DES encryption using three different keys) offers the security of a 112 bits key.