The OCB AEAD Algorithm used in this document is defined in RFC7253.
The OCB algorithm can only use block ciphers with 16-octet blocks. The initialization vector is 15 octets long. OCB authentication tags are 16 octets long.
Encryption and decryption depend on a nonce N, which must be selected as a new value for each encryption. The nonce need not be random or secret. A counter will work fine. Nonces may have any number of bits less than 128. The recommendation is to use a 96-bit nonce.
So the maximum nonce size seems to be in fact 127 bits, where 120 bits is the largest whole octet nonce size. However, the author explicitly recommends 96 bits. I think deviating from that requires some reasoning, or we should follow the recommendation.
Designs
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related.
Learn more.
It's not that I'm opposed to using 96 bits, but we're citing RFC7253 for the definition of OCB, not the original documentation. So the maximum nonce size of the algorithm we're citing is in fact 120 bits, and the recommendation of 96 bits is also not given in RFC7253 (and so I would almost argue that choosing 96 bits would require some other citation or justification). I imagine it was originally recommended as a good trade-off between size on the wire and security (though there's no justification given in the document), but the former is now actually not a consideration for us anymore, as we're deriving the nonce from a HKDF. So I don't think there's a particularly strong reason for us not to go with the maximum size.
It's not that I'm opposed to using 96 bits, but we're citing RFC7253 for the definition of OCB, not the original documentation. So the maximum nonce size of the algorithm we're citing is in fact 120 bits, and the recommendation of 96 bits is also not given in RFC7253 (and so I would almost argue that choosing 96 bits would require some other citation or justification).
While not a recommendation per-se, the test vectors are using 96 bits nonces. I expect test vectors to use reasonable parameters to be most relevant.
In any case, I think we should seek guidance and include some kind of justification.
In GCM, if you provide a nonce longer than 96 bits, it is hashed down internally to 96 bits, so it doesn't increase security. In OCB it's not the case, all 120 bits are used. That being said, given that we now have per-message keys, 96 bits shouldn't decrease security (compared to 120 bits) either. All in all, I think there should be no meaningful difference either way.
During the RFC review process some people reviewing the draft were concerned about the variable length nonce ability in OCB. At that time we co-opted the high byte of Nonce to indicate the length of nonce being used. Prior to that point in time the nonce was free to be up to 127 bits. The FAQ was likely never updated. So, the RFC version of OCB does have a max nonce length of 120 bits = 15 octets. A 12 byte nonce recommendation is purely to align with RFC 5116, but any length nonce will do as long as a nonce never repeats for the same key
I think it makes sense for openpgp to also align with RFC 5116 to ensure the crypto libraries have the support needed for OCB with OpenPGP. So that would mean using 96bit nonce.
Notably, Niels asked whether standardizing a less flexible API first would do. It wouldn't, because a) it fixes a 96-bit nonce, and b) it fixes AES-128:
On 2022-03-02 DT call we decided to stick with 120 bits; main reason was we're not aware of libraries that hard-code 96 bits, but we'd like wider feedback that this is in fact the case
I'm inclined to close this issue as resolved. @sftcd do you want to try to get some other feedback from any other outside party? if so, who? if not, can you close this?
thanks for the confirmation, @teythoon! if you don't mind sharing the source of whatever tests you've managed to complete with the new version of nettle, a simple MR to the ocb-test-vectors repo would be great. Don't worry about dependency management or anything, i can massage it as needed. Just the .c file (or rust, if that's what you're using to generate it) should be fine.
I'm afraid I don't follow. I added your test vectors as a test case in sequoia-pgp/nettle-rs@f2d6d7f0 which is not merged into main because Nettle's OCB support isn't merged either.
no worries, the pointer to your nettle-rs proposal is what i was looking for. i've just linked to your proposed test case from the ocb-test-vectors repo README, and that satisfies my needs. I'm just trying to collect all the evidence for consensus on these vectors in one place.