Stripping off message authentication or signature

Question

If attackers can strip off RSA / EC / -DSA digital signature and conduct CCA on AES-CTR or CBC payload, why can't they do the same for AES-GCM?

Answer 1

If attackers can strip off RSA / EC / -DSA digital signature and conduct CCA on AES-CTR or CBC payload, why can't they do the same for AES-GCM?

The scenario, you're talking about is iMessage or Signal Protocol or other protocols which allow optionally to sign the ciphertext and thereby don't MAC it.

The problem here is a) that you could replace the signature with your own (if it is valid and required) or b) completely strip it off if it is not required, which would be considered a protocol flaw in my eyes.

The situation is different with AES-GCM because the authentication is a mandatory part of the specification. Any non-stupid implementation will return an "invalid ciphertext" if the tag is missing or just the last ciphertext block (i.e. largely unrelated), so this won't allow you to even get to decrypt the CTR stream and thereby exploit its CCA weaknesses.

Answer 2

The problem with non-authenticated symmetric cipher modes is that they are PRP's. That means that - no matter what you do to the ciphertext - you'll get a valid and unique plaintext (not considering unpadding). This means that an attacker can change (part of) the outcome of decryption by altering the ciphertext.

It can also lead to information leakage, e.g. through plaintext oracle attacks. Padding oracle attacks on CBC are probably being the biggest threat, requiring only 128 tries per byte, regardless of the cipher used.

If an authentication tag is present then it is impossible for an attacker to alter the ciphertext or - of course - the authentication tag without triggering a failure during authentication.

---

Notes:

• an authentication tag doesn't automatically protect against replay attacks;
• you'd still have to worry about properly performing GCM of course, e.g. the nonce should be a nonce and the authentication tag should use plenty of bits.