2
$\begingroup$

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.

OCB overview

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.

$\endgroup$
  • $\begingroup$ One interpretation of OCB is that authentication is handled by "PMAC on the ciphertext using the inverse tweakable PRP of the encryption part" (which is why XOR'ing the messages is OK for authentication) which requires strong tweakable block ciphers for the main data processing (and thus two XORs). $\endgroup$ – SEJPM Jan 3 at 18:56
5
$\begingroup$

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...

| improve this answer | |
$\endgroup$
  • $\begingroup$ Does the second XOR prevent the forgery? $\endgroup$ – kelalaka Jan 3 at 21:47
  • $\begingroup$ @kelalaka: of course it does; because, for each block, each second XOR xor's in a different delta; hence if they permute the ciphertext blocks, the result of the second XOR (in the decryption direction) will be distinct. And, the attacker can't adjust for it, because the delta's are secret. $\endgroup$ – poncho Jan 3 at 21:57
  • $\begingroup$ Ah, the checksum is the x-or of plaintext, right? If not, then it would not detect. $\endgroup$ – kelalaka Jan 3 at 22:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.