Ngtjyty

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?

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.

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.

• 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.