[OTR-users] mpOTR: replay attacks from insiders

[Christoph A.]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: OpenPGP digital signature
URL: <http://lists.cypherpunks.ca/pipermail/otr-users/attachments/20100830/19a6522d/attachment.pgp>