3
$\begingroup$

Regarding reordering attacks, is CBC block cipher as vulnerable as ECB? why? If CBC can prevent reordering attacks (that is, after reordering, the decrypted plaintext will make nonsense so the receiver can detect that it must have been tampered with during transmission), why do we still need mechanisms like sequence number to prevent reordering attack?

$\endgroup$
6
$\begingroup$

CBC is almost as vulnerable to reordering attacks as ECB. Sometimes you can get garbage, but you can certainly move e.g. two blocks and know that the second block will decrypt to the same plaintext as the original.

With ECB you cannot easily change the last block if padding is used. If the last block doesn't contain correct padding then an error may be generated during decryption. With CBC this is extended to (the last part) of the first-to-last block of the ciphertext.

All this is quite useless though. To protect modes such as ECB and CBC against change you should simply add an authentication tag over the ciphertext (and IV, if that is send). If active attacks are possible then padding oracle attacks may be possible as well; an authentication tag would protect against both.

So adding an authentication tag (MAC) or using authenticated encryption (such as GCM mode) is the best way to protect the message integrity and authenticity. That way you don't have to rely on the plaintext message / padding to detect errors.


You can of course have two ways of reordering ciphertext when it comes to CBC. You can reorder the blocks in a message or reorder the messages themselves. Sequence numbers protect against the latter.

This is quite a separate issue; reordering messages can be performed regardless of which mode is used. CBC certainly won't protect against the reordering of messages.

$\endgroup$
3
$\begingroup$

In ECB and CBC, any string of blocks is a valid ciphertext. Neither one can distinguish a real ciphertext from a forged ciphertext.

An adversary can reorder blocks within a single message, and an adversary can reorder messages, and an adversary can flip bits and cut & paste and apply all kinds of implements of destruction to a ciphertext or substitute the complete works of William Shakespare, and neither ECB nor CBC nor CTR nor CFB nor OFB will make you any the wiser about it. The plaintext might be gibberish that causes your application logic to choke—but you don't want to let an adversary touch that logic. Unauthenticated data is pure evil—don't touch it!

If you want to distinguish forgeries from legitimate messages, you must use authentication. May I suggest an authenticated encryption scheme such as NaCl crypto_secretbox_xsalsa20poly1305 or AES-GCM?

The gist of the security contract is simple: sender and receiver must share a uniform random key that they keep secret from the adversary, and for each message they must choose a nonce never before or again used with that key, such as a message sequence number; in exchange, the adversary can't forge messages or learn the content of messages.

If you transmit many messages in a sequential conversation, rejecting reordering is easy: simply drop messages whose sequence numbers precede the current one on the floor. (For a bidirectional stream, maybe have one party use odd nonces and the other party use even ones.)

If you transmit many messages asynchronously in no particular order, where you pick nonces uniformly at random,* then rejecting reordering may require more work. If this is an active protocol, maybe you can use timestamps and reject messages more than (say) one second old, and remember the nonces you have already seen in the last second in order to reject those too.


* Note that nonces chosen uniformly at random are safe for NaCl crypto_secretbox_xsalsa20poly1305, but unsafe except for very small numbers of messages with AES-GCM.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy