5

Given that we know that nonce + message + hash(nonce + message + mac-key) all inside the encryption makes it possible to detect if any bits of the message have been changed by the attacker (in essence converting a malleable cipher into a non-malleable one), why do they still say encrypt then MAC?

Furthermore, doesn't adding the mac-key that is split into pairs like the symmetric cipher authenticate the attacker by proving the rest of the material not subject to attack on the cipher is known (assuming adequate length)?

Of course if we had full asymmetric we'd sign then encrypt but that's not the question being asked.

EDIT: The encryption algorithms I prefer all have the property of not having invalid inputs, in that any ciphertext + any key -> some "plaintext", usually garbage. There cannot exist an attack on the algorithm that would crash the implementation.

EDIT: OK I get the part about HMAC not being hash(a + b) due to most hash functions being unsuitable. I prefer to replace a hash function as unsuitable for any use once it reaches the state of unsuitable for that use but no matter. I don't get the part about why we care if the ciphertext has been altered. The way my stuff is set up it is not faster to MAC before attempting decryption due to rewinding streams.

Joshua
  • 441
  • 4
  • 14
  • 3
    Hint – e-sushi Jul 22 '14 at 20:36
  • 1
    I was going to fix the grammar on the second paragraph, but I find myself wondering what it's supposed to mean. What I first though can't be it. – otus Jul 22 '14 at 21:17
  • We "care if the ciphertext has been altered" because it might be easy to modify a single ciphertext so that whether or not the decryptor rejects depends in a predictable-and-useful way on what the message was. $;$ –  Jul 22 '14 at 22:18
  • And if the decryptor can't reject? – Joshua Jul 23 '14 at 15:54
  • If the decryptor can't reject, then we "care if the ciphertext has been altered" because it might be easy to modify a single ciphertext so that whether or not it is detected that "any bits of the message have been changed by the attacker" depends in a predictable-and-useful way on what the message was. $\hspace{.68 in}$ –  Jul 23 '14 at 17:11
  • Wouldn't the plaintext MAC check catch it then? – Joshua Jul 23 '14 at 17:49
  • ... where "it" is ...? $;$ –  Jul 23 '14 at 18:22
  • Wouldn't the plaintext MAC check catch the message had been modified before somebody tried to use it? – Joshua Jul 23 '14 at 18:39
  • If the plaintext message had been modified, then a secure MAC would be overwhelmingly likely to catch that. $:$ However, there exist encryption schemes such that one can easily modify a single ciphertext so that whether or not that modifies the plaintext depends in a predictable-and-useful way on what the plaintext message was. $;;;;$ –  Jul 23 '14 at 18:53

2 Answers2

4

It has the disadvantages of any MAC-then-encrypt scheme, which I'm quoting from the linked answer below. In addition:

  • It has the property that you need both a nonce and a hash, so for equivalent security it requires more message space.

  • The nonce has to be random, so it requires strong random numbers for each message, unlike e.g. AES CTR + HMAC.

  • Doesn't work if you need deterministic encryption, for some reason.

From the link:

Does not provide any integrity on the ciphertext, since we have no way of knowing until we decrypt the message whether it was indeed authentic or spoofed.

This means that it may allow some chosen-ciphertext attacks that encrypt-then-MAC would protect from. It also means more time is wasted on incorrect messages, which could e.g. help with denial-of-service attacks.

If the cipher scheme is malleable it may be possible to alter the message to appear valid and have a valid MAC code. This is a theoretical point, of course, since practically speaking the MAC secret should provide protection.

In your scheme the nonce and ID take the place of the MAC secret, which could be weaker if the encryption is weak and the hash function isn't a strong MAC in that mode, but can't be any stronger. Still theoretical, as long as you choose a strong, unknown nonce.

Community
  • 1
otus
  • 32,132
  • 5
  • 70
  • 165
  • My scheme has both nonce and MAC secret (identifier) – Joshua Jul 22 '14 at 21:01
  • @Joshua, right, but "hash(m|k)" is not a secure MAC with all hash functions. I've updated the answer to clarify. – otus Jul 22 '14 at 21:17
  • 1
    In addition to possibly allowing chosen-ciphertext attacks, it may even be malleable. $\hspace{1.3 in}$ –  Jul 22 '14 at 21:38
  • @RickyDemer, could you explain what you mean? Beyond what MAC-then-encrypt in general allows? – otus Jul 22 '14 at 21:58
  • 1
    I mean that it might be easy to modify a single ciphertext so that whether or not the decryptor rejects depends in a predictable-and-useful way on what the message was. $:$ (That is not beyond "what MAC-then-encrypt in general allows".) $;;;;$ –  Jul 22 '14 at 22:18
4

If there exists an encryption scheme, then there exists an encryption schemes such that
one can easily modify a single ciphertext so that whether or not that modifies the decryption
result depends in a predictable-and-useful way on what the plaintext message was, such as:

The modified encryption operation outputs a zero concatenated with the original encryption algorithm's output. $\:$ If the input ciphertext is empty then the modified decryption operation gives the same output as the original decryption algorithm. $\:$ If the input ciphertext begins with a zero then the modified decryption operation outputs the original decryption algorithm's output when given the rest of the ciphertext.
If the input ciphertext begins with a one followed by a prefix-free encoding of a natural number,
then the modified decryption operation takes the output of the original decryption algorithm on the
rest of the ciphertext, appends however many (possibly zero) zeros are needed to make it longer
than the natural number, makes the [natural number]-th bit a one, and outputs that result of that.
Otherwise, the modified decryption operation outputs the original
decryption algorithm's output when given the empty ciphertext.


If MAC-then-encrypt is used with an encryption scheme which allows such ciphertext modifications
that depend in a predictable-and-useful way on the actual message component of the plaintext,
then the resulting scheme will still be malleable.

  • I can come up with some examples like this, but can't actually come up with anything that would work with the nonce there. (Assuming the nonce is large, random and private.) – otus Jul 23 '14 at 20:08
  • It's a "just do it" construction that I'll describe later. $;$ –  Jul 23 '14 at 20:15
  • otus: It's a matter of the ciphertext change didn't change the plaintext only if the plaintext is a certain value at some point. – Joshua Jul 23 '14 at 20:39
  • @otus : $:$ I just edited in an example. $;;;;$ –  Jul 23 '14 at 21:26
  • HUH what? If you insert the plaintext MAC is completely different due to being decrypted at a different offset than encrypted. – Joshua Jul 23 '14 at 23:08
  • @Joshua : $;;;$ Should your comment have "the MAC becomes" instead of "MAC is"? $:$ I can't figure out how to parse what you wrote. $;;;;;;;$ –  Jul 23 '14 at 23:11
  • Yeah becomes works there better. – Joshua Jul 23 '14 at 23:13
  • Let us continue this discussion in chat. –  Jul 23 '14 at 23:15
  • Ok, I think I get it. You are basically saying it is possible to create an encryption algorithm that allows ciphertext modifications to affect whether the message decrypts, not that you could actually forge a message with such an algorithm? – otus Jul 24 '14 at 07:46
  • @otus : $:$ If "message" means plaintext rather than ciphertext, then that's right. $\hspace{1.67 in}$ –  Jul 24 '14 at 07:58
  • Sorry, that was ambiguous, yes it's what I meant. – otus Jul 24 '14 at 08:10