Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for omemo #199

Open
yelloff opened this issue Dec 25, 2015 · 125 comments
Open

Support for omemo #199

yelloff opened this issue Dec 25, 2015 · 125 comments

Comments

@yelloff
Copy link

@yelloff yelloff commented Dec 25, 2015

That would be nice.

@ibauersachs
Copy link
Member

@ibauersachs ibauersachs commented Dec 25, 2015

What is that?

@fippo
Copy link
Member

@fippo 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
Copy link

@jitsi-developers 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
Copy link
Author

@yelloff 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
Copy link

@lovetox 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
Copy link

@Evi1M4chine 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
Copy link
Member

@ibauersachs ibauersachs commented Jan 9, 2016

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

@lovetox
Copy link

@lovetox 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
Copy link

@improti 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
Copy link

@Evi1M4chine 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?

@oodbur
Copy link

@oodbur 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
Copy link

@jitsi-developers 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
Copy link

@Evi1M4chine 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
Copy link

@improti 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 iNPUTmice/Conversations#1646 or something? It might actually be a rather small task if you could exchange code/knowledge here?

@turint
Copy link

@turint 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
Copy link

@improti 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
Copy link

@lovetox 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
Copy link

@prinzpi prinzpi commented Mar 18, 2016

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

@ibauersachs
Copy link
Member

@ibauersachs ibauersachs commented Mar 18, 2016

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

@Evi1M4chine
Copy link

@Evi1M4chine Evi1M4chine commented Mar 19, 2016

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

@dreamflasher
Copy link

@dreamflasher dreamflasher commented Apr 12, 2016

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

@ghost
Copy link

@ghost ghost commented May 9, 2016

Bounty at bountysource

@Ashaman-
Copy link

@Ashaman- Ashaman- commented May 29, 2016

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

@hoijui
Copy link

@hoijui 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-
Copy link

@Ashaman- 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.

@vanitasvitae
Copy link

@vanitasvitae vanitasvitae commented May 23, 2018

In addition :)

@MathiasRenner
Copy link

@MathiasRenner MathiasRenner commented May 23, 2018

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

@ccoenen
Copy link

@ccoenen 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
Copy link
Member

@saghul saghul commented May 24, 2018

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

@dreamflasher
Copy link

@dreamflasher dreamflasher commented May 24, 2018

It's off-topic.

@smith476
Copy link

@smith476 smith476 commented Sep 8, 2018

Dear All,
as openpgp has been integrated into smack (heavy thx to @vanitasvitae):
https://blogs.fsfe.org/vanitasvitae/2018/07/30/summer-of-code-smack-has-openpgp-support/
I am kindly asking when openpgp and OMEMO (!) will be integrated into Jitsi Desktop client?
It is simply pity that one of the most advanced XMPP VoIP clients (harbouring the almost unique features of ZRTP for audio/video and currently OTR for texting) is becoming more and more iqnored and lacking support by the open source community...(myself only user, no programmer)
many thx, Smith

@Neustradamus
Copy link

@Neustradamus Neustradamus commented Nov 22, 2018

Any news?

@mario26
Copy link

@mario26 mario26 commented Nov 22, 2018

I'm waiting for OMEMO in Jitsi Desktop and Jitsi Android for XMPP impatiently, could it work soon?

Thank you !

@smith476
Copy link

@smith476 smith476 commented Nov 22, 2018

I still have hope for Jitsi Desktop with OMEMO, but not so much with Jitsi Android.
For Android a XMPP client (a fork of Jitsi-Android) called "aTalk (Jabber/XMPP)" is already available at Google Play (source on GitHub), which includes audio/video (encryption with zrtp) and chatting (encryption with both OTR and OMEMO!)
currently too many clients & protocols out there (Signal etc), I hope that XMPP remains ...

@wiktor-k
Copy link

@wiktor-k wiktor-k commented Nov 22, 2018

Last time I checked aTalk (and that was a long time ago) it was barely usable. Actually it was unusable as even sending simple messages crashed the app :-/

@stevenroose
Copy link

@stevenroose stevenroose commented Nov 22, 2018

@vanitasvitae
Copy link

@vanitasvitae vanitasvitae commented Nov 22, 2018

I'm sure aTalk can need some contributors ;)

@cmeng-git
Copy link

@cmeng-git cmeng-git commented Nov 23, 2018

aTalk is working well now even for Android 9.0 (Pie) or API-28 . Earlier releases of aTalk was not fully compatible with API-27 and above. Please feedback to me if you still see problems.

You may refer to http://omemo.top/ and aTalk online https://atalk.sytes.net

@wiktor-k
Copy link

@wiktor-k wiktor-k commented Nov 23, 2018

@cmeng-git, I just re-tested aTalk and indeed it works a lot better than before! Audio call works, video didn't (camera permission granted but in settings it just says No camera device found 😢). OMEMO messages could have type="chat" so they don't pop out in windows in Gajim (non-encrypted messages have that and work OK).

All in all aTalk looks really good now, I'll definitely keep an eye on it!

@cmeng-git
Copy link

@cmeng-git cmeng-git commented Nov 24, 2018

@cmeng-git, I just re-tested aTalk and indeed it works a lot better than before! Audio call works, video didn't (camera permission granted but in settings it just says No camera device found ). OMEMO messages could have type="chat" so they don't pop out in windows in Gajim (non-encrypted messages have that and work OK).

All in all aTalk looks really good now, I'll definitely keep an eye on it!

wiktor-k: Can you sent the debug log for my investigation on camera issue

type="chat" => Has just fixed in aTalk, but not sure if vanitasvitae should include this fix in Omemo Message instead i.e. Message sendMessage = encryptedMessage.asMessage(toJid);; the type is not defined in sendMessage.

By the way can we take the discussion off Jitsi thread - the jitsi team may have some concern.

@Neustradamus
Copy link

@Neustradamus Neustradamus commented Jan 5, 2020

We are in 2020, any news on it?

@vanitasvitae
Copy link

@vanitasvitae vanitasvitae commented Jan 5, 2020

@Neustradamus we are in 2020, where is your PR?

@ccoenen
Copy link

@ccoenen ccoenen commented Jan 5, 2020

calibrates time machine shit. wrong year.

@playforvoices1
Copy link

@playforvoices1 playforvoices1 commented Mar 25, 2020

Would also interested in to see OMEMO support in jitsi. Any updates?

@smith476
Copy link

@smith476 smith476 commented Mar 25, 2020

@damencho
Copy link
Member

@damencho damencho commented Mar 26, 2020

@Neustradamus did the license change?

@lovetox
Copy link

@lovetox lovetox commented Mar 26, 2020

There is no license anymore, the whole crypto approach is now specified, so one can search librarys that support the primitives and implement the crypto themself.

@Neustradamus
Copy link

@Neustradamus Neustradamus commented Mar 26, 2020

@damencho: XEP has always like it, in 2020: "© 1999 – 2020 XMPP Standards Foundation"

@damencho
Copy link
Member

@damencho damencho commented Mar 26, 2020

Sorry @lovetox @Neustradamus, I was talking about https://github.com/igniterealtime/Smack/blob/master/documentation/extensions/omemo.md
If you want to use OMEMO in a GPLv3 licensed client, you can use the smack-omemo-signal Smack module that is not compatible with Apache license, but if anybody is willing to implement it under another license, you are welcome to open a PR which will be reviewed.

@alexanderadam
Copy link

@alexanderadam alexanderadam commented Mar 26, 2020

@Neustradamus you are mixing things up here. The XEP-0384 is just the protocol reference. As far as I know you could do an implementation and license this implementation in whatever you want. So this is not the point here.

I'm sure Дамян just asked because Smack was once proposed. Smack is one(!) of those OMEMO implementations(!). But if you want to use Smack in one of your projects, it must to be licensed under the GPLv3 or compatible (like Apache).

There are other OMEMO libraries that should be compatible though. For instance the OMEMO library jomemo which uses the Apache license.

@lovetox
Copy link

@lovetox lovetox commented Mar 26, 2020

The license situation has not changed for smack-omemo-signal, but the XEP now specifies how the crypto works so so its not necessary anymore to depend on code that uses libsignal, someone can now look at the spec and impl the crypto themself in a new library which can be licensed under whatever license the creator wants, after that someone can use that library in the smack plugin and drop smack-omemo-signal

@vanitasvitae
Copy link

@vanitasvitae vanitasvitae commented Mar 26, 2020

I deliberately designed Smacks OMEMO support with an eventual drop-in replacement of libsignal in mind. While smack-omemo is not yet updated to 0.4.0 (there are some changes needed and all in all the module could use some love), it is totally possible to replace libsignal with another double ratchet library.

@damencho
Copy link
Member

@damencho damencho commented Mar 26, 2020

Nice, good to know. Anyone willing to do it, just ask me questions for little guidance, I can help. But for now, I haven't heard of anybody willing to do the work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.