4
$\begingroup$

Given a stream cipher such as ChaCha20 and a MAC such as Poly1305, how do we handle data that comes in chunks in the encrypt-then-MAC scheme ?

For example, the plaintext is 530 bytes long. We read the first 512 bytes into a buffer, process this chunk, but what happens then ?

Do we

1.

  • write the ciphertext of the incoming chunk
  • update and write the MAC of this ciphertext

or

2.

  • while (incoming chunk == 512B)
    • write the ciphertext of the incoming chunk
    • update the MAC with this ciphertext
  • write the ciphertext of the last chunk with length L (<512)
  • update the mac with this ciphertext
  • write out the MAC

What about decryption ?

The goal of EtM is to be able to check the MAC before decrypting, so I think 2 is the right way of doing it, except if we just need one MAC tag at the end of the file (like with GCM).

Improve this question
$\endgroup$
0

1 Answer 1

Reset to default
3
$\begingroup$

You can do either. Though make sure you tighten up how you do the first scheme.

In the first case you are going to have multiple tags, 1 for each chunk. In the latter, you will have a single tag. If you are downloading files that are approximately 1MB, I think #2 makes sense. If you are downloading files that are 1GB or 1TB, maybe #1 makes the most sense, as you can stop the download if one of the chunks is bad.

Improve this answer
$\endgroup$
5
  • $\begingroup$ Say we have a 1TB file to encrypt with 32kB chunks. Then with 1 there would be 512MiB just for tags. Isn't that too much ? One could increase the chunk size but then one also needs to read more data before getting to the tag. $\endgroup$
    – Dreadlockyx
    May 25, 2016 at 16:28
  • $\begingroup$ @Dreadlockyx you have to balance the tradeoffs. $\endgroup$
    – mikeazo
    May 25, 2016 at 16:37
  • 1
    $\begingroup$ Note that the first scheme, as described, is not secure: it cannot detect the deletion or insertion of a valid full-length chunk into the message. This could be fixed by including the MAC of the previous chunk as associated data while computing the MAC for the next chunk. (Personally, I'd also prefer to include a chunk counter, but it's not strictly necessary.) $\endgroup$
    – Ilmari Karonen
    May 25, 2016 at 18:30
  • $\begingroup$ So you're saying that for any iteration n, the AAD should consist of the MAC of the previous ciphertext output, is that right ? $\endgroup$
    – Dreadlockyx
    May 26, 2016 at 14:00
  • 2
    $\begingroup$ @Dreadlockyx WRT 'Isn't that too much?" instead look at it as a percentage increase in size/decrease in performance. SO it really just comes down to the chunk size vs the mac size and the message size is not in the equation. $\endgroup$
    – zaph
    Aug 12, 2016 at 17:07

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.