[throw0101d]

The next few lines are:

> It is the user’s obligation to ensure that nonces don’t repeat within a session. In settings where this is infeasible, OCB should not be used.

But earlier in that section we have:

> […] The nonce doesn’t have to be random or secret or unpredictable. It does have to be something new with each message you encrypt. A counter value will work for a nonce, and that is what is recommended. […]

* https://www.cs.ucdavis.edu/~rogaway/ocb/ocb-faq.htm#nonce

So given that GCM uses a counter ("C"), and a counter is recommended for OCB, wouldn't it be simple enough to get the equivalent (?) security more efficiently?

[tptacek]

The notion of a nonce here is the same as that in GCM. GCM nonces aren't secret and don't need to be unpredictable; in fact, because the nonce space is so small, a common engineering recommendation is to use a durable counter.

[throw0101d]

Given that OCB (appears to be?) is more computationally efficient than GCM, is there any reason why OCB shouldn't be favoured nowadays given there are no IP issues?

[tptacek]

I like OCB and dislike GCM, but GCM is very, very fast and is the de facto standard AEAD, and the runner-up is Chapoly. OCB would be a quirky choice, and maybe trickier to get in every ecosystem you develop in (I ended up writing my own back in the early days of Golang).

[upofadown]

OCB is superior to AES-GCM-SIV in every way other than nonce reuse. OCB is faster than generic GCM for any combination of hardware acceleration. OCB is also significantly better than generic GCM for nonce reuse.

GCM-SIV is not perfect for nonce reuse anyway. It reveals to the attacker that two messages are identical.