Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

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?

share|improve this question

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

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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