20
$\begingroup$

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?

$\endgroup$
6
  • 6
    $\begingroup$ OCB is patented for commercial use in the USA. $\endgroup$
    – Thomas
    Dec 9, 2012 at 14:08
  • 2
    $\begingroup$ Update: OCB is patented, but is available for non-military use $\endgroup$ Dec 11, 2013 at 16:54
  • 1
    $\begingroup$ Expect things to change around 2021 when the patents start expiring $\endgroup$
    – Demi
    Apr 13, 2016 at 13:02
  • 1
    $\begingroup$ @figlesquidge It's available for some specific uses under a license that, among other things, prohibits military use. It also prohibits all kinds of other uses, for example commercial use in embedded systems. It's called the "non-military use" license for convenience, to identify that particular license by one of its key restrictions, not because it permits all non-military uses. $\endgroup$ May 2, 2016 at 22:36
  • 3
    $\begingroup$ UPDATE: Apparently all patents have now been abandoned. This is from Prof. Rogaway two days ago: mailarchive.ietf.org/arch/msg/cfrg/qLTveWOdTJcLn4HP3ev-vrj05Vg $\endgroup$ Mar 1, 2021 at 16:35

4 Answers 4

15
$\begingroup$

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

$\endgroup$
5
  • 7
    $\begingroup$ 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. $\endgroup$
    – Seth
    Dec 9, 2012 at 23:55
  • 1
    $\begingroup$ OCBv1 didn't allow for associated data, but it was introduced in OCBv2. $\endgroup$ Feb 13, 2013 at 23:08
  • 1
    $\begingroup$ @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! :) $\endgroup$ Dec 12, 2013 at 11:53
  • 4
    $\begingroup$ @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. $\endgroup$
    – Maarten Bodewes
    Nov 5, 2014 at 11:50
  • 3
    $\begingroup$ Agreed, I disagree with my past self. When back at desk will try and hack that vote off $\endgroup$ Nov 5, 2014 at 11:53
17
$\begingroup$

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.

$\endgroup$
2
  • $\begingroup$ The non-military license is actually three licenses, none of which permit, for example, commercial use in embedded systems. That the use is non-military is just one of the requirements that license has. $\endgroup$ May 2, 2016 at 22:35
  • $\begingroup$ I wouldn't really recommend EAX. It's really just an improvement on CCM in terms of flexibility, which itself was designed as an alternative to OCB for IEEE 802.11i (I believe). Unlike OCB or GCM, it has horrible performance issues due to requiring two passes over the plaintext rather than one. $\endgroup$
    – forest
    Jan 4, 2020 at 3:09
5
$\begingroup$

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.

$\endgroup$
5
  • 7
    $\begingroup$ 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. $\endgroup$ Feb 14, 2013 at 16:19
  • 1
    $\begingroup$ 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. $\endgroup$
    – anon2328
    Feb 14, 2013 at 17:28
  • 6
    $\begingroup$ 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. $\endgroup$ Feb 14, 2013 at 17:48
  • 4
    $\begingroup$ $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}$. $\endgroup$
    – Seth
    Feb 14, 2013 at 21:06
  • 1
    $\begingroup$ @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 $\endgroup$
    – anon2328
    Feb 15, 2013 at 18:42
1
$\begingroup$

The "OpenSSL" license for OCB allows unrestricted use of OCB mode in any work "containing or based upon" OpenSSL. Only works "unrelated to" OpenSSL are excluded. No military nor embedded exclusion, no restriction on binary-only distribution, nothing: just start with or include anything from OpenSSL and you're golden. It is, though a patent rather than a copyright license, ultimately far less restrictive about what you may do with the licensed material than the GPL and arguably even freer than the 2-clause BSD license.

Given that it is hard to see what objection anyone might have to OCB on licensing terms at this point save, perhaps, a religious one.

$\endgroup$

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.