3
$\begingroup$

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.

Improve this question
$\endgroup$
5
  • 3
    $\begingroup$ That's really bad from a security perspective (WEP-level bad). I'll look the relevant sources up. About the order of operations: Should we MAC-then-encrypt or encrypt-then-MAC?. About using a hash instead of a MAC: Why is plain-hash-then-encrypt not a secure MAC?. About using a checksum instead of a hash: Are checksums essentially non-secure versions of cryptographic hashes? $\endgroup$
    – SEJPM
    Dec 19, 2016 at 22:00
  • $\begingroup$ Hi @SEJPM thank you for the comment. I studied the pages you mentioned. About the encrypt-then-mac and vice versa while the first one is more acceptable, I think for my hypothetical scenario mac-then-encrypt is better. Because like you know checksum is not strong as MAC. $\endgroup$
    – madz
    Dec 20, 2016 at 9:11
  • $\begingroup$ For the crypto.stackexchange.com/q/32988/23623 for me, It only speaks of checksum vs hash or MAC outside of encryption world. While they are right, but checksum inside encryption can be something different than checksum without encryption. While its obvious that MAC is way better than checksum, I'm looking for a proof in a practical scenario for "checksum very less secure than MAC" $\endgroup$
    – madz
    Dec 20, 2016 at 9:40
  • $\begingroup$ For "Why is plain-hash-then-encrypt not a secure MAC?" It sound the accepted answer assumes the m0 is known for stream cipher which is very unlikely for my scenario. $\endgroup$
    – madz
    Dec 20, 2016 at 9:43
  • $\begingroup$ Can you guarentee that nobody will ever get a valid message or be able to guess its contents and manipulate it such that the system's integrity is at danger? The practical example why a checksum can be trivially broken is in my answer. $\endgroup$
    – SEJPM
    Dec 20, 2016 at 9:49

1 Answer 1

Reset to default
8
$\begingroup$

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.

Improve this answer
$\endgroup$
6
  • $\begingroup$ Thank you again for the detailed explanation. I agree with the last three. But for the first one that is actually going to stop me implementing the scenario, I don't see how the attacker is able to compute CRC(P) ⊕ CRC(Δ) because he does not know about CRC(P). He can only see the CIPHER(P). Do you know any reference or detailed explanation of this kind of attack? $\endgroup$
    – madz
    Dec 20, 2016 at 19:17
  • $\begingroup$ @pendrive the attacker computes $X=\Delta\parallel\operatorname{CRC}(\Delta)$ and XORs this into the ciphertext message. This results in the $\Delta$ being applied on the plaintext and the CRC being correctly updated without knowing the original CRC. $\endgroup$
    – SEJPM
    Dec 20, 2016 at 19:19
  • $\begingroup$ There is one thing that I want you to know of. I know that MAC is totally better than CHECKSUM (otherwise there would be no MAC). I just want to know how the attack works on checksum inside the cipher. $\endgroup$
    – madz
    Dec 20, 2016 at 19:25
  • $\begingroup$ @pendrive I've added a paragraph on this attack, I hope it's clearer now. $\endgroup$
    – SEJPM
    Dec 20, 2016 at 19:38
  • $\begingroup$ OK, great explanation. I get it all now. Actually I did not know that the overall perspective of CTR is as simple as C=M⊕K . I was thinking that CTR actually mutates or substitutes plain text M. So it obviously does not follow Diffusion principle. The fact that CTR is using IV does not change anything? Is there any Stream Cipher that could do better than just a simple C=M⊕K? $\endgroup$
    – madz
    Dec 20, 2016 at 20:35

Your Answer

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

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