In Rogaway's OCB mode, the offset (derived from the key) ist XOR-added twice: Once to the plaintext block, and a second time after the Encryption.
I am wondering, why the second XOR operation is necessary. The design is I believe inspired by the XEX construction introduced by DESX. In that case, the second XOR is needed to prevent a meet-in.the middle-attack, but that's not really a problem for OCB.
I am wondering, why the second XOR operation is necessary.
If it is omitted, then an arbitrary permutation of the ciphertext blocks would not modify the tag, and hence any such modification would not be detected.
In the decrypt direction, the checksum (which is what the tag depends on) is an xor of all the values generated by the AES block decryption xored with a key/nonce dependent constant (which is the xor of all the delta's, but that's not important). If you permute the ciphertext blocks, then you would perform the block decryptions (which would result in the same intermediate plaintexts, just in a different order); they would xor to the same value (xor'ed with the same key/nonce dependent constant), and so the checksum is not modified, and hence the tag is not modified.
The second XOR operations prevents this; with that second XOR, a permutation of the ciphertext blocks would alter the list of internal ciphertext blocks presented to AES (in the decrypt direction), and so alter the list of internal plaintext blocks generated by AES.
The design is I believe inspired by the XEX construction introduced by DESX.
Nope; Phil Rogaway had a concrete reason for doing what he designed...
