1
$\begingroup$

As defined in the specification of OCB, the tag depends only on the checksum (that is just the binary sum of plain blocs), so if we construct two messages that have the same sum (this is very easy to do), we can get two different ciphertexts that have exactly the same tag.

So we can easily mount a ciphertext integrity attack against OCB and the game of the semantic security can be win with a probability one (we can construct a new valid ciphertext using a previously obtained one).

What am I missing that OCB is still considered secure?

$\endgroup$

2 Answers 2

5
$\begingroup$

I finally found the problem: there is an error in the course about the OCB mode presented in Coursera Cryptography 1 (by Pr. Dan Boneh). When I consulted the official specification of the OCB mode (RFC 7253), I found that the value used for the tag construction is the number of blocks m and not 0 as presented in the course (see the figure below), otherwise the scheme becomes insecure (an integrity attack can easily be mounted against the semantic security game!).

enter image description here

$\endgroup$
4
  • 1
    $\begingroup$ You might want to share this flaw in the slides on the official forum for the course or if no such thin exists contact the lecturer to inform him about it. $\endgroup$
    – SEJPM
    Apr 5, 2017 at 9:19
  • $\begingroup$ @SEJPM The last time I pointed out a flaw there I didn't get any response, but trying does not hurt I suppose. $\endgroup$
    – Maarten Bodewes
    Apr 16, 2017 at 14:22
  • $\begingroup$ I have tried but unfortunately no response !! $\endgroup$ Apr 16, 2017 at 22:06
  • $\begingroup$ I do not understand how this resolves the original problem. The checksum is a simple XOR of the plaintext blocks. The tweak (it's not actually 3 but some other value) depends on the number of plaintext blocks. So as presented, it should be easy to construct a plaintext with the same number of blocks and the same XOR value as the original, and then the tag should be the same. So the original question remains $\endgroup$
    – eddydee123
    Dec 16, 2021 at 16:45
1
$\begingroup$

the tag depends only on the checksum (that is just the binary sum of plain blocs)

This is technically correct but overlooks a crucial point: the "plain blocs" are the plaintext obtained by decrypting the ciphertext. They are not plaintext supplied by the attacker.

OCB is an AE(AD) mode. The security model for these modes is that the attacker must not be able to submit valid ciphertext (without reference to any particular plaintext). This is not the same as the security model for MACs, which is that the attacker must not be able to submit an existential forgery, i.e. a valid tag for a plaintext chosen by the attacker.

So you are quite correct that an attacker can take a known plaintext/ciphertext pair, modify plaintext so that it XORs to the same value as the known plaintext, and it will result in the same tag when encrypted under OCB. However, the OCB ciphertext will obviously be different! And the attacker has no way to generate this different ciphertext corresponding to the modified plaintext.

This underscores an important difference between the AE(AD) modes and the Encryption+MAC paradigm: with AE(AD) the verifier must always process the entire ciphertext, even if they independently receive (what they think is) the valid plaintext (because it may have been chosen by a helpful attacker who wants to save you the trouble of doing the decryption).

Bottom line: an OCB tag is not a MAC!

(Indeed this is obvious from the specification of the AD part of OCB: AD is of course not encrypted, and therefore cannot be decrypted to feed into the tag calculation together with the plaintext. Instead AD is processed through the cipher and enters the tag calculation as ciphertext, not plaintext).

I think this is the correct answer to the question. The input into the tweak of the tag calculation, as proposed in the other answer, is a red herring.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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