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


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



  • 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).


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.

  • $\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 '16 at 16:28
  • $\begingroup$ @Dreadlockyx you have to balance the tradeoffs. $\endgroup$ – mikeazo May 25 '16 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 '16 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 '16 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 '16 at 17:07

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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