7
$\begingroup$

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?

Improve this question
$\endgroup$
3

1 Answer 1

Reset to default
11
$\begingroup$

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

"Safe-like" 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.

"Padlock-like" 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.

Improve this answer
$\endgroup$
5
  • 7
    $\begingroup$ Caution: for CTR and OFB to work "Padlock-like", we need to consider the IVs of the successive encryptions as not part of the ciphertext, which departs from standard convention both in practice (where IV is usually at start of ciphertext) and theory (the standard definition of a symmetric cipher for e.g. CPA security forces that plaintext is recoverable from ciphertext and key, which in turn forces CTR and OFB's IV to be part of the ciphertext). $\endgroup$
    – fgrieu ♦
    Commented Apr 23, 2021 at 11:54
  • $\begingroup$ @frgieu: Excellent point. With your permission I'll edit this into the answer. $\endgroup$
    – Daniel S
    Commented Apr 23, 2021 at 12:08
  • 1
    $\begingroup$ Please do! The best my comments can hope is being incorporated. $\endgroup$
    – fgrieu ♦
    Commented Apr 23, 2021 at 13:06
  • $\begingroup$ Thank you very much $\endgroup$
    – Gamer2015
    Commented Apr 23, 2021 at 13:18
  • $\begingroup$ @DanielShiu, you asked about what I needed it for, I'm playing around with e2ee a little. I have four parties a,b,c and s, where s represents the communication server. I have verified e2ee encryption for a&b and for b&c, i want to create it for a&c. 1. a&c do a X3DH (Signal) (s might be a mitm) 2. a sends digest of the sn to c via b: 2.1 a: sn_ab_ac -> s 2.2 s: sn_ab_ac_ss ->b 2.3 b: sn_ac_ss_bc -> s 2.4 s: sn_ac_bc -> c 2.5 c decrypts and compares 3. c sends a digest of the sn to a in a similar way. Now we might be able to verify the security number without meeting in person $\endgroup$
    – Gamer2015
    Commented Apr 23, 2021 at 14:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.