Academic Integrity: tutoring, explanations, and feedback — we don’t complete graded work or submit on a student’s behalf.

I am examining a protocol that uses CRC32 as a MAC (see note 1) the weaknesses o

ID: 652585 • Letter: I

Question

I am examining a protocol that uses CRC32 as a MAC (see note 1) the weaknesses of this method but I would nevertheless like to see if it is just weak or actually relatively easily to break.

The examined protocol has the format more or less of:

Plaintext = Headers (6 bytes) || CRC (4 bytes) || Data
Ciphertext = 3DES-CBC(Plaintext)

This is used for a Server to send a Client a message and the Client will authenticate the message by decrypting it and checking the CRC. An attacker cannot ask the Server or the Client to encrypt a message, they could predict though the plaintext from a ciphertext.

Searching about it I can see that there is an attack on SSH 1.5 that is similar. To perform the attack the format of the data is put into this format for SSH:

Plaintext = Padding (8 bytes) || Data || CRC (4 bytes)
Ciphertext = 3DES-CBC(Plaintext)

The attack is performed partially by taking advantage of the CBC encryption by changing the first block which is the 8 byte padding in order to manipulate the second 8 byte block. If I was to perform the same attack though on the examined protocol since the 4 byte CRC is split between the first and second protocol it wouldn't work.

Is there a generic attack on encrypted CRC32 when used as a MAC?

Explanation / Answer

Well, 32 bits is somewhat short, so one could just try ciphertexts.
However, there is a much better attack.

Choose M0 arbitrarily, let P be the CBC padding for Headers || CRC || M0,
and choose M1 so that CRC( M0 || P || M1 ) = CRC(M0).
Submit M0 || P || M1 to be encrypted, truncate the ciphertext to the length of
encryptions of M0, and then output the result. That will be a valid encryption of M0.


Even without chosen plaintext, one should be able to change the headers.

Let H be the headers and let CL be the first 16 bits of CRC and let L be the (bit-)length of Data.
Choose 48 bits X which are not all zero so that the CRC of [X combined with L zero bits
however the protocol does that] ends with the same 16 bits as the CRC of 48+L zero bits.
Xor the IV with [X concatenated with [the xor of the first 16 bits of the two just-mentioned CRCs.
By the affineness of CRC, the result will be a valid ciphertext
with the same Data and header H xor X.