On Tue, Nov 10, 2015, at 04:15 PM, Greg Troxel wrote: > > I am curious if anyone from OTR-land has comments about the pros and > cons of OMEMO vs OTR. > > http://conversations.im/omemo/ > > In using smssecure as well as OTR, I notice an interesting property > which is more about the implementation than the protocol, which is that > keymat is stored persistently. So after having an smssecure session > with Alice (not her real name :-) in early June, and no texts since, I > was able to send one just now, and have both of our devices still have > the keymat and have it work. Of course that means it has persisted in > flash across reboots. > > So it seems obvious that PFS is not a binary property; presumanbly the > keys are overwritten (seems hard with flash wear leveling) when new > messages happen, but there is a perhaps-months "short term key", vs a > maybe-years "long term key", and PFS or not becomes blurry. > > Keeping the keys definitely helps usability, but part of that is how OTR > (in adium) doesn't necessarily recover from a half-closed session > seamlessly.
Are you sure it was persisting key material? I think the idea with OMEMO is to support the Axolotl/TextSecure pre-key technique using XMPP infrastructure. This means, you can create a valid session key without the other party needing to be online. In addition, for ChatSecure, we proactively generate session keys for OTR, so that if you have an open conversation thread with someone, and they are online AND we detect they have a compatible XMPP resource, we start the OTR negotiation process. If you receive a message you cannot decrypt, we renegotiate the session, and then thanks to delivery receipts, the sender should then know to re-send the previous undelivered messages. The goal is to make OTR as automatic as possible, while still maintaining PFS, as much as possible. We only keep OTR session keys in RAM. That said, we really do like OMEMO, and do have plans to support it in our next-generation app, Zom. -- Nathan of Guardian [email protected] _______________________________________________ OTR-dev mailing list [email protected] http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
