OCB nonce usage

Question

I've just come across this piece of code in Bouncy Castle's implementation of OCB Mode:

if (N.length > 16 || (N.length == 16 && (N[0] & 0x80) != 0))
{
            /*
             * NOTE: We don't just ignore bit 128 because it would hide from the caller the fact
             * that two nonces differing only in bit 128 are not different.
             */
            throw new IllegalArgumentException("IV must be no more than 127 bits");
}

My understanding of this check is that if the nonce is longer than 16 bytes, or the nonce is 16 bytes and the first bit of the first byte of the nonce is not 0 (assuming big endian), then an error is thrown.

Do I understand this correctly? If so, what is best practice for creating the nonce (assuming I want a full 127-bit nonce). Generate 16 random bytes and unset the first bit of the first byte?

Also, regarding the code-comment about simply ignoring the 128th bit, would it be safe to do that if the full 128-bit nonce was used (not unsetting the first bit) with an authenticated mode (or encrypt-then-mac), ensuring the integrity of the nonce?

score 3 · Accepted Answer · answered Jul 18 '14 at 19:36

You looked on version 1.49 where OCB was not fully implemented as it seems. Actually OCB uses only 120 bit nonce, the other 8 bits are encoded as described in the RFC.

Have a look at version 1.50. There OCB seems (nearly) fully implemented and an exception is raised, if the given nonce is longer than 15 bytes (source code line #158).

score 2 · Answer 2 · edited Jun 17 '20 at 08:17

I'll give another answer in case you or someone else needs to work with that version of OCB and/or Bouncy Castle.

My understanding of this check is that if the nonce is longer than 16 bytes, or the nonce is 16 bytes and the first bit of the first byte of the nonce is not 0 (assuming big endian), then an error is thrown.

Do I understand this correctly? If so, what is best practice for creating the nonce (assuming I want a full 127-bit nonce). Generate 16 random bytes and unset the first bit of the first byte?

Yes. However, if you are doing any nonce comparisons to ensure inequality, remember to compare them with the high bit unset. That's the reason they added the check, after all.

Random 127-bit nonces shouldn't collide for a reasonable number of messages, but a counter works as an OCB nonce as well, if you want an easy way to not have to worry about nonce collisions.

Also, regarding the code-comment about simply ignoring the 128th bit, would it be safe to do that if the full 128-bit nonce was used (not unsetting the first bit) with an authenticated mode (or encrypt-then-mac), ensuring the integrity of the nonce?

Integrity is not the issue. The issue is two nonces differing only in the high bit, which would lead to nonce repetition, possibly allowing the attacker to break the encryption of (some of) the messages sharing a nonce.

OCB nonce usage

2 Answers2