# Why is OCB-AES mode not becoming a standard for authenticated encryption?

The OCB mode of authenticated encryption (used for example with AES) is the fastest way to provide authenticity and confidentiality without having to strive into questions like: Encrypt then MAC, MAC then encrypt, Encrypt and MAC.

So why it is not widely used and didn't become a standard?

-
OCB is patented for commercial use in the USA. –  Thomas Dec 9 '12 at 14:08
Update: OCB is patented, but is available for non-military use –  figlesquidge Dec 11 '13 at 16:54

As D.W. mentioned, the patent on OCB really is a killer; who would want to go through the legal hassle and expense of licensing OCB, when there are free authenticated encrypted modes available.

Another, considerably more minor issue, is that OCB does not support 'Additional Authenticated Data'. This is data that both the encryptor and decryptor provide to the mode; it is used to compute the authentication tag (along with the actual encrypted message). What this allows you to do is cryptographically bind the message to the message context; not only does the receiver verify that the message was not modified, he can also verify that someone didn't cut/paste a message that was originally meant in a different context.

You don't always need that; however, if you do need it, the only way to make it work with OCB is the put a copy of the context in the plaintext (and have the receiver verify that the context in the message is, in fact, the context that he expects). This is workable, but it would be cleaner if the mode supported it directly.

Update: the newer versions of OCB support associated data natively, but the patent situation remains "messy" at least

-
OCB does allow additional authenticated data (which the author calls "associated data"); see this description of the algorithm. While including associated data would take about the same amount of time as simply including it (redundantly) in the plaintext, you do save something in terms of bandwidth/storage. –  Seth Dec 9 '12 at 23:55
OCBv1 didn't allow for associated data, but it was introduced in OCBv2. –  Stephen Touset Feb 13 '13 at 23:08
@poncho: Sorry, but downvoted because now licences are available and OCB (now at v3) supports AD. Both are good reasons for why it wasn't accepted originally, but nowadays I would argue the main reason its not used is more to do with "because we've already implemented <alternative>". Would be very happy indeed to remove downvote if corrected! :) –  figlesquidge Dec 12 '13 at 11:53
@figlesquidge Looking at AEAD modes, I came across your comment/reason for downvote. Note that as long as OCB is not completely free, it is still a killer issue. Usually cryptography is implemented in libraries, not in applications directly. It is impossible to know if implementing OCB in a library for generic use is allowed, if that library may be used for military purposes. As long as it is IP encumbered, I won't be specifying it in any standard including the one for AEAD that I'm writing at this minute. –  Maarten Bodewes Nov 5 '14 at 11:50
Agreed, I disagree with my past self. When back at desk will try and hack that vote off –  figlesquidge Nov 5 '14 at 11:53

Because OCB is patented.

And there are other good solutions for authenticated encryption that aren't patented. This makes them more suitable, in most situations. I can recommend, e.g., EAX, GCM, or CWC. EAX and GCM have been used in some standards, and AES-GCM has been standardized.

For pointers where you can learn more, read Wikipedia. And try using search on this site with the phrase "authenticated encryption".

Update: There are now free licenses available for OCB. However, they have some unusual restrictions, which some implementors have expressed concerns over (e.g., one license only applies to open-source software; another allows only non-military uses). For a detailed discussion, see the responses on this thread on the IRTF CFRG mailing list.

-

These are the shortcomings of OCB when one puts AES as the underlying block cipher- discussed in this presentation by Bernstein, Lange.

First there's suboptimal performance of AES-OCB3 (earlier authenticated ciphers such as Phelix (although broken in the nonce-reuse scenario) already beat AES-OCB3). Next AES-OCB3 is provably secure given that AES secure, but due to recent attacks on AES, it's not necessarily the case anymore. As for the security proof of AES-OCB3, it allows attack probability of $6q^2/2^{128}$, where $q$ is the number of AES block inputs: if $q$ is around $2^{60}$ the bound is far from ok. When it comes to side-channel attacks, it's not the strong point of AES and thus not for AES-OCB3. Finally, it's unclear how the OCB deals when flooding with forgeries (GCM allows discarding without decryption).

These are also some of the arguments that lead to the CAESAR authenticated cipher competition.

-
1) With AES-NI the performance of AES-OCB is great, even ChaCha12 can't compete. It's just without AES-NI that it's slow. 2) What attacks against AES are you talking about? I'm not aware of any real attacks when AES is used with a random key. 3) How is the cost of forgeries unclear? It's simply the cost of decryption. I also think forgery flood isn't that big an issue. –  CodesInChaos Feb 14 '13 at 16:19
A dedicated AE construction could clearly do better performance-wise than using AES. As for 2), what do you make out of security proofs that assume behaves securely whereas it doesn't? Anyway these are some broader arguments why OCB is not so perfect as it seems. –  wu7 Feb 14 '13 at 17:28
It's not clear to me that you can do much better given AES-NI hardware. Wouldn't be surprised if we needed new instructions for that, which will take a decade or so. 2) Most security proofs assume PRPness of AES, which related key attacks don't affect, and biclique attacks are just a minor speedup. So I don't think there should be many affected proofs. | I also don't think any of these answer why AES-OCB isn't used. People are fine with using AES, and it seems clearly better than other AES based modes. –  CodesInChaos Feb 14 '13 at 17:48
$2^{60}$ blocks = 16 exabytes. Okay, point conceded: next time I want to encrypt 16 exabytes, I'll stay away from OCB3. :) On the other hand, as long as you encrypt fewer than 16 terabytes, the bound stays comfortably below $2^{-40}$. –  Seth Feb 14 '13 at 21:06
@CodesinChaos Note that AES-NI doesn't provide instructions for full AES but rather round-wise instructions. So, a dedicated construction that recycles some of the AES operations can readily make use of the new instructions. Examples of new such new AE schemes: AEGIS and ALE, both given in DIAC workshop booklet –  wu7 Feb 15 '13 at 18:42