Does AES encryption work like a padlock or like a safe? If I encrypt a plaintext p using AES-256 in GCM mode with the keys $k_1 ... k_n$ and I want to decrypt it later, can I use the keys in any order when decrypting or do I have to use the same order as when encrypting but in reverse?
If not, is there a modern symmetric encryption algorithm that lets me perform the decryption in any order?
Mode Dependency
Whether or not the order of AES encryptions matters depends on its mode of operation. I'll get to your case of GCM (Galois Counter Mode presently).
&quot;Safe-like&quot; modes
For modes such as ECB, CBC, or PFB where the plaintext contributes to the input for the actual primitive, then the order does matter.
&quot;Padlock-like&quot; modes
For some streaming modes such as CTR and OFB then the order does not matter as the XOR of streams of bits can be done in any order and so if the streams are independent of the plaintext things can be done in any order.
ETA: @fgrieu points out that such modes use an additional parameter known as an Initialisation Vector or IV and that I have implicitly assumed that these are not encrypted during the multiple encryption processes. This assumption is not consistent with implementations that simply pre-pend the IV to the ciphertext in the cryptogram, nor certain theoretical constructs. It would be more accurate to say that if $p$ is encrypted with key, IV pairs $(k_1,IV_1), (k_2,IV_2),\ldots, (k_n,IV_n)$ then the padlock property applies.
GCM Mode
Your case of GCM is interesting as it provides two cryptographic functions: confidentiality and authentication. The confidentiality part is unaffected by ordering as it is a stream like CTR that is independent of plaintext. Thus you can recover $p$ by decrypting in any order (assuming that no-one modifies any ciphertext outside of decryption). However, the authentication part does depend on the ordering and so the final decryptions and intermediate decryptions should throw up error warnings if they are done in anything other than the reverse order. Again we must specifically exclude the IVs used in GCM from encryption for the padlock property.
If you intend to ignore these authentication tags (which is always poor practice), you would be better served by using an unauthenticated method such as CTR and finding a suitable, non-integrated authentication scheme for your application. This will shorten the ciphertext as each GCM encryption adds its own authentication tag which lengthens the final message by $n$ blocks.
Additional Commentary
Generally speaking, applying multiple layers of encryption is not something that is recommended as meet-in-the-middle attacks means that the overall security is not additive. I suspect that you might be considering single-encryptor-group-decryptor scenarios and you might like to read up on ideas such as Shamir's Secret Sharing.