I'm delivering shared secret with DH exchange, using a static key for signing and an ephemeral for session, so is there a point using GCM for encrypting the data, or is a simple CBC/CTR block cipher is enough?

Also, I'm not sure what's the point authenticating the encrypted data, since if it gets modified, it will produce garbage at decryption, or if adversary gains the key somehow they will be able to fake the authentication tag too.

  • 2
    $\begingroup$ It's a common misconception that modified ciphertexts produce garbage when decrypted. This is highly dependent upon the mode of encryption, and flipping bits in many commonly-used modes (e.g., CBC, CTR) has well-defined and predictable effects on the plaintext, even if the plaintext itself is unknown to the attacker. $\endgroup$ – Stephen Touset Mar 31 '14 at 18:45

Unless you are absolutely sure that you don't need to and that the cost is going to be significant then I would absolutely say you should use authenticated encryption. One reason is bit-flipping attacks - flipping a few bits at the 'right' point in your encrypted message might lead well to a message that is legal (the classic example is if someone learns your message will be of the form ??<misc secret unknown format stuff>??? Send Bob ???<more unknown stuff>??? then they can xor the 'Alice' section with Bob$\oplus$Eve).

Another example that could well affect you would be a replay attack where an old message is sent again, and because you are not authenticating the messages the server wouldn't realise. There's a nice reference somewhere to an old computer game that players managed to cheat by continuously replaying the 'Killed Beast' message, but I can't find it at the moment.

You might find this question relevant.

  • $\begingroup$ If I remember well, what you said only happens if you use the same one-time pad or IV more than once for a message, whit the same key. Also, for example changing 1 bit in AES-CBC/CTR will produce complete garbage for that block. About replay attacks, it's not a big problem in my case, the important is that the encrypted data should stay secured. Also, if I use a secret IV delivered from the shared secret too with CTR mode, and keep increasing it every packet, it will protect against this attack method. $\endgroup$ – Szotyi Mar 31 '14 at 18:02
  • $\begingroup$ Bitflipping is exactly the sort of thing you can do to CTR mode encryption. To KNOW where in the stream that is happening might be slightly more complicated, but if for whatever reason I can something about the message format you're in trouble because I can modify messages. $\endgroup$ – figlesquidge Mar 31 '14 at 18:08
  • $\begingroup$ Keeping the IV secret (non-standard implementation but not necessarily unacceptable) may work, but how about if I block or loose a message for some reason? Every future message will be out of sync and then what? You reject them all!? There are some awkward nuances to these implementation issues (which as I say, you might well be able to solve, but definitely need considering) $\endgroup$ – figlesquidge Mar 31 '14 at 18:11
  • 1
    $\begingroup$ Yeh, I realised that as well last night. I don't think gcm will help protect you from relay attacks if you already take "good enough" care of your nonces. Still, bitflipping alone should be more than enough reason to use authenticated encryption. Similar attacks exist of CBC - for the cost of one unpredictable block I can add my own appendix to your encrypted message by splicing two queries together. If I can find somewhere in your data where this bad block isn't important (eg inside an image for example- I might only damage a few pixels of it) I can attach malicious bytes to the ciphertext. $\endgroup$ – figlesquidge Apr 1 '14 at 9:02
  • 2
    $\begingroup$ Yes it is. And since GCM operates with CTR mode that doesn't need unpredictable IV, I'll use GCM with secret IV and counters that also won't let adversary block packets unnoticed. "It's not a bug, it's a feature." $\endgroup$ – Szotyi Apr 1 '14 at 10:53

One of the major advantages of GCM is the authenticated data input that you can pass. Think about headers of a message that you want authenticated but not encrypted. This is a great thing to have in many practical implementations where some data has to stay in clear but manipulating it by an attacker has serious consequences.

  • $\begingroup$ Yes I know that, if this was in my case, I wouldn't ask the question. $\endgroup$ – Szotyi Apr 2 '14 at 12:55

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.