/jitsi

Support for omemo #199

Open
yelloff opened this Issue Dec 25, 2015 · 100 comments

Comments

Assignees
No one assigned
Labels
Projects
None yet
Milestone
No milestone
@yelloff

yelloff commented Dec 25, 2015

That would be nice.
@ibauersachs

This comment has been minimized.

Show comment
Hide comment
@ibauersachs

ibauersachs Dec 25, 2015

Member

What is that?
Member

ibauersachs commented Dec 25, 2015

What is that?
@fippo

This comment has been minimized.

Show comment
Hide comment
@fippo

fippo Dec 25, 2015

@ibauersachs: an e2e encryption thing:
http://xmpp.org/extensions/inbox/omemo.html -- see also some recent discussion on standards@xmpp.org

fippo commented Dec 25, 2015

@ibauersachs: an e2e encryption thing:
http://xmpp.org/extensions/inbox/omemo.html -- see also some recent discussion on standards@xmpp.org
@jitsi-developers

This comment has been minimized.

Show comment
Hide comment
@jitsi-developers

jitsi-developers Dec 25, 2015

This is extraordinary weird. I just viewed this article 6 hours ago and
suddenly this e-mail came !

https://xmpp.org/2015/12/xmpp-at-the-end-of-the-google-summer-of-code-2015/
(2nd paragraph, Andreas Straub)

On 12/25/2015 09:57 PM, Ingo Bauersachs wrote:

What is that?

—
Reply to this email directly or view it on GitHub
#199 (comment).

dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

/Regards/,
/Ahmad/

jitsi-developers commented Dec 25, 2015

This is extraordinary weird. I just viewed this article 6 hours ago and
suddenly this e-mail came !

https://xmpp.org/2015/12/xmpp-at-the-end-of-the-google-summer-of-code-2015/
(2nd paragraph, Andreas Straub)

On 12/25/2015 09:57 PM, Ingo Bauersachs wrote:

What is that?

—
Reply to this email directly or view it on GitHub
#199 (comment).

dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

/Regards/,
/Ahmad/
@yelloff

This comment has been minimized.

Show comment
Hide comment
@yelloff

yelloff Dec 26, 2015

I was looking for an xmpp based alternative to Text Secure/Signal. And found this blog:
http://www.titus-stahl.de/blog/2015/09/15/how-to-get-secure-decentralized-chat-working-with-xmpp-both-on-mobile-and-desktop/

yelloff commented Dec 26, 2015

I was looking for an xmpp based alternative to Text Secure/Signal. And found this blog:
http://www.titus-stahl.de/blog/2015/09/15/how-to-get-secure-decentralized-chat-working-with-xmpp-both-on-mobile-and-desktop/
@lovetox

This comment has been minimized.

Show comment
Hide comment
@lovetox

lovetox Dec 30, 2015

this would be great, there is no desktop client that supports OMEMO
normal OTR from desktop -> phone is not the best UX.

also, all the desktop clients from whatsapp and singal need a phonenumber and a smartphone to activate an account -> horrible.

lovetox commented Dec 30, 2015

this would be great, there is no desktop client that supports OMEMO
normal OTR from desktop -> phone is not the best UX.

also, all the desktop clients from whatsapp and singal need a phonenumber and a smartphone to activate an account -> horrible.
@Evi1M4chine

This comment has been minimized.

Show comment
Hide comment
@Evi1M4chine

Evi1M4chine Jan 8, 2016

I just came over from Freedesktop’s Bugzilla for Telepathy’s XMPP component (gabble) and while they also have a bug for it, the KDE developers downstream don’t expect much from them. So Jitsi is probably our only hope for now.

(If it would enable chatting with Signal/TextSecure/Axolotl users, that would be the single greatest thing for desktop messaging as of now.)

Evi1M4chine commented Jan 8, 2016

I just came over from Freedesktop’s Bugzilla for Telepathy’s XMPP component (gabble) and while they also have a bug for it, the KDE developers downstream don’t expect much from them. So Jitsi is probably our only hope for now.

(If it would enable chatting with Signal/TextSecure/Axolotl users, that would be the single greatest thing for desktop messaging as of now.)

@ibauersachs ibauersachs added type:feature component:Chat protocol:XMPP help-wanted labels Jan 9, 2016

@ibauersachs

This comment has been minimized.

Show comment
Hide comment
@ibauersachs

ibauersachs Jan 9, 2016

Member

This would need to come from the community, we simply don't have the resources to develop this.
Member

ibauersachs commented Jan 9, 2016

This would need to come from the community, we simply don't have the resources to develop this.
@lovetox

This comment has been minimized.

Show comment
Hide comment
@lovetox

lovetox Jan 9, 2016

there is work on a Gajim Plugin https://github.com/kalkin/gajim-omemo
it already works for me.

@Evi1M4chine how do you think this would enable chatting with Signal or TextSecure Apps?
even if it is the same tech behind it, the companys behind it would have to allow it, if this was possible i think many people already would have made desktop apps for it.

Further does Signal rely on the telephonenumber (which is for me the biggest failure of all the new messaging apps) as kind of JID. i dont see it happen that they would allow to add people to their network based on an normal JID.

lovetox commented Jan 9, 2016

there is work on a Gajim Plugin https://github.com/kalkin/gajim-omemo
it already works for me.

@Evi1M4chine how do you think this would enable chatting with Signal or TextSecure Apps?
even if it is the same tech behind it, the companys behind it would have to allow it, if this was possible i think many people already would have made desktop apps for it.

Further does Signal rely on the telephonenumber (which is for me the biggest failure of all the new messaging apps) as kind of JID. i dont see it happen that they would allow to add people to their network based on an normal JID.
@improti

This comment has been minimized.

Show comment
Hide comment
@improti

improti Jan 12, 2016

The implementation contained in https://github.com/siacs/Conversations could also be portable. It's Java on Android, but I got no clue about the libraries used. Any chance to get the developers of these projects to make a common backend and provide their distinct UIs on top of that or something? There was a Jitsi on Android initiative anyways, right? The UI and design principles of Conversations make a really good impression, if you don't know it maybe take a look. It's chat-only though, i.e. without VoIP. Pictures in chats are a killer-feature, imho. Getting that and the OMEMO goodies working between the two (no matter if with common backend or not) would be really awesome.

improti commented Jan 12, 2016

The implementation contained in https://github.com/siacs/Conversations could also be portable. It's Java on Android, but I got no clue about the libraries used. Any chance to get the developers of these projects to make a common backend and provide their distinct UIs on top of that or something? There was a Jitsi on Android initiative anyways, right? The UI and design principles of Conversations make a really good impression, if you don't know it maybe take a look. It's chat-only though, i.e. without VoIP. Pictures in chats are a killer-feature, imho. Getting that and the OMEMO goodies working between the two (no matter if with common backend or not) would be really awesome.
@Evi1M4chine

This comment has been minimized.

Show comment
Hide comment
@Evi1M4chine

Evi1M4chine Jan 12, 2016

@lovetox:

Why would you think they couldn’t? The protocol is the same, so it’s only a matter of picking the same server to connect to. But you don’t even have to do that, since Signal’s server, being just an XMPP one with Axolotl/Omemo added in, supports federation (which is already used, e.g. with CyanogenMod’s builtin SMS/messaging app).
I also made a Signal fork this morning. Other than warnings about chat partners having different keys there were no problems. So obviously the “companies* behind it” don’t prevent it.

  • Which I assume are not criminals/psychopaths and hence don’t employ nasty anti-social behavior like exclusivism or trying to corporate-murder each other.
@improti:

Signal (formerly TextSecure) itself is already Android/Java. I don’t think it’s a problem to take any necessary code from there. It’s more a problem of: Who wants to do it?

Evi1M4chine commented Jan 12, 2016

@lovetox:

Why would you think they couldn’t? The protocol is the same, so it’s only a matter of picking the same server to connect to. But you don’t even have to do that, since Signal’s server, being just an XMPP one with Axolotl/Omemo added in, supports federation (which is already used, e.g. with CyanogenMod’s builtin SMS/messaging app).
I also made a Signal fork this morning. Other than warnings about chat partners having different keys there were no problems. So obviously the “companies* behind it” don’t prevent it.

  • Which I assume are not criminals/psychopaths and hence don’t employ nasty anti-social behavior like exclusivism or trying to corporate-murder each other.
@improti:

Signal (formerly TextSecure) itself is already Android/Java. I don’t think it’s a problem to take any necessary code from there. It’s more a problem of: Who wants to do it?

@improti improti referenced this issue in siacs/Conversations Jan 12, 2016

Closed

[Bounty] Explore possible synergies with project "Jitsi" #1646

@oodbur

This comment has been minimized.

Show comment
Hide comment
@oodbur

oodbur Jan 18, 2016

OMEMO could be significant: The Axolotl ratchet is the much improved and widely used (see WhatsApp and several others) successor to OTR. Now OMEMO integrates this directly into XMPP, so no more of the criticism of operating on the wrong layer of the protocol stack, which hurdled adoption (see Empathy/Telepathy) and is connected to usability problems of OTR.

oodbur commented Jan 18, 2016

OMEMO could be significant: The Axolotl ratchet is the much improved and widely used (see WhatsApp and several others) successor to OTR. Now OMEMO integrates this directly into XMPP, so no more of the criticism of operating on the wrong layer of the protocol stack, which hurdled adoption (see Empathy/Telepathy) and is connected to usability problems of OTR.
@jitsi-developers

This comment has been minimized.

Show comment
Hide comment
@jitsi-developers

jitsi-developers Jan 18, 2016

if OMEMO is useful/significant/superior to OTR etc etc - could you
please provide the plugin/support for Jitsi for it?

currently users (incl. myself) are happy that Jitsi client function is
maintained as it is because only very few developers are currently
volunteering to support Jitsi client

On 1/18/16 3:33 PM, oodbur wrote:

OMEMO could be significant: The Axolotl ratchet is the much improved
and widely used (see WhatsApp and several others) successor to OTR.
Now OMEMO integrates this directly into XMPP, so no more of the
criticism of operating on the wrong layer of the protocol stack, which
hurdled adoption (see Empathy/Telepathy) and is connected to usability
problems of OTR.

—
Reply to this email directly or view it on GitHub
#199 (comment).

dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

jitsi-developers commented Jan 18, 2016

if OMEMO is useful/significant/superior to OTR etc etc - could you
please provide the plugin/support for Jitsi for it?

currently users (incl. myself) are happy that Jitsi client function is
maintained as it is because only very few developers are currently
volunteering to support Jitsi client

On 1/18/16 3:33 PM, oodbur wrote:

OMEMO could be significant: The Axolotl ratchet is the much improved
and widely used (see WhatsApp and several others) successor to OTR.
Now OMEMO integrates this directly into XMPP, so no more of the
criticism of operating on the wrong layer of the protocol stack, which
hurdled adoption (see Empathy/Telepathy) and is connected to usability
problems of OTR.

—
Reply to this email directly or view it on GitHub
#199 (comment).

dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev
@Evi1M4chine

This comment has been minimized.

Show comment
Hide comment
@Evi1M4chine

Evi1M4chine Jan 19, 2016

Frankly, without OMEMO, there is no point in even using an IM client. OTR is unacceptable from a usability and design standpoint, and IM clients without push abilities plainly can’t work on mobile devices without dragging down the battery or not receiving messages.
So this is really the only choice. And Axolotl/OMEMO is apparently a rather nice implementation.
Which is why it is rapidly becoming the standard.
So any IM client who can’t do OMEMO, soon won’t be compatible with anything… especially not federated mobile XMPP clients.
If I can do anything about it, I won’t even allow non-OMEMO connections on my server or any client I might write or use, to show a big middle finger to any state terrorists (aka “intelligence” agencies, etc).

So, even more frankly, this is simply a question of life and death for Jitsi.
No OMEMO, and you could as well close down now, instead of letting it rot to a slow unavoidable digital donkey undeath.

The only thing I am ashamed of, is that I have so little resources to give, to support your great software.

Evi1M4chine commented Jan 19, 2016

Frankly, without OMEMO, there is no point in even using an IM client. OTR is unacceptable from a usability and design standpoint, and IM clients without push abilities plainly can’t work on mobile devices without dragging down the battery or not receiving messages.
So this is really the only choice. And Axolotl/OMEMO is apparently a rather nice implementation.
Which is why it is rapidly becoming the standard.
So any IM client who can’t do OMEMO, soon won’t be compatible with anything… especially not federated mobile XMPP clients.
If I can do anything about it, I won’t even allow non-OMEMO connections on my server or any client I might write or use, to show a big middle finger to any state terrorists (aka “intelligence” agencies, etc).

So, even more frankly, this is simply a question of life and death for Jitsi.
No OMEMO, and you could as well close down now, instead of letting it rot to a slow unavoidable digital donkey undeath.

The only thing I am ashamed of, is that I have so little resources to give, to support your great software.
@improti

This comment has been minimized.

Show comment
Hide comment
@improti

improti Jan 19, 2016

An implementation of OMEMO for XMPP is available (in Java) in the referenced project (https://github.com/siacs/Conversations). I'd very much like to see that becoming used in Jitsi (as well as the Jitsi ZRTP over XMPP becoming used in Conversations). I cannot do that atm due to large overhead involved (I know neither of the projects code-wise). But could you please try to get in touch with them and see if you guys can help each other here? Maybe drop a note in siacs/Conversations#1646 or something? It might actually be a rather small task if you could exchange code/knowledge here?

improti commented Jan 19, 2016

An implementation of OMEMO for XMPP is available (in Java) in the referenced project (https://github.com/siacs/Conversations). I'd very much like to see that becoming used in Jitsi (as well as the Jitsi ZRTP over XMPP becoming used in Conversations). I cannot do that atm due to large overhead involved (I know neither of the projects code-wise). But could you please try to get in touch with them and see if you guys can help each other here? Maybe drop a note in siacs/Conversations#1646 or something? It might actually be a rather small task if you could exchange code/knowledge here?
@turint

This comment has been minimized.

Show comment
Hide comment
@turint

turint Jan 19, 2016

Just like it was already mentioned by the devs -- yes, OMEMO is nice thing, but the code has to come from the community. Jitsi is a big project, with lot of work there to maintain it and believe me, the devs won't reject a good code attribution.

So once again, it's "talk is cheap, show me the code".

turint commented Jan 19, 2016

Just like it was already mentioned by the devs -- yes, OMEMO is nice thing, but the code has to come from the community. Jitsi is a big project, with lot of work there to maintain it and believe me, the devs won't reject a good code attribution.

So once again, it's "talk is cheap, show me the code".
@improti

This comment has been minimized.

Show comment
Hide comment
@improti

improti Jan 19, 2016

@turint : Here is the code: https://github.com/siacs/Conversations/tree/master/src/main/java/eu/siacs/conversations/crypto/axolotl - as said, I have no clue how Jitsi is build and how to go and integrate it (as I do not know how it is used there) :( If you tell me what info you need I would actually go and try to get it for you, although I think a direct exchange between you guys would be far more effective (and could yield synergies in the future as well?).

P.S.: What I do know (might be better to write about that?) is the following though: OMEMO needs a rather new version of ejabberd to work (> 14.x it seems), as it stores things on the server (that's how it works "offline"). PEP was mentioned several times, but I do not know the technical details. If Jitsi hasn't support for those XEPs yet, it will probably need some more work though. There is some technical information I found at https://conversations.im/omemo/ that look like draft specs: XEP-xxxx: OMEMO Encryption and XEP-xxxx: OMEMO Encrypted Jingle File Transfer. For any technically interested person those might be of interest.

improti commented Jan 19, 2016

@turint : Here is the code: https://github.com/siacs/Conversations/tree/master/src/main/java/eu/siacs/conversations/crypto/axolotl - as said, I have no clue how Jitsi is build and how to go and integrate it (as I do not know how it is used there) :( If you tell me what info you need I would actually go and try to get it for you, although I think a direct exchange between you guys would be far more effective (and could yield synergies in the future as well?).

P.S.: What I do know (might be better to write about that?) is the following though: OMEMO needs a rather new version of ejabberd to work (> 14.x it seems), as it stores things on the server (that's how it works "offline"). PEP was mentioned several times, but I do not know the technical details. If Jitsi hasn't support for those XEPs yet, it will probably need some more work though. There is some technical information I found at https://conversations.im/omemo/ that look like draft specs: XEP-xxxx: OMEMO Encryption and XEP-xxxx: OMEMO Encrypted Jingle File Transfer. For any technically interested person those might be of interest.
@lovetox

This comment has been minimized.

Show comment
Hide comment
@lovetox

lovetox Jan 19, 2016

@improti i think you misunderstanding him.

its not a question of information to make this possible, like you are trying to provide.
its a question of having the time to implement it.

it seems that the developers dont have time, even if it is a great feature.
so he is asking for a code contribution, someone from outside of the current development team to make that contribution (program it)

so if you cant code it yourself or get someone else to code it, you simply cant help.

lovetox commented Jan 19, 2016

@improti i think you misunderstanding him.

its not a question of information to make this possible, like you are trying to provide.
its a question of having the time to implement it.

it seems that the developers dont have time, even if it is a great feature.
so he is asking for a code contribution, someone from outside of the current development team to make that contribution (program it)

so if you cant code it yourself or get someone else to code it, you simply cant help.
@prinzpi

This comment has been minimized.

Show comment
Hide comment
@prinzpi

prinzpi Mar 18, 2016

Hi,
any new information regarding the case about the OMEMO support?

prinzpi commented Mar 18, 2016

Hi,
any new information regarding the case about the OMEMO support?
@ibauersachs

This comment has been minimized.

Show comment
Hide comment
@ibauersachs

ibauersachs Mar 18, 2016

Member

I'm not even capable of maintaining the existing features. So, no.
Member

ibauersachs commented Mar 18, 2016

I'm not even capable of maintaining the existing features. So, no.
@Evi1M4chine

This comment has been minimized.

Show comment
Hide comment
@Evi1M4chine

Evi1M4chine Mar 19, 2016

Maybe there needs to be a bug about creating a funding campaign? :)

Evi1M4chine commented Mar 19, 2016

Maybe there needs to be a bug about creating a funding campaign? :)
@DreamFlasher

This comment has been minimized.

Show comment
Hide comment
@DreamFlasher

DreamFlasher Apr 12, 2016

I'd love to see OMEMO being supported by Jitsi.

DreamFlasher commented Apr 12, 2016

I'd love to see OMEMO being supported by Jitsi.
@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost May 9, 2016

Bounty at bountysource

ghost commented May 9, 2016

Bounty at bountysource
@Ashaman-

This comment has been minimized.

Show comment
Hide comment
@Ashaman-

Ashaman- May 29, 2016

Added $25 to the bounty. Will add another $100 in if/when someone starts working on it.

Ashaman- commented May 29, 2016

Added $25 to the bounty. Will add another $100 in if/when someone starts working on it.
@hoijui

This comment has been minimized.

Show comment
Hide comment
@hoijui

hoijui Jun 8, 2016

can omemo also be used for voice and video communication/streams, or is it just for text messages and file transfers?

hoijui commented Jun 8, 2016

can omemo also be used for voice and video communication/streams, or is it just for text messages and file transfers?
@Ashaman-

This comment has been minimized.

Show comment
Hide comment
@Ashaman-

Ashaman- Jun 8, 2016

@hoijui Text and file transfer, with multi device and group message support. Zrtp is the standard for voice and video encryption - it's what Signal uses too.

On June 8, 2016 5:00:30 PM EDT, hoijui notifications@github.com wrote:

can omemo also be used for voice and video communication/streams, or is
it just for text messages and file transfers?

You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#199 (comment)

Sent from my Android device with K-9 Mail. Please excuse my brevity.

Ashaman- commented Jun 8, 2016

@hoijui Text and file transfer, with multi device and group message support. Zrtp is the standard for voice and video encryption - it's what Signal uses too.

On June 8, 2016 5:00:30 PM EDT, hoijui notifications@github.com wrote:

can omemo also be used for voice and video communication/streams, or is
it just for text messages and file transfers?

You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#199 (comment)

Sent from my Android device with K-9 Mail. Please excuse my brevity.
@SamWhited

This comment has been minimized.

Show comment
Hide comment
@SamWhited

SamWhited Jun 8, 2016

On Wed, Jun 8, 2016 at 4:00 PM, hoijui notifications@github.com wrote:

can omemo also be used for voice and video communication/streams, or is it just for text messages and file transfers?

OMEMO is a wire format designed for encrypting messages in XMPP (so
it's not well suited for video or file transfers; the current file
transfer mechanism doesn't really count since it requires receiving
the entire file before you can begin decryption, and it's actually
encrypted/decrypted out of band with a separate AES key).

ZRTP is a much better fit for A/V streams.

SamWhited commented Jun 8, 2016 •
edited
Edited 1 time
  • @SamWhited SamWhited edited Sep 27, 2016 (most recent)

On Wed, Jun 8, 2016 at 4:00 PM, hoijui notifications@github.com wrote:

can omemo also be used for voice and video communication/streams, or is it just for text messages and file transfers?

OMEMO is a wire format designed for encrypting messages in XMPP (so
it's not well suited for video or file transfers; the current file
transfer mechanism doesn't really count since it requires receiving
the entire file before you can begin decryption, and it's actually
encrypted/decrypted out of band with a separate AES key).

ZRTP is a much better fit for A/V streams.
@JohnnyCalavera

This comment has been minimized.

Show comment
Hide comment
@JohnnyCalavera

JohnnyCalavera Sep 27, 2016

Is anybody working on this? Seems like so many people are talking about OMEMO, but there is no stable desktop solution and on mobile devices there is only conversations.
At least Chatsecure is working on OMEMO integration... Still, we need something for our desktop systems.

JohnnyCalavera commented Sep 27, 2016

Is anybody working on this? Seems like so many people are talking about OMEMO, but there is no stable desktop solution and on mobile devices there is only conversations.
At least Chatsecure is working on OMEMO integration... Still, we need something for our desktop systems.
@DreamFlasher

This comment has been minimized.

Show comment
Hide comment
@DreamFlasher

DreamFlasher Sep 27, 2016

There is a stable desktop solution which works on the relevent desktop OS: Gajim -- and it's the reason why I switched to it, away from Jitsi. So yeah Jitsi, would be great if you add that feature, because apart from that you have a great software :)

DreamFlasher commented Sep 27, 2016

There is a stable desktop solution which works on the relevent desktop OS: Gajim -- and it's the reason why I switched to it, away from Jitsi. So yeah Jitsi, would be great if you add that feature, because apart from that you have a great software :)
@Evi1M4chine

This comment has been minimized.

Show comment
Hide comment
@Evi1M4chine

Evi1M4chine Sep 28, 2016

The thing is: OMEMO and the ratchet design only became necessary on unstable mobile connections. Jitsi already includes proper encryption. The only reason I would like to see it, is so it can communicate nicely with mobile messengers that need it. (Since all [my] messengers should use the same standardized protocol to avoid lock-in.)

Evi1M4chine commented Sep 28, 2016

The thing is: OMEMO and the ratchet design only became necessary on unstable mobile connections. Jitsi already includes proper encryption. The only reason I would like to see it, is so it can communicate nicely with mobile messengers that need it. (Since all [my] messengers should use the same standardized protocol to avoid lock-in.)
@DreamFlasher

This comment has been minimized.

Show comment
Hide comment
@DreamFlasher

DreamFlasher Sep 28, 2016

The thing is: That's wrong.
See: https://conversations.im/omemo/

comparison

DreamFlasher commented Sep 28, 2016

The thing is: That's wrong.
See: https://conversations.im/omemo/

comparison
@ccoenen

This comment has been minimized.

Show comment
Hide comment
@ccoenen

ccoenen Sep 28, 2016

@Evi1M4chine you make it sound as if OMEMO isn't all that neccessary because Jitsi is on the desktop. But you never know where the other end of your chat is received - in today's world there's a pretty high chance that at least one of the receivers is actually a mobile device with less-than-ideal connection. Also (as mentioned in the table above) receiving stuff on PC and Mobile or work PC and private PC (for example via XEP280 Carbon copy) is something that's fairly common. And OTR is not a good fit, there either.

I see only advantages with OMEMO, except that support is extremely limited right now. Exactly what the OP tries to get fixed.

ccoenen commented Sep 28, 2016

@Evi1M4chine you make it sound as if OMEMO isn't all that neccessary because Jitsi is on the desktop. But you never know where the other end of your chat is received - in today's world there's a pretty high chance that at least one of the receivers is actually a mobile device with less-than-ideal connection. Also (as mentioned in the table above) receiving stuff on PC and Mobile or work PC and private PC (for example via XEP280 Carbon copy) is something that's fairly common. And OTR is not a good fit, there either.

I see only advantages with OMEMO, except that support is extremely limited right now. Exactly what the OP tries to get fixed.
@SamWhited

This comment has been minimized.

Show comment
Hide comment
@SamWhited

SamWhited Sep 28, 2016

The thing is: OMEMO and the ratchet design only became necessary on unstable mobile connections. Jitsi already includes proper encryption.

OMEMO and the Axolotl double ratchet design have nothing to do with mobile; the main benefit OMEMO has over other end-to-end encryption mechanisms like OTR is that it can be used to send messages to multiple online clients on both ends, so your contact can get your encrypted message on their desktop and their phone. To do this it sacrifices perfect forward secrecy (it's still forward secret, but not to the same degree that OTR is), which is probably an acceptable trade off for most people. The benefit it has over something like PGP is that it is forward secret, and the down side is that it can only sync with clients that had already published pre-keys (if you add new clients, or clients don't come online for too long and the pre-keys are all used up, they won't get old messages).

It's all about the security properties you need for your use case; bandwidth and the stability of the connection isn't really a concern in any of the three major chat encryption mechanisms.

(Since all [my] messengers should use the same standardized protocol to avoid lock-in.)

I agree, but currently there aren't any real standards for end-to-end encryption in messaging. OTR is at best a defacto standard, PGP is done differently in ever implementation (although there is work happening at the XSF to standardize this recently), and OMEMO is in the process of standardization with its change from the Axolotl ratchet to Olm (a very similar scheme that changes the IV to get around some potential legal issues).

SamWhited commented Sep 28, 2016 •
edited
Edited 1 time
  • @SamWhited SamWhited edited Sep 28, 2016 (most recent)

The thing is: OMEMO and the ratchet design only became necessary on unstable mobile connections. Jitsi already includes proper encryption.

OMEMO and the Axolotl double ratchet design have nothing to do with mobile; the main benefit OMEMO has over other end-to-end encryption mechanisms like OTR is that it can be used to send messages to multiple online clients on both ends, so your contact can get your encrypted message on their desktop and their phone. To do this it sacrifices perfect forward secrecy (it's still forward secret, but not to the same degree that OTR is), which is probably an acceptable trade off for most people. The benefit it has over something like PGP is that it is forward secret, and the down side is that it can only sync with clients that had already published pre-keys (if you add new clients, or clients don't come online for too long and the pre-keys are all used up, they won't get old messages).

It's all about the security properties you need for your use case; bandwidth and the stability of the connection isn't really a concern in any of the three major chat encryption mechanisms.

(Since all [my] messengers should use the same standardized protocol to avoid lock-in.)

I agree, but currently there aren't any real standards for end-to-end encryption in messaging. OTR is at best a defacto standard, PGP is done differently in ever implementation (although there is work happening at the XSF to standardize this recently), and OMEMO is in the process of standardization with its change from the Axolotl ratchet to Olm (a very similar scheme that changes the IV to get around some potential legal issues).
@falsefifth

This comment has been minimized.

Show comment
Hide comment
@falsefifth

falsefifth Nov 6, 2016

This would need to come from the community, we simply don't have the resources to develop this.

In terms of monetary units what would we be talking?

falsefifth commented Nov 6, 2016 •
edited
Edited 1 time
  • @falsefifth falsefifth edited Nov 6, 2016 (most recent)

This would need to come from the community, we simply don't have the resources to develop this.

In terms of monetary units what would we be talking?
@Evi1M4chine

This comment has been minimized.

Show comment
Hide comment
@Evi1M4chine

Evi1M4chine Nov 7, 2016

[Removed stuff that was just a repetition of what I had already said.]

But to bring this thing to its logical conclusion: A proper solution would be, to build full obligatory encryption of every connection right into the kernel, and add an OMEMO-equivalent as a facility to that!
(And this encryption should definitely be decentralized, without any defective-by-design fallacy like CAs, but with pluggable encryption modules.)

Maybe this ends the discussion. :)

@ccoenen: You misunderstood me. I was agreeing with you. :) I was just disappointed at the problem existing with mobile devices in the first place, because I think it is a bug of the underlying OSI layers.

Evi1M4chine commented Nov 7, 2016 •
edited
Edited 1 time
  • @Evi1M4chine Evi1M4chine edited Nov 7, 2016 (most recent)

[Removed stuff that was just a repetition of what I had already said.]

But to bring this thing to its logical conclusion: A proper solution would be, to build full obligatory encryption of every connection right into the kernel, and add an OMEMO-equivalent as a facility to that!
(And this encryption should definitely be decentralized, without any defective-by-design fallacy like CAs, but with pluggable encryption modules.)

Maybe this ends the discussion. :)

@ccoenen: You misunderstood me. I was agreeing with you. :) I was just disappointed at the problem existing with mobile devices in the first place, because I think it is a bug of the underlying OSI layers.
@vanitasvitae

This comment has been minimized.

Show comment
Hide comment
@vanitasvitae

vanitasvitae Nov 15, 2016

I will most definitely implement Jitsi OMEMO support as part of my bachelor thesis.

vanitasvitae commented Nov 15, 2016

I will most definitely implement Jitsi OMEMO support as part of my bachelor thesis.
@vanitasvitae

This comment has been minimized.

Show comment
Hide comment
@vanitasvitae

vanitasvitae Jan 19, 2017

Update: I'm making progress. My module is usable in 1:1 chats already. I'll tackle MUC support soon.

Btw: Take a look at this overview of OMEMO implementations.

vanitasvitae commented Jan 19, 2017

Update: I'm making progress. My module is usable in 1:1 chats already. I'll tackle MUC support soon.

Btw: Take a look at this overview of OMEMO implementations.
@2Belette

This comment has been minimized.

Show comment
Hide comment
@2Belette

2Belette Feb 23, 2017

@vanitasvitae your link seems broken ?
Is there a way to test your module somewhere with Jitsi?
Many thanks ;)

2Belette commented Feb 23, 2017

@vanitasvitae your link seems broken ?
Is there a way to test your module somewhere with Jitsi?
Many thanks ;)
@vanitasvitae

This comment has been minimized.

Show comment
Hide comment
@vanitasvitae

vanitasvitae Feb 23, 2017

@2Belette Yes, I separated the repository into two modules. You can find the source code here:
https://github.com/vanitasvitae/smack-omemo
https://github.com/vanitasvitae/smack-omemo-signal

In order to test the module, you'd first have to update Smack in Jitsi to version 4.2

vanitasvitae commented Feb 23, 2017 •
edited
Edited 1 time
  • @vanitasvitae vanitasvitae edited Feb 23, 2017 (most recent)

@2Belette Yes, I separated the repository into two modules. You can find the source code here:
https://github.com/vanitasvitae/smack-omemo
https://github.com/vanitasvitae/smack-omemo-signal

In order to test the module, you'd first have to update Smack in Jitsi to version 4.2
@2Belette

This comment has been minimized.

Show comment
Hide comment
@2Belette

2Belette Feb 24, 2017

2Belette commented Feb 24, 2017

@vanitasvitae

This comment has been minimized.

Show comment
Hide comment
@vanitasvitae

vanitasvitae Feb 24, 2017

@2Belette For now I'm focusing on making it a good usable Smack module. My goal is, that it's straight forward for a client like jitsi to implement OMEMO (sendOmemoMessage instead of sendMessage...). The hardest part on the client side should be designing the UI for activating OMEMO, trusting keys etc.

vanitasvitae commented Feb 24, 2017

@2Belette For now I'm focusing on making it a good usable Smack module. My goal is, that it's straight forward for a client like jitsi to implement OMEMO (sendOmemoMessage instead of sendMessage...). The hardest part on the client side should be designing the UI for activating OMEMO, trusting keys etc.
@2Belette

This comment has been minimized.

Show comment
Hide comment
@2Belette

2Belette Feb 24, 2017

2Belette commented Feb 24, 2017

@cmeng-git

This comment has been minimized.

Show comment
Hide comment
@cmeng-git

cmeng-git Jul 12, 2017

aTalk-android has implemented OMEMO. For anybody who are interested, may download from the site below. Note aTalk supports android device only:

http://atalk.sytes.net/releases/atalk-android/aTalk-release.apk

cmeng-git commented Jul 12, 2017

aTalk-android has implemented OMEMO. For anybody who are interested, may download from the site below. Note aTalk supports android device only:

http://atalk.sytes.net/releases/atalk-android/aTalk-release.apk
@DreamFlasher

This comment has been minimized.

Show comment
Hide comment
@DreamFlasher

DreamFlasher Jul 12, 2017

@cmeng-git This sounds great, but could you add a little bit more information? I can't find aTalk in the PlayStore nor on F-Droid. Also I can't find any website, http://atalk.sytes.net/ is a newly configured apache, http://atalk.sytes.net/releases/atalk-android is forbidden. Do you have the sourcecode of the apk somewhere published?

DreamFlasher commented Jul 12, 2017

@cmeng-git This sounds great, but could you add a little bit more information? I can't find aTalk in the PlayStore nor on F-Droid. Also I can't find any website, http://atalk.sytes.net/ is a newly configured apache, http://atalk.sytes.net/releases/atalk-android is forbidden. Do you have the sourcecode of the apk somewhere published?
@cmeng-git

This comment has been minimized.

Show comment
Hide comment
@cmeng-git

cmeng-git Jul 12, 2017

cmeng-git commented Jul 12, 2017

@DreamFlasher

This comment has been minimized.

Show comment
Hide comment
@DreamFlasher

DreamFlasher Jul 12, 2017

Okay, can you ping us again when you have released the source code? Before that I'd rather not install a random apk, which in the best case just shows an encryption symbol and in the worst case contains a rootkit ;)

DreamFlasher commented Jul 12, 2017

Okay, can you ping us again when you have released the source code? Before that I'd rather not install a random apk, which in the best case just shows an encryption symbol and in the worst case contains a rootkit ;)
@cmeng-git

This comment has been minimized.

Show comment
Hide comment
@cmeng-git

cmeng-git Jul 12, 2017

cmeng-git commented Jul 12, 2017

@louy2

This comment has been minimized.

Show comment
Hide comment
@louy2

louy2 Jul 15, 2017

@cmeng-git In which case, are you using Smack in aTalk? Since that recently added support to OMEMO.

https://community.igniterealtime.org/blogs/ignite/2017/06/06/smack-v42-introduces-omemo-support

louy2 commented Jul 15, 2017

@cmeng-git In which case, are you using Smack in aTalk? Since that recently added support to OMEMO.

https://community.igniterealtime.org/blogs/ignite/2017/06/06/smack-v42-introduces-omemo-support
@vanitasvitae

This comment has been minimized.

Show comment
Hide comment
@vanitasvitae

vanitasvitae Jul 15, 2017

@louy2 Yeah, aTalk is the second app that I know of that utilizes my OMEMO code :)

vanitasvitae commented Jul 15, 2017

@louy2 Yeah, aTalk is the second app that I know of that utilizes my OMEMO code :)
@cmeng-git

This comment has been minimized.

Show comment
Hide comment
@cmeng-git

cmeng-git Jul 15, 2017

Hi Louy2.

Below is the history log for aTalk that starts using Smack release version 4.2.1
[...]

cmeng-git commented Jul 15, 2017 •
edited by ibauersachs
Edited 1 time
  • @ibauersachs ibauersachs edited Jul 15, 2017 (most recent)

Hi Louy2.

Below is the history log for aTalk that starts using Smack release version 4.2.1
[...]
@ibauersachs

This comment has been minimized.

Show comment
Hide comment
@ibauersachs

ibauersachs Jul 15, 2017

Member

@cmeng-git I've removed the release notes. You can link to them on your own site, provided that you release the source code. I've previously politely asked you to do that. It isn't just the morally right thing to do. Since you're now using OMEMO, thanks to the GPL, you're legally obligated to release it.
Member

ibauersachs commented Jul 15, 2017 •
edited
Edited 1 time
  • @ibauersachs ibauersachs edited Jul 15, 2017 (most recent)

@cmeng-git I've removed the release notes. You can link to them on your own site, provided that you release the source code. I've previously politely asked you to do that. It isn't just the morally right thing to do. Since you're now using OMEMO, thanks to the GPL, you're legally obligated to release it.
@cmeng-git

This comment has been minimized.

Show comment
Hide comment
@cmeng-git

cmeng-git Jul 15, 2017

Sorry if this has offended you. I am just reply to louy2 question. As I have mentioned earlier, atalk source will be open source. It is just that I feel the source is just no clean up enough to be released.

cmeng-git commented Jul 15, 2017

Sorry if this has offended you. I am just reply to louy2 question. As I have mentioned earlier, atalk source will be open source. It is just that I feel the source is just no clean up enough to be released.
@ccoenen

This comment has been minimized.

Show comment
Hide comment
@ccoenen

ccoenen Jul 15, 2017

@ibauersachs AFAIK, it is perfectly fine to hand out source code "on request" of a user. This is not the way the community prefers it, but it is legal use under the GPL.

... to make sure that you have the freedom to distribute copies of free software (and charge for them if you wish), that you receive source code or can get it if you want it ...
(From GPL-v3 Preamble)

ccoenen commented Jul 15, 2017

@ibauersachs AFAIK, it is perfectly fine to hand out source code "on request" of a user. This is not the way the community prefers it, but it is legal use under the GPL.

... to make sure that you have the freedom to distribute copies of free software (and charge for them if you wish), that you receive source code or can get it if you want it ...
(From GPL-v3 Preamble)
@DreamFlasher

This comment has been minimized.

Show comment
Hide comment
@DreamFlasher

DreamFlasher Jul 15, 2017

@cmeng-git @ccoenen Well then, I hereby request the source code of aTalk :) You can reach me via the methods listed here: https://keybase.io/dreamflasher

DreamFlasher commented Jul 15, 2017

@cmeng-git @ccoenen Well then, I hereby request the source code of aTalk :) You can reach me via the methods listed here: https://keybase.io/dreamflasher
@cmeng-git

This comment has been minimized.

Show comment
Hide comment
@cmeng-git

cmeng-git Jul 15, 2017

Thanks for showing interest on atalk source. When I mention the source is not clean enough for public release. It is more than just pure source coding. Atalk is a fork from jitsi-android. At the moment, the source has multiple copyright statement. Leagally I do not have good idea what it means to release source of this nature. Actually I am about to start discussion this with someone and seek their advice. Hopefully it is not too complicated and restriction to release the source. Meantime I do not feel comfortable to release code to the public. Thank for your understanding.

cmeng-git commented Jul 15, 2017

Thanks for showing interest on atalk source. When I mention the source is not clean enough for public release. It is more than just pure source coding. Atalk is a fork from jitsi-android. At the moment, the source has multiple copyright statement. Leagally I do not have good idea what it means to release source of this nature. Actually I am about to start discussion this with someone and seek their advice. Hopefully it is not too complicated and restriction to release the source. Meantime I do not feel comfortable to release code to the public. Thank for your understanding.
@ccoenen

This comment has been minimized.

Show comment
Hide comment
@ccoenen

ccoenen Jul 15, 2017

@cmeng-git jitsi-android is released under apache license at the top of this license file is a short summary what that means.

ccoenen commented Jul 15, 2017

@cmeng-git jitsi-android is released under apache license at the top of this license file is a short summary what that means.
@ccoenen

This comment has been minimized.

Show comment
Hide comment
@ccoenen

ccoenen Jul 15, 2017

We're going off-topic a lot. I will not comment further on this branch of the discussion. Let's get back to omemo in jitsi.

ccoenen commented Jul 15, 2017

We're going off-topic a lot. I will not comment further on this branch of the discussion. Let's get back to omemo in jitsi.
@cmeng-git

This comment has been minimized.

Show comment
Hide comment
@cmeng-git

cmeng-git Jul 15, 2017

cmeng-git commented Jul 15, 2017 •
edited
Edited 1 time
  • @cmeng-git cmeng-git edited Jul 15, 2017 (most recent)

@damencho damencho referenced this issue in jitsi/jitsi-meet Jan 23, 2018

Closed

Implement OMEMO beside OTR #2409

@smith476

This comment has been minimized.

Show comment
Hide comment
@smith476

smith476 Feb 6, 2018

sorry for re-opening this thread - but client "aTalk" (Jitsi-Android fork) is now available on Google Play "aTalk (Jabber / XMPP)" which includes both OMEMO (!) and OTR support, the source is published on GitHub.
How is the progress implementing OMEMO in Jitsi-Desktop?

smith476 commented Feb 6, 2018

sorry for re-opening this thread - but client "aTalk" (Jitsi-Android fork) is now available on Google Play "aTalk (Jabber / XMPP)" which includes both OMEMO (!) and OTR support, the source is published on GitHub.
How is the progress implementing OMEMO in Jitsi-Desktop?
@ibauersachs

This comment has been minimized.

Show comment
Hide comment
@ibauersachs

ibauersachs Feb 19, 2018

Member

There is no progress for OMEMO itself. Smack 4.2 (which is a prerequiste) is almost ready to merge (the pending switch to OpenH264).

Note however that the Smack implementation of OMEMO cannot be used since it is GPL licensed. If there is no progress on licensing OMEMO differently, it can never end up in Jitsi.

Regarding aTalk, at least it is finally open source. Unfortunately the changes in the XMPP stack haven't been contributed back to Jitsi. I think @cmeng-git never signed the Atlassian CLA, so I also cannot just merge his changes back myself (which by this time would probably be pointless anyway since the codes diverged too much).
Member

ibauersachs commented Feb 19, 2018

There is no progress for OMEMO itself. Smack 4.2 (which is a prerequiste) is almost ready to merge (the pending switch to OpenH264).

Note however that the Smack implementation of OMEMO cannot be used since it is GPL licensed. If there is no progress on licensing OMEMO differently, it can never end up in Jitsi.

Regarding aTalk, at least it is finally open source. Unfortunately the changes in the XMPP stack haven't been contributed back to Jitsi. I think @cmeng-git never signed the Atlassian CLA, so I also cannot just merge his changes back myself (which by this time would probably be pointless anyway since the codes diverged too much).
@DreamFlasher

This comment has been minimized.

Show comment
Hide comment
@DreamFlasher

DreamFlasher Feb 19, 2018

Just as a reference I found this as a good explanation about the licensing situation: https://github.com/igniterealtime/Smack/wiki/OMEMO-libsignal-Licensing-Situation
Is there any way out of that? Could there be a plugin under GPL license which wraps smack and smack-omemo-signal and then Jitsi could just use the plugin?
-> Looks like a no: https://www.apache.org/licenses/GPL-compatibility.html unless the author relaxed his license.

DreamFlasher commented Feb 19, 2018 •
edited
Edited 1 time
  • @DreamFlasher DreamFlasher edited Feb 19, 2018 (most recent)

Just as a reference I found this as a good explanation about the licensing situation: https://github.com/igniterealtime/Smack/wiki/OMEMO-libsignal-Licensing-Situation
Is there any way out of that? Could there be a plugin under GPL license which wraps smack and smack-omemo-signal and then Jitsi could just use the plugin?
-> Looks like a no: https://www.apache.org/licenses/GPL-compatibility.html unless the author relaxed his license.
@vanitasvitae

This comment has been minimized.

Show comment
Hide comment
@vanitasvitae

vanitasvitae Feb 19, 2018

@DreamFlasher I'm not an expert on the field of software licenses. Is it possible to circumvent licensing issues with plugins?

vanitasvitae commented Feb 19, 2018

@DreamFlasher I'm not an expert on the field of software licenses. Is it possible to circumvent licensing issues with plugins?
@ibauersachs

This comment has been minimized.

Show comment
Hide comment
@ibauersachs

ibauersachs Feb 19, 2018

Member

I think this should work. We (the Jitsi authors) don‘t mind having our code combined with GPL‘ed code, but:

  • it cannot live in the Jitsi repository
  • we cannot ship/distribute a combination

(because that would automatically apply the GPL to everything).

If somebody else does that though, fine. The Apache License 2.0 is compatible with the GPL3 (but not GPL2!).
Member

ibauersachs commented Feb 19, 2018

I think this should work. We (the Jitsi authors) don‘t mind having our code combined with GPL‘ed code, but:

  • it cannot live in the Jitsi repository
  • we cannot ship/distribute a combination

(because that would automatically apply the GPL to everything).

If somebody else does that though, fine. The Apache License 2.0 is compatible with the GPL3 (but not GPL2!).

@yegortimoshenko yegortimoshenko referenced this issue in nylira/prism-break Mar 18, 2018

Closed

Remove XMPP clients that do not support OMEMO #1927

@smith476

This comment has been minimized.

Show comment
Hide comment
@smith476

smith476 Mar 27, 2018

short info: with the recent update (2.0.0) the "Conversations" client on Android is removing support for OTR.
OMEMO is now the default encryption method.
I guess all Jitsi Desktop users would be very grateful, if their preferred client would receive OMEMO support soon, the OMEMO development with other clients is progressing:
https://omemo.top/
(I am only politely motivating and cannot provide support myself due to lack of IT skills)

smith476 commented Mar 27, 2018

short info: with the recent update (2.0.0) the "Conversations" client on Android is removing support for OTR.
OMEMO is now the default encryption method.
I guess all Jitsi Desktop users would be very grateful, if their preferred client would receive OMEMO support soon, the OMEMO development with other clients is progressing:
https://omemo.top/
(I am only politely motivating and cannot provide support myself due to lack of IT skills)
@cmeng-git

This comment has been minimized.

Show comment
Hide comment
@cmeng-git

cmeng-git Apr 5, 2018

cmeng-git commented Apr 5, 2018

@cmeng-git

This comment has been minimized.

Show comment
Hide comment
@cmeng-git

cmeng-git Apr 5, 2018

cmeng-git commented Apr 5, 2018

@stevenroose

This comment has been minimized.

Show comment
Hide comment
@stevenroose

stevenroose May 22, 2018

@vanitasvitae How is the progress going??

stevenroose commented May 22, 2018

@vanitasvitae How is the progress going??
@vanitasvitae

This comment has been minimized.

Show comment
Hide comment
@vanitasvitae

vanitasvitae May 22, 2018

Unfortunately I'm currently very busy with other things (this years Summer of Code project), so I don't have much time to look at the OMEMO stuff. There are multiple heavy weight PRs I openend, which still need to get merged (the OMEMO PR is among them). However, I encourage the use of the OMEMO code in order to find bugs or - even better - submit fixes ;)

vanitasvitae commented May 22, 2018

Unfortunately I'm currently very busy with other things (this years Summer of Code project), so I don't have much time to look at the OMEMO stuff. There are multiple heavy weight PRs I openend, which still need to get merged (the OMEMO PR is among them). However, I encourage the use of the OMEMO code in order to find bugs or - even better - submit fixes ;)
@stevenroose

This comment has been minimized.

Show comment
Hide comment
@stevenroose

stevenroose May 23, 2018

@vanitasvitae Doing OpenPGP in favor of OMEMO? :(

stevenroose commented May 23, 2018

@vanitasvitae Doing OpenPGP in favor of OMEMO? :(
@vanitasvitae

This comment has been minimized.

Show comment
Hide comment
@vanitasvitae

vanitasvitae May 23, 2018

In addition :)

vanitasvitae commented May 23, 2018

In addition :)
@MathiasRenner

This comment has been minimized.

Show comment
Hide comment
@MathiasRenner

MathiasRenner May 23, 2018

I meanwhile changed to Matrix (https://matrix.org) with the Riot client. Quite happy so far.

MathiasRenner commented May 23, 2018

I meanwhile changed to Matrix (https://matrix.org) with the Riot client. Quite happy so far.
@ccoenen

This comment has been minimized.

Show comment
Hide comment
@ccoenen

ccoenen May 23, 2018

(good for you, not that anyone cares? If a moderator could please remove that post and mine along with it, that'd be great.)

ccoenen commented May 23, 2018

(good for you, not that anyone cares? If a moderator could please remove that post and mine along with it, that'd be great.)
@saghul

This comment has been minimized.

Show comment
Hide comment
@saghul

saghul May 24, 2018

Member

I don't think that comment needs to be deleted. You may disagree, and that's fine.
Member

saghul commented May 24, 2018

I don't think that comment needs to be deleted. You may disagree, and that's fine.
@DreamFlasher

This comment has been minimized.

Show comment
Hide comment
@DreamFlasher

DreamFlasher May 24, 2018

It's off-topic.

DreamFlasher commented May 24, 2018

It's off-topic.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment