Support for asynchronous communication

[mikrosk]

Following our discussion on #28, I'd like to make a feature request / plea :) one more time. I've been working on a p2p communication client for a while and as you can imagine, in such environment is hard to predict the order of delivery, basically to predict delivery at all. According to this blog post: https://whispersystems.org/blog/advanced-ratcheting it would seem that I'm doomed. The author had implemented a "double ratchet" algorithm presented here: https://github.com/trevp/double_ratchet/wiki but as far as I know, no attempt has been made to "backport" it into libotr.

However, when I tried some basic use cases like "send (encrypt) messages 1, 2, 3" and "receive (decrypt) 3, 2, 1" or "receive (decrypt) 3, 1" within a session, there wasn't any problem. Right now I don't care about forward secrecy, I'm happy to have one session per user pair forever (i.e. I'd use OTR mainly as an authentication tool, or, as mentioned in #28, as a symmetric key generator based on the shared secret).

So my questions would be:

• In what scenarios OTR does fail when it comes to the order of delivery? Am I safe during the session at least?
• If the session is safe, what do I have to store to be able to renew the session later? Would be making Session Serializable enough to renew the session?
• And most importantly, what are my chances to see the double ratchet algorithm (or something similar) implemented in otr4j? :-)

[cobratbq]

I intend to answer your questions for as far as I can, but it will take a few days as I am currently very busy.

[mikrosk]

That's all right, I'm looking forward for your answer!

[claucece]

Hey @mikrosk !

Just some news here: the new version of OTR will support asynchronous communication. Check it here: https://github.com/otrv4/otrv4

With OTRv4:

• In what scenarios OTR does fail when it comes to the order of delivery? Am I safe during the session at least?

None.

• If the session is safe, what do I have to store to be able to renew the session later? Would be making Session Serializable enough to renew the session?

With OTRv4, you only need to store message keys for a certain amount of time.

• And most importantly, what are my chances to see the double ratchet algorithm (or something similar) implemented in otr4j? :-)

In OTRv4. Check the C implementation, which already has some parts of the double ratchet algorithm:
https://github.com/otrv4/libotr-ng