OCB (Offset Codebook Mode) for block ciphers is a very interesting approach to solving authentication with what appears to be the absolute minimal performance impact possible (for AE under a block cipher requirement).
All the OCB versions use Gray Codes; "successive points differ (in the Hamming sense) by just one bit".
Is using some other tweak schedule somehow insecure? If so, how? What other tweak schedules would suffice?
OCB3 also appears to greatly complicate OCB1 for truly minuscule gains in performance (just a single AES operation... which is ~60 cycles... why?). Given how one such complexity lead to the break of OCB2 that seems ill-advised.
Would utilizing a HKDF involving both the key and nonce to derive all AES round keys and secrets required for OCB operation be a safe alteration to current OCB implementations?
The goal is to have the simplest possible OCB implementation from a security perspective and where setup costs are irrelevant to the design; only performance after setup matters - in which OCB cannot be matched by anything else by a wide margin.
For key commitment purposes, a CTX (a paper put that approach forward, not "context") approach will be taken such that associated-data will not be part of OCB but rather part of the key commitment: HMAC(key,nonce,AD,length,ocb_tag)
Another question: since the OCB tag will be concealed as part of the HMAC. Does this significantly improve security for OCB forgery?
