Jump to content

KTp/RepeatedDiscussions/OTR: Difference between revisions

From KDE Community Wiki
Mck182 (talk | contribs)
Drop the "Do I need OTR to be safe?" section, does not fully apply after the NSA scandals...
D ed (talk | contribs)
Line 21: Line 21:
Encrypting messages is at the wrong level, encrypting the entire stream (i.e XEP-0188 which is lower in the stack) is so much simpler, provides greater security and is "right".
Encrypting messages is at the wrong level, encrypting the entire stream (i.e XEP-0188 which is lower in the stack) is so much simpler, provides greater security and is "right".


OTR is only for geek users and the paranoid, and no-one discusses anything that secret over IM! It doesn't have a large userbase, just a vocal one.
libOTR isn't an ideal solution.


===Conclusion===
===Conclusion===

Revision as of 13:12, 23 September 2013

Add OTR support to KDE-Telepathy

Summary

No. Unless you want to code it, in which case we will be happy to help.

What is OTR

OTR is short for "off the record" and is an encryption scheme that sits _on top_ of all messaging layers providing point-to-point encryption/auth. It is not an official part of any communication protocol but a layer on top written by some cryptographers.

Wikipedia, as always, says it best: Off-the-Record_Messaging

History

When we started KTp OTR was being considered for implementation at the Telepathy level, up from us. As such we were waiting on it to be implemented in the library we used, and we would add the UI on top. There was a GSOC project on this, but this was never merged into Telepathy (https://gitorious.org/jprvita-repos/telepathy-gabble/commits/otr), and as such we have nothing to build upon. We could implement it ourselves, on top of the Telepathy layer. This is a slightly less "clean" solution, but the most realistic.

Personal Thoughts

Encrypting messages is at the wrong level, encrypting the entire stream (i.e XEP-0188 which is lower in the stack) is so much simpler, provides greater security and is "right".

libOTR isn't an ideal solution.

Conclusion

If someone wants to implement it in KTp we will be happy to help. We have a message filtering plugin which could be adapted to work with this, and the plugin from Kopete could be ported with medium changes. We will happily adapt our plugin system to try and support it and anyone stepping up to the coding challenge.

However, it's not something I consider a worthwhile use of my team's time, and angry comments on blog posts/mailing lists/social networks will not change that.

Misc

GTalk also has an implementation of something called "OTR" which is Off the Record which turns off server logging, This is completely different and is a documented XMPP extension. This is something I would like to add.