2
$\begingroup$

Consider a scenario where a message is sent encrypted and signed using public-key cryptography.

When using asymmetric encryption, you end up also using symmetric encryption if the message is large (hybrid encryption), which raises the question: is a MAC required?

I'm aware that not using a MAC when using Encrypt-then-Sign can lead to vulnerabilities such as the one described in the "Dancing on the Lip of the Volcano: Chosen Ciphertext Attacks on Apple iMessage" paper.

However, if you use Sign-then-Encrypt, are there any known attacks when not using a MAC?

Improve this question
$\endgroup$
3
  • 1
    $\begingroup$ I think if you use CBC, and don't use a MAC on the ciphertext, then you may potentially enable padding attacks as we have seen a few on TLS. $\endgroup$
    – SEJPM
    Mar 8, 2018 at 12:33
  • 5
    $\begingroup$ Look at the weaknesses of MAC-then-encrypt. They should apply to sign-then-encrypt as well. $\endgroup$
    – CodesInChaos
    Mar 8, 2018 at 13:55
  • $\begingroup$ Kind of obvious to most of us, but please consider an authenticated cipher mode such as GCM or EAX instead of a separate MAC calculation. If you use a MAC then don't forget to MAC the IV and any other data that could be authenticated (additional authenticated data or AAD). $\endgroup$
    – Maarten Bodewes ♦
    Mar 9, 2018 at 11:12

1 Answer 1

Reset to default
9
$\begingroup$

As with all things, the answer is "it depends".

If you're using a block mode with no padding (such as CTR or CTS) then you're probably fine. The ciphertext length is the plaintext length, your hashing time is a function of the known length, and you return "error" on tamper.

If you use a block mode WITH padding (CBC, ECB, etc) then you're not so fine. By using StE (or MtE) the recipient has to deal with the padding BEFORE knowing if it was a tampered message. So let's say that I'm a bad actor and I tamper with your message en route. I tamper wherever I need to tamper to mount a padding attack and observe results:

  • If you reply "padding failure" then you are a true padding oracle, and I chortle and attack you very quickly.
  • If you reply "error" sometimes in 'significantly' less time than others then you are checking the padding before starting the hash, and you have a noisy timing-based padding oracle. I smirk and attack you.
  • If you reply "error" at almost always the same rate, but some more slowly than others, then I have hit the boundary condition between your plaintext interpreted padding length and the digest's padding length. You have a whispering oracle, and I grumble and attack you anyways. For good measure I fire up a botnet and DDoS you when I'm done, because you pointlessly annoyed me.

There's no situation where you win in online scenarios.

Note that this answer didn't care if you did asymmetric signature, MAC, or just a simple digest. You processed untrusted data and leaked info via a side (or direct) channel.

In offline scenarios there's not much room for oracle attacks, so you will reliably detect an error induced in the storage layer. Huzzah?

The right answer for padded block cipher modes is always EtM. That way every tamper is rejected at the same time interval, and now the attacker is left with brute forcing for success (which is fairly improbable if your MAC is in the 128+ bit space).

To relate to the Apple problem: An asymmetric signature is a valid message authentication code (some people reserve "MAC" for excluding asymmetric signatures). The problem, as also related in Do I need to use a MAC with asymmetric encryption?, is when you don't have an association of WHO is allowed to sign the particular message. Using a HMAC/etc only changes the equation by forcing the recipient to know a priori what key will be used. Binding the public key of the expected signer a priori solves the problem similarly.

Improve this answer
$\endgroup$
1
  • $\begingroup$ Note that other operations on the message before signature verification may lead to a plaintext oracle; in that sense a padding oracle is just a specialized plaintext oracle attack. For instance, there were some interesting attacks on XML-enc that optimized beyond padding oracle attacks (and using XML-enc without authenticated cipher is very much akin to shooting yourself in the foot). $\endgroup$
    – Maarten Bodewes ♦
    Mar 9, 2018 at 11:09

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.