3

Lets assume for a specific situation we cannot use authenticated encryption like GCM ...

If we were to use CTR, what would you think of using a checksum on the plaintext then encrypt the whole.

The reason I don't want to use a hash is because the checksum is already presented in the plaintext protocol, and the reason I don't want to use standard authenticated ciphers is because of the extra hash size, even though it is just 16 bytes.

Thanks in advance.

Patriot
  • 3,162
  • 3
  • 20
  • 66
madz
  • 175
  • 1
  • 8

1 Answers1

8

If we were to use CTR, what would you think of using a checksum on plain text then encrypt whole.

That's a really bad idea (from a security perspective).
Here are the reasons for this:

  • Depending on your checksum, there are immediate obvious attacks on the authenticity of messages. If your checksum is CRC for example then it is linear. This means that an attacker can just compute some $\Delta$ he wants to insert into the message and also computes $\operatorname{CRC}(\Delta)$ and he can just XOR this into your message and it will be accepted as a valid message, because $\operatorname{CRC}(P)\oplus\operatorname{CRC}(\Delta)=\operatorname{CRC}(P\oplus \Delta)$. This attack was already known to be applicable to WEP.
  • A checksum is less "hardened" than a hash. A checksum doesn't even want to be a cryptographic hash and doesn't want to resist targeted attacks. They may thus expose linear behavior (see above) or other weaknesses which may allow for forgeries. Also see "Are checksums essentially non-secure versions of cryptographic hashes?" on this matter.
  • Hash-then-Encrypt is a bad idea as a composition. As you've already seen above Hash-then-Encrypt can be vulnerable if your "hash" is linear. However even if it is non-linear and the attacker can take a good guess at the message's contents, he can still compute $H(\text{oldMessage})\oplus H(\text{newMessage})$ and XOR that into your keystream (along with $\text{oldMessage}\oplus \text{newMessage}$) and he has easily achieved a message forgery. Also see "Why is plain-hash-then-encrypt not a secure MAC?" on this subject.
  • Authenticating and then encrypting is also highly discouraged. Even if your "hash" was an actual MAC, using it first on the message and then encrypting the result is less desirable. There are generic security proofs that assure that Encrypt-Then-MAC is secure and don't give the same guarantees for MAC-Then-Encrypt, so using the latter is discouraged. Also see Prof. Lindell's answer on the question "Should we MAC-then-encrypt or encrypt-then-MAC?".

OK, as asked for in the comments, let's dive a little into the attack I outlined in the first bullet point.
Let's call the ciphertext $C$, the (unknown) message $P$ and the (unknown) keystream $K$, which is internally used by the CTR mode. As you're using a stream cipher $C=M\oplus K$ (with $\oplus$ denoting bitwise XOR) is the encryption function. Note that for all choices of $A$ and $B$ you can come up with a $C$ such that $A=B\oplus C$. Now in the first step we manipulate the message $M$. So we first calculate the difference we want to see appear after decryption, let's call it $\delta$. Now we intercept $C$ and send $C'=C\oplus \delta$ onwards. Note how $C'\oplus K=M\oplus\delta$ will yield the manipulated message upon decryption. So now we split $M$ into the concatenation of the plaintext $P$ and its checksum $\operatorname{CRC}(P)$ as $P\parallel\operatorname{CRC}(P)$. Now also split $\delta=\Delta\parallel\operatorname{CRC}(\Delta)$. Now you see that you'll get $P\oplus\Delta$ upon decryption as the plaintext and $\operatorname{CRC}(P)\oplus\operatorname{CRC}(\Delta)$ as the checksum. Now as CRC is linear $\operatorname{CRC}(P)\oplus\operatorname{CRC}(\Delta)=\operatorname{CRC}(P\oplus\Delta)$ which is the valid checksum for the forged message.

SEJPM
  • 46,697
  • 9
  • 103
  • 214