I've got a system with a slow data transfer channel. Transferring a message through several channels does increase the transfer speed significatnly. AES-CBC+HMAC is good except that verifying the MAC cannot be done in parallel. Encryption can be parallel by using CTR, but MAC calculation still needs to be sequential.

I looked at some AE modes like GCM, CCM, EAX, OCB, etc (actually I'm reading this document: http://www.fi.muni.cz/~xsvenda/docs/AE_comparison_ipics04.pdf ), but still cannot find one that meets all my needs. Here're the main requirements:

  1. The decryption and verifying integrity must be parallelizable.
  2. The encryption is not required to be parallelizable.
  3. The Message can be of any size. Well, at least up to 100 TBytes.
  4. When encrypting data, the message size may be unknown. So "online processing" is required for encryption.
  5. High performance is not required, because the data channel speed is the bottleneck.
  6. No patents.

It seems that GCM mode is a way to go, except that it doesn't meet the requirement #3. According to NIST 800-38D GCM supports messages only up to 2^39-256 that is ~512 GB only. However the doc I referenced before states that GCM supports online message processing (without knowing the length of the whole message). Am I missing something? Because having length limitation seems to imply inability of online processing.

  • 2
    $\begingroup$ Being online does not mean that there are no length limitations, it just means that you can perform the encryption/decryption directly - specifically without knowing the length in advance. GCM can be parallelized, but at the cost of performing additional calculations. It may be tricky to find a library that supports that. If the solution space is empty then the obvious solution is to split up the input and verify the blocks separately (with an additional authentication tag over the first authentication tag, like a hash tree). $\endgroup$
    – Maarten Bodewes
    Jul 3, 2015 at 23:09
  • $\begingroup$ Also, you state that the data channel speed is limited, but you need to handle huge messages. If you have a 100 TByte message, you need a 9 Gbps link to download it in a day (and I wouldn't call a 9 Gbps link limited). So, do you really need to be able to handle messags that large? $\endgroup$
    – poncho
    Jul 4, 2015 at 1:26
  • $\begingroup$ You want Norx: norx.io $\endgroup$ Jul 4, 2015 at 5:33
  • 2
    $\begingroup$ If you have large files, why don't you split the file into chunks and encrypt these independently? That has the added advantage that you don't need to decrypt terabytes of data, only to throw them away at the end if the MAC doesn't validate. $\endgroup$ Jul 4, 2015 at 8:08
  • $\begingroup$ Here's an overview of the round 1 CAESAR candidates and their abilities. Norx is one of them. Note: They're not considered "fully reviewed" yet (although some have a security reduction proof). $\endgroup$
    – SEJPM
    Jul 4, 2015 at 9:19

1 Answer 1


Use AES-OCB. It is patented, but now has a free license for any non-military software use. Unlike most other CAESAR candidates, OCB has been scrutinized for a while now, and meets all of your criteria other than 6 (assuming you have a good AES implementation).

If the patent is simply too much for you, then use a heavily scrutinized patent-free tweakable block cipher like Threefish in a patent-free mode like Tweakable Authenticated Encryption (TAE) mode.

But, as CodesInChaos points out, you should also break up the message into several pieces and authenticate each piece independently, so you don't waste all day downloading 100 Terabytes that you have to throw away because a single MAC tag at the end doesn't match. Remember, there are other ways to attack you than just message forgery or breach of privacy - maybe a hacker would be satisfied just wasting your time.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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