7
$\begingroup$

I don't fully understand the need for MAC algorithms to authenticate encrypted messages. As I understand, the standard is to send something like $\mathrm{E}(m,k) \| \mathrm{MAC}(m,k)$ where $E$ is an error-propagating block cipher, $k$ is an encryption key.

Would it not be easier simply to send $\mathrm{E}(m\|s,k)$ where $s$ is a salt shared across the system? After decryption, the receiving user can simply check that the last $\mathrm{len}(s)$ bytes of the message match $s$ to check its authenticity.

$\endgroup$
  • $\begingroup$ Which mode of operation are you using? With most modes (including ECB, CBC, CFB, OFB and CTR) there are attacks against this construction. $\endgroup$ – CodesInChaos Jul 24 '17 at 19:09
  • $\begingroup$ @Eoin : ​ One would also need to be confident that the mode of operation preserved error-propogation. ​ ​ ​ ​ $\endgroup$ – user991 Jul 25 '17 at 4:57
  • $\begingroup$ Just saying "error-propagating" is not enough. No popular unauthenticated mode of operation has the properties required to make this secure (SIV has, but it's already authenticated). $\endgroup$ – CodesInChaos Jul 25 '17 at 8:21
  • $\begingroup$ @Eoin, just a note: it's usually recommended to use a MAC of the encrypted message, i.e. send $ \mathrm{E_{k1}}(m) \| \mathrm{MAC_{k2}}(\mathrm{E_{k1}}(m)) $ (with separate keys for $ \mathrm{E} $ and $ \mathrm{MAC} $, of course) $\endgroup$ – ilkkachu Jul 25 '17 at 11:08
17
$\begingroup$

Would it not be easier simply to send $E(m||s,k)$ where s is a salt shared across the system?

Yes, that would be simpler; however, that would not (in general) be secure.

The assumption you are making is that if someone modifies the ciphertext in any way, then the last few bits of the resulting plaintext must also be modified. This is often not the case:

  • If we are using CTR mode, then someone modifying byte $i$ of the ciphertext will cause byte $i$ of the plaintext to be modified, without any other changes. So, the attacker can avoid this protection by simply limiting his changes to the first part ($len(m)$) of the ciphertext

  • If we are using CBC mode, then someone modifying block $i$ of the ciphertext will cause blocks $i$ and $i+1$ of the plaintext to be modified; assuming that attacker does not modify that last two blocks of the ciphertext, his modifications will be undetected.

$\endgroup$
  • 1
    $\begingroup$ For CBC mode it might also allow padding oracle attacks in which case not only the integrity and authenticity would be at risk but also the confidentiality of the plaintext - negating any security provided by the cipher. $\endgroup$ – Maarten Bodewes Jul 24 '17 at 23:22
  • $\begingroup$ Sorry, I should have mentioned: I was operating under the assumption that the block cipher had error-propagation. Edited. $\endgroup$ – user2972359 Jul 25 '17 at 0:54
  • 1
    $\begingroup$ OpenPGP is using this protection, it is called MDC in combination with The CFB variant. But it is just a incomplete protection in Oracle scenarios. like discussed here eprint.iacr.org/2005/033.pdf $\endgroup$ – eckes Jul 25 '17 at 5:40
  • $\begingroup$ @eckes Isn't that an encrypted hash instead of an encrypted fixed key? $\endgroup$ – CodesInChaos Jul 25 '17 at 9:14
  • $\begingroup$ @CodesInChaos yes indeed, and some salt bytes for a good measure $\endgroup$ – eckes Jul 25 '17 at 16:30

Your Answer

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

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