2

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.

Cryptographeur
  • 4,317
  • 2
  • 27
  • 40
Szotyi
  • 23
  • 3
  • 2
    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. – Stephen Touset Mar 31 '14 at 18:45

2 Answers2

3

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.

Community
  • 1
Cryptographeur
  • 4,317
  • 2
  • 27
  • 40
  • 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. – Szotyi Mar 31 '14 at 18:02
  • 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. – Cryptographeur Mar 31 '14 at 18:08
  • 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) – Cryptographeur Mar 31 '14 at 18:11
  • TCP guaranties that it won't go out of sync, so the worst that can happen that connection terminates, and a reconnection is needed. Anyways, you made it more clear for me, so I accept your answer, thank you. I'll use GCM, since that 16 byte overhead is not a big problem, and has no other drawbacks, and it's also more secure. – Szotyi Mar 31 '14 at 18:17
  • As @figlesquidge mentions, CTR is actually extremely susceptible to bit-flips. A bit flipped in a CTR ciphertext flips the bit at the same location in the plaintext. This is because the CTR construction is (put simply) $c = E(k, n \vert\vert c) \oplus m$ where $n$ is the nonce and $c$ is the block counter. – Stephen Touset Mar 31 '14 at 18:52
  • Ok, so I was thinking on this again, and not sure if I should make a new question for this, but how GCM protects against replay attack? If you send the same untouched packet again and again it will just validate it every time, no? – Szotyi Apr 01 '14 at 06:55
  • 1
    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. – Cryptographeur Apr 01 '14 at 09:02
  • 2
    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." – Szotyi Apr 01 '14 at 10:53
1

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.

camgas
  • 31
  • 1