1
$\begingroup$

I want my application to have confidentiality and integrity.

Let's say I have managed to securely share an AES key between two parties in my messaging application.

The applications communicate by sending XML messages. The XML has two tags, one for the actual text message and one for the timestamp the message was sent. This is in order make sure a replay attack cannot take place.

The XML message is encrypted with the AES algorithm and then it is sent to the recipient.

Should in this scenario add message authentication? Since the key is only known by the two parties, it should be enough to provide both confidentiality and integrity.

The worst case scenario I can think of, is someone sending a random stream of characters which will be decrypted successfully in a well formed XML message with a correct timestamp, since in any other case the message will be ignored by the receiver.

$\endgroup$
1
  • 1
    $\begingroup$ What mode of operation are you using with AES? Have you considered using TLS? Your time stamp might not be enough to prevent replay attacks. The key being known by only Alice and Bob does not guarantee that a ciphertext received by Alice was created by Bob. It also does not guarantee integrity; Bob could send a ciphertext to Alice, and an adversary could flip bits of the ciphertext en route. Alice will then decrypt the ciphertext and have no idea that it was modified and that the contents are invalid. $\endgroup$
    – Ella Rose
    Commented Sep 25, 2016 at 17:45

1 Answer 1

1
$\begingroup$

Non-authenticated symmetric encryption is malleable, meaning that an attacker who intercepts an encrypted message can modify it in ways that result in (at least partially) predictable changes to the decrypted plaintext even if they do not know the encryption key.

The exact ways in which this can be done depend on the mode of operation used, but the most obvious examples are streaming modes like CTR and OFB, where simply flipping any bit of the ciphertext will flip the corresponding bit of the plaintext. Thus, an attacker who could guess a part of your encrypted XML message could manipulate it in nearly any way they like by replacing characters with different ones — replacing authorized user IDs with a different ID, changing ="false" to ="true" , altering the XML markup itself, etc.

Other non-authenticated encryption modes like CBC are malleable in less obvious ways, such that modifying the ciphertext will, as a side effect, typically garble at least some of the nearby plaintext in unpredictable ways. However, it may still be possible to modify messages encrypted using these modes, if the attacker can arrange their modifications so that the garbled parts of the resulting plaintext will be ignored by the recipient (e.g. by wrapping them in an XML comment).

The point of all this is that, if you want your encryption to be secure against active attacks (i.e. attacks that may involve the attacker constructing their own messages, possibly by modifying intercepted ones), then you need some form of message integrity protection. This can be achieved by applying a MAC on top of a traditional non-authenticated encryption mode, or by using an authenticated encryption mode that handles both confidentiality and integrity protection. You could even achieve it e.g. by digitally signing all your messages with some public-key signature scheme. But if you allow an attacker to actively send forged messages and don't have some way to detect it, they can do a lot more than just "sending a random stream of characters".

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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