[OTR-users] mpOTR: replay attacks from insiders

[Berkant Ustaoglu]

Hi,

This is one of the many directions we were not able to complete due to  
space and time restrictions. The examples you suggest are quite  
descriptive of the problems that can arise. You should consider the  
consensus as something vital for any implementation: we have not  
offered a concrete solution, but emphasized consensus importance for  
mpOTR and that security as in encryption, macs and signatures do not  
necessarily imply consensus.

A more personal answer regarding your question "Which order  
fingerprint is chosen?". OTR I think is satisfying a quite a few  
folks. So when two parties are concerned as in your example mpOTR  
should at least provide OTR result. The interesting part to  
design/decide is when you have Charlie contributing to the messages.  
KleeQ (reference [18]) has some worthy things to add on the issue. I  
think relative counters must somehow be used. Alice has a counter she  
increases with every message, but also uses Bob's and  Charlie's  
counters to indicate what she thinks she responds to. So Alice won't  
accept a replayed message (counter is part of the message) from Bob  
because Bob's counter will say "I'm responding to your first  
question.". However, the feasibility of that approach is somewhat  
questionable since counters may get the message length a bit too long.

Your otr-user list alternative is to send us directly your questions  
and comments.

Best

Berkant

Quoting "Christoph A." <casmls at gmail.com>:

> On 08/29/2010 10:46 PM, Gregory Maxwell wrote:
>>> If I understand AuthSend() - defined in algorithm 5 - correctly, it does
>>> not contain any counter that would prevent such a replay attack.
>>> Is that correct or did I miss something that prevents already such an
>>> attack? (beside the consensus check in shutdown())
>>
>>
>> I initially replied "The consensus check" but then saw you mentioned that.
>>
>> I'm not an mpOTR designer, so perhaps there is some other protection
>> there that I'm missing... But this was how I understood the operation
>> of the protocol.  Do you think that the consensus check is inadequate?
>
> A replay-proof signature would prevent the attack from
> happening/succeeding in the first place.
> Alice would refuse to accept the signature in line 5.
> The consensus check detects it after the fact at the end of the chat
> session, therefore I think I would prefer the first solution.
>
> I would be surprised that such a replay attack is possible (which is not
> confirmed yet) because including a counter in sign() would defeat the
> attack.
>
> To be honest I also have a question regarding the consensus that is
> somehow connected to the replay scenario:
>
> Alice view:
>
> 1 Alice: Does it rain?
> 2 Bob: yes
> 3 Alice: really?
> 4 Bob: no
>
> Bob's view of the same chat room:
>
> 1 Alice: Does it rain?
> 2 Bob: no
> 3 Alice: really?
> 4 Bob: yes
>
> Charlie's view
>
> 1 Alice: Does it rain?
> 2 Alice: really?
> 3 Bob: no
> 4 Bob: yes
>
> Consensus checklist:
>  - same set of participants -> ok
>  - same sid -> ok
>  - same set of messages -> ok
>  - each message origin -> ok
>
> consensus reached?
>
> From chapter 4.4:
> "To ensure that out-of-order message delivery does not affect this
> digest, the messages are taken in lexical order. Note however, that
> should messages include a suitable order fingerprint, the lexical order
> coincides with delivery and creation order, hence our ordering is not
> restrictive."
>
> The remaining question is: Which order fingerprint is chosen?
>
> kind regards,
> Christoph
>
>



-- 
Berkant Ustaoglu
http://cryptolounge.net