0

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?

Ursa Major
  • 123
  • 5
  • Note that without the complete protocol this is a bit of a tricky question. Usually symmetric operations and asymmetric primitives are not directly mixed; it's a bit strange to require an asymmetric key if you've already shared a symmetric key. You'd probably have to agree (or wrap) the symmetric key using an additional operation if you cannot share the secret key in advance. So there seems to be an operation or two missing in the description of the protocol in your question. – Maarten Bodewes Apr 16 '16 at 10:11
  • @MaartenBodewes, example protocols where you sign the ciphertext and don't MAC it include iMessage and Signal Protocol IIRC. – SEJPM Apr 16 '16 at 10:27

2 Answers2

2

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.

SEJPM
  • 45,967
  • 7
  • 99
  • 205
  • Signature over the ciphertext is also authentication, and if we apply authentication with AE, such as AES-GCM, the MAC payload can still be replaced, as it is appending like in the case of the signature.

    As the AES-GCM also return status code, oracle attack is still there. Isn't it?

     – Ursa Major Apr 16 '16 at 12:43
  • @UrsaMajor, you could replace the MAC with AES-GCM but you won't be able to forge a valid tag unless you knew the encryption key the recipient is expecting and usually you don't. And AES-GCM only returns "decryption failed" (in theory) so an attacker doesn't learn too much (security proofs still hold if an attacker learns that decryption failed). – SEJPM Apr 16 '16 at 12:49
  • I understand that. However, the signature has a key too which the recipient can expect, and should also return unauthenticated. Why can't that suffice?

    As well, when AES-GCM returns "decryption failed", it can also be abused as an oracle.

    Thank you for your patience, I am trying to understand this.

     – Ursa Major Apr 16 '16 at 18:08
  • @UrsaMajor, yes GCM returning "decryption failed" is an oracle but this isn't an issue, because the security proofs assume that an attacker has access to such an oracle as well and as the proofs hold, access to this oracle is not a problem. And the signature is a valid solution as long as you a) enforce / know which signature to expect and b) that you expect a signature. Both points aren't always the case. Also see our canonical answer on "Sign then encrypt" – SEJPM Apr 16 '16 at 18:41
  • I think I got it. The key point is with key management. It was assumed that the key that signed had been trusted. While in AES-CTR, the key is binded by the 1st RSA, and if it is GCM, it is binded by the same. The weakness occurs with the the signing key. They made it too complex using 3 algorithms to pieced to form 1 scheme. As the signing key is on a separate system, and possibly compromised, that key can untrusted. Because the signing is untrusted and unbinded, it becomes the weak link. When it is compromised or becomes a rogue key, it becomes a spy key. – Ursa Major Apr 17 '16 at 00:03
  • If they had used RSA-OAEP or AES-GCM, it would be mitigated since it depends on the key in the RSA scheme that guards the cipher key which attackers cannot access.

    If the signature is encrypted, the key has to be trusted, and binded. It can't be simply detached and attached for IND-CCA2.

     – Ursa Major Apr 17 '16 at 00:04
  • would it correct to assert the above that it is largely a transitive key-binding trust issue? – Ursa Major Apr 20 '16 at 01:24
  • 1
    @UrsaMajor, yes. If you do not expect a specific key with a specific message, then you can always replace the signature (if you can modify that part of the message). CCA2 securely encrypting the signature would fix the issue (although you could use RSA-KEM instead of RSA-OAEP) – SEJPM Apr 20 '16 at 10:15
0

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.
Maarten Bodewes
  • 92,551
  • 13
  • 161
  • 313
  • 1
    The authentication tag is just part of the payload, as the signature case. Similar things can happen, isn't it? – Ursa Major Apr 16 '16 at 12:44