# Is the risk of a collision for OCB mode mitigated by upping the block size of the cipher?

A paper published by Niels Furguson Collision attacks on OCB indicates that processing large amounts of data (somewhere on the order of $2^{32}$ 128 bit blocks) with a single encryption operation (same key and nonce) makes it probable that an attacker could create a modified cipher text that would generate the same tag as a the original cipher text (pass authentication) and decrypt to a different plain text.

The probability of the necessary X collision occurring

$$(m−1)^2 2^{−128}$$

appears to be related to the block size of the cipher. In the paper a 128 bit cipher (the size originally recommended in the OCB specification) was used for all the probabilities cited.

Another surprising property observed is that using larger tag lengths increases the probability of a collision occurring.

My primary question is: does using a larger bit size cipher (say 512 bits) with a small tag size (say 64 bits) decrease the probability of this collision occurring? And if so does it decrease it enough that more than $2^{32}$ blocks of data can be written with less then a $2^{-64}$ chance of message forgery?

Niels advises against the widespread use of OCB; is this the consensus throughout the cryptographic community?

• Its interesting you ask this... We pinged Ted Krovetz about supporting 256, 512 and 1024-bit block sizes for Rijndael, Threefish, Kalyna, etc. Krovetz came back with a new RFC draft that provided RESIDUE, SHIFT and MASKLEN for wider block sizes. It should be in the IETF data tracker shortly. Jack Lloyd commented the same thing and cited the same attack/paper. He was interested in larger block sizes to help avoid the collisions, too. – user10496 Jul 21 '17 at 1:28

Using a larger blocksize in a cipher will always aid in mitigating collisions.

For a practical example, take what OWASP says about key management:

If the amount of data encrypted grows beyond a certain threshold, a new key should be used. This certain threshold varies depending on the encryption algorithm used, but is typically 235 bytes (~34 gigabytes) for 64 bit block ciphers (DES, 3DES, Blowfish, RC5, ...) and 268 bytes (~ 295,147,905 terabytes) for 128 bit block ciphers (AES, TwoFish, Serpent). If encrypting with a modern cipher, this threshold is unlikely to be reached, but it should be considered when evaluating algorithms and rotation procedures.*

I think Niels' views on the use of OCB are more academic than most people who might implement such a system. The biggest reason why OCB isn't being used is because of its patent. It also didn't help that in OCBv1 it didn't allow additional authenticated data. It was later added in OCBv2, but it did hurt adoption.

To reiterate on the above, Niels presents a more academic and logical argument against the adoption of OCB, but the biggest reason why it wasn't adopted was due to the patent the author has on it.

• I am up voting this because you answered the question about increasing key size reducing the chance of collisions, however, I am not marking it as the accepted answer as you suggest that "I can't imagine having a smaller tag aids, in anyway against, against a collision. While counter intuitive the white paper explicitly states "A larger τ does not improve the security. The converse is also true." So this statement is incorrect and I don't wan't the accepted answer to contain information that could lead someone to use OCB mode in a way that reduces it security. – K3rb3ros Mar 4 '17 at 1:59
• @K3rb3ros You're right, I just reread the paper. I removed the problematic statement. – Tuxxy Mar 15 '17 at 21:50
• Note that OCBv1 was developed before associated data was even a 'thing' in mode design. Rogaway himself introduced the modern definition of AEAD security in 2002. – pg1989 Mar 15 '17 at 23:26