2
$\begingroup$

When using GCM mode decryption, is it necessary to wait for the decryption to complete, (and thus being able to see if the integrity of cipher text is OK) before beginning processing the clear text output, or is it possible to begin processing the clear text in parallel without any risk, regarding chosen cipher text and timing attacks? (Of course, I understand that the clear text would have to be discarded anyway, if the integrity of ciphertext appeared to be bad)

$\endgroup$
  • $\begingroup$ What if you receive a message that triggers a code execution bug in your early processing routine? $\endgroup$ – SEJPM Oct 5 '18 at 9:14
  • $\begingroup$ @SEJPM: Waiting for the decryption to be complete is also good at preventing exploits, is that what you point out ? Well, that's true but the code also has to validate and resist to clear text user input anyway, as the bad guy could also be the one who has the key! $\endgroup$ – Kaa Oct 5 '18 at 9:40
  • 1
    $\begingroup$ the problem with that scenario is that the bad guy does not need the key, he only needs to know the original plaintext to recover the keystream. The message will not authenticate, but that attack vector could bypass authentication $\endgroup$ – Richie Frame Oct 5 '18 at 11:23
2
$\begingroup$

TL;DR: no you should not process GCM decrypted data before the authentication tag has been verified.


GCM mode simply uses counter (CTR or SIC) mode as cipher. For the 12 byte IV you just have to create a counter by adding bytes 00000002 and start decrypting using the given key. You can see a decryption example here. It would be easy to create an example that starts at a different offset in the ciphertext / plaintext as well.

When you process the decrypted data without authentication you will expose yourself to timing attacks and plaintext oracle attacks. Any state that you keep that depends on the plaintext can be altered by an adversary; adversary can flip any bit of plaintext for unauthenticated ciphertext in CTR mode by flipping the ciphertext bit at the same offset.

How badly you are exposed depends of course on the plaintext processing used. I would not underestimate the risk though, even simple decoding of Unicode (UTF-8) characters could leak information. It could also be possible for an adversary to change the state of your service and then try to prevent rollback (e.g. by turning off the power).

You could possibly write the decrypted plaintext to a temporary file. Then you could copy the file to the final destination once the authentication has succeeded. This kind of processing can be performed without too much risk as the contents of the plaintext shouldn't influence the processing of the bytes.


Commonly this issue is sidestepped by encrypting the plaintext in chunks, verifying the authentication tag for each chunk. Note that you would need some kind of protocol to disallow reordering of the chunks - you could use the IV for that. Obviously this also requires additional space to store the authentication tag for each chunk.

And obviously these kind of changes to the protocol need to be performed during encryption; it doesn't influence existing ciphertext.


GCM mode is basically encrypt-then-MAC, where the MAC is generally faster than the CTR mode decryption. In principle it is therefore possible to verify the MAC before decryption. So in principle you could verify and then perform stream decryption, processing the bytes on the go. You would need a specialized implementation for this.

Unfortunately, passing over the same bytes twice could significantly slow down operation as well. In general you are better off trying to speed up GCM decryption in general and cache the results. You could however use this complicated scheme for memory-starved environments.

$\endgroup$
  • $\begingroup$ Beware, just because you cannot think of a way that an attacker can abuse your application of cryptography doesn't mean you're safe. The road of crypto is littered with "smart" applications of cryptography that allowed attackers to break schemes that should have been unbreakable. $\endgroup$ – Maarten Bodewes Oct 5 '18 at 13:16
  • $\begingroup$ One may also want to note that processing unauthenticated ciphertext / plaintext is the reason for efail being a thing. $\endgroup$ – SEJPM Oct 5 '18 at 17:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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