Deniability of OTR messaging

Question

I've been looking at the off-the-record messaging protocol, and there is something about its deniability property that seems strange to me.

Consider the following scenario:

In the course of an OTR conversation, Alice decides to break Bob's deniability, e.g. she wants to be able to prove to some third party that Bob indeed sent one or more of the following messages without any way for him to plausibly deny the fact.

According to the OTR protocol, Bob will publish his old MAC only as soon as he gets a positive confirmation of Alice having received his newest key by way of Alice using a newer key than the one associated with that MAC. This is so that Bob won't publish the old MAC before Alice can verify any messages in transit that are authenticated by it.

But what keeps Alice from just ignoring all of Bob's newer keys starting at a certain point in the conversation, thereby making it impossible for him to discard any old key and also to publish any of the old MAC keys? If Alice were able to prove that she indeed never enabled Bob to publish the old MAC values, wouldn't that break his deniability?

Is there some safeguard against that attack, e.g. a timeout of old keys, that encourages implementations to automatically publish any remaining old MAC keys, even if the other party never acknowledges their receipt or just leaves the conversation entirely?

Or is OTR messaging vulnerable against this (admittedly pretty specific) attack?

Answer 1

It does not break Bob's deniability since MAC keys are symmetric. Bob still has plausible deniability as Alice could have just as easily forged any message she claims was from Bob.

Also, remember that OTR uses malleable encryption (a stream cipher mode) and has a forgeability property, which makes deniability even easier for Bob.

Answer 2

While the only other answer is correct in that it does not break Bob's deniability, I want to add a few things because this question was on the first page of search results.

A variation of this attack is described in the paper Finite-State Security Analysis of OTR Version 2, section 3.2: "Attack on Strong Deniability":

An outside attacker who has control over the whole network removes the MAC key when it is sent, and re-inserts it right before it is received. A forger listening to the conversation therefore does not have access to the MAC keys, and cannot doctor any messages.

The effect is the same, whether Bob is prevented from publishing old keys or they just go missing in transit. However, the only (rather philosophical) result is that it breaks OTR's deniability claims, i.e. that anyone can produce messages which use this MAC key, because the protocol is not able to guarantee that the MAC key actually was published.

Generally speaking, this focus on "forgeability", especially this scheme of publishing MAC keys, does not seem to make much sense for deniability. Citing the paper "Deniable Authentication and Key Exchange" by Di Raimondo et al.:

If the parties can deny having exchanged a key with the other party, then the rest of the communication can also be denied.

The same paper proves the SIGMA-R protocol used in OTR to be "partially deniable". This means that even though participation cannot be denied because digital signatures are used, the identity of the communication partner as well as the contents of the following messages can. (I assume this is as long as no other proof in the form of a digital signature is delivered, which is why it is important to use MACs instead.)

tl;dr: OTR's "forgeability" has little to do with deniability and is, as far as I can tell, unecessary. Therefore any attack on this publishing of MAC keys does not matter.

Edit: I also think it should be noted that the tag is incorrect - this is about "deniable authentication", not "deniable encryption".