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

Add OMEMO encryption [$100] #63

Open
cart opened this issue Oct 20, 2015 · 66 comments
Open

Add OMEMO encryption [$100] #63

cart opened this issue Oct 20, 2015 · 66 comments
Assignees
Labels
Milestone

Comments

@cart
Copy link

@cart cart commented Oct 20, 2015

I haven't seen end to end encryption mentioned anywhere. For an organization claiming "Our first aim is to protect your privacy" this seems like an important feature. Have you considered implementing XEP-0027? Conversations (the android app) supports it.

@edhelas
Copy link
Member

@edhelas edhelas commented Oct 20, 2015

There's a bounty on BoutySource here https://www.bountysource.com/teams/movim/issues?utm_source=Movim&utm_medium=shield&utm_campaign=bounties_received

Implementing OTR in Movim is really-really tricky because I have to keep the sessions open, even if you reload the pages, something that people do all the time. Other clients don't have this issue because they are running everything in the same "process". So it's definitely not plan yet in Movim. Also OTR has some serious compatibility issues with XMPP (like handling properly the different resources, the history…).

XEP-0027 is Obsolete actually.

@edhelas edhelas added the enhancement label Nov 7, 2015
@ghostofkendo
Copy link

@ghostofkendo ghostofkendo commented Nov 12, 2015

It would be great to have end-to-end encryption in Movim.

Although it's somewhat different from Movim, Salut à Toi has OTR support: http://repos.goffi.org/sat/file/8cc7d83141a4/src/plugins/plugin_sec_otr.py
Maybe you could use SàT's implementation as inspiration for Movim?

Also, regarding the difficulty to correctly implement OTR with XMPP, you could perhaps start with a first minimal version without resources support (e.g. an OTR-encrypted conversation is only valid for the resource used to start it), etc.

@marxistvegan
Copy link

@marxistvegan marxistvegan commented Nov 20, 2015

edhelas not to belabor the point but there is also this jappix/jappix#305

@edhelas
Copy link
Member

@edhelas edhelas commented Nov 21, 2015

Like I said in my previous comment Jappix run in an unique tab so there is no issue to use OTR.js, which is not the case for Movim.

@edhelas edhelas closed this Jan 9, 2016
@edhelas edhelas reopened this Jan 10, 2016
@mulles
Copy link

@mulles mulles commented Jan 11, 2016

There is a quite new encryption "method" designed for instant messaging, currently implemented in conversations android app:
https://en.m.wikipedia.org/wiki/OMEMO_(encryption)

It's worth a lock.

@dkellner
Copy link

@dkellner dkellner commented Jan 23, 2016

+1 for implementing OMEMO instead of OTR.

@heyimgay
Copy link

@heyimgay heyimgay commented Jan 27, 2016

I'd look to cyph for inspiration, specifically their websign solution to guaranteeing trust after the initial visit.

@edhelas edhelas added this to the 0.9.1 milestone Mar 30, 2016
@edhelas edhelas self-assigned this Mar 30, 2016
@edhelas
Copy link
Member

@edhelas edhelas commented Mar 30, 2016

I'm currently having a look at a possible OMEMO implementation in Movim.

@edhelas edhelas removed this from the 0.9.1 milestone Apr 7, 2016
@bb010g
Copy link

@bb010g bb010g commented Jun 28, 2016

Any updates on this or areas assistance would be wanted in?

@edhelas
Copy link
Member

@edhelas edhelas commented Jul 24, 2016

Just to keep you updated about this ticket. Movim current architecture is making the implementation of OMEMO (or OTR) quite impossible if I want to do it "right" (without storing risky stuff on the server). So I have no plans to do it for now to do it but I leave the ticket open.

@MRZA-MRZA
Copy link

@MRZA-MRZA MRZA-MRZA commented Jul 24, 2016

Do you mean that there is no possibility to store user's keys/fingerptints?

@mulles
Copy link

@mulles mulles commented Jul 25, 2016

Thanks for sharing. May you elaborate what the technical challenges/s is/are.

Maybe endtoend encryption is meaningless, when you don't have at least one save place which is permanent to store the password/key needed for encryption.
This seems very hard when you are using ANY webbrowser on ANY computer, but the android app may be capable of.
One could use a new key for every session and safely delete those. If futhermore you want to have message history, the only possibility I see is to save the messages unencrypted and only send them encrypted.

At the end one must say that endtoend is sercurity on top, which is always good, but needs more effort. I say "On top", because if you trust your proper server and the one to whom you send your message the message transfer is already encrypted the whole time when it passes entites you can't trust, as you may not even be able to know them. Thus, this nice decentralized technology can be deployed now, when everybody thinks well when choosing a server.

@rhz
Copy link

@rhz rhz commented Jul 26, 2016

Perhaps end-to-end encryption could be done using PGP like they do in ProtonMail? The idea would be that everything gets stored on the server encrypted and then it's decrypted by the client (the web ui) using javascript and a second password.

@edhelas
Copy link
Member

@edhelas edhelas commented Oct 13, 2016

To give a small update here. I've made some try and research regarding E2E encryption in Movim and the current architecture definitely doesn't allow it to be done in a "secure" way. Movim is handling the XMPP connection in PHP and deliver a unique session to several tabs/devices at the same time (on most of the others clients everything is done on one device/computer).
So basically I can't handle a OMEMO/OTR session (that should be done on a device) this way.

@herbsmn
Copy link

@herbsmn herbsmn commented Oct 14, 2016

Hey @iNPUTmice, just wanted to ping you on this thread so you know about the OMEMO implimentation discussion going on.

@MRZA-MRZA
Copy link

@MRZA-MRZA MRZA-MRZA commented Oct 14, 2016

What are the advantages of single session for all devices?

@louy2
Copy link

@louy2 louy2 commented Oct 15, 2016

@edhelas So what we need is a client side javascript OMEMO implementation?

@edhelas
Copy link
Member

@edhelas edhelas commented Oct 15, 2016

@MRZA-MRZA the architecture of Movim allow him to be used as a "simple website" this means that using a unique cookie, you can open several tabs that will be connected to the same session in the backend. This behavior has been extended in 0.8 to share the same session not only between tabs, but also between browsers (basically your Android phone, your desktop Firefox and your Electron desktop app are sharing the same session cookie and then are perfectly synchronized). That's why Movim can be considered as a "light-client" (and Jappix a "heavy-client"), all the processing and session handling is done server side, the browsers are just displaying the result.

This also means that the XMPP session and processing is done server-side. The end-to-end encryption protocols are always designed with the idea that "where the message is send/arrive" = "where the message is encrypted/decrypted". This is not the case with Movim. A copy of the messages are stored, unencrypted, in a database (that way you can reload the page, do pagination… ). If I respect the OMEMO/OTR rules, I could encrypt/decrypt them on the server but this means that they still will be saved and sent in plain text to the browser (with HTTPS on top), so basically it's not end to end anymore.

Now let's say that the encryption layer is done in JS, in the browser. Because here we could have several tabs/browsers opened on the same "Movim session" they will not share the same OMEMO/OTR keys/status. Also if you reload the page I'll have to sync the current status somewhere to be sure that I'm not loosing something on the line.

Now imagine that I can successfully do that (which I doubt seriously) and I can decrypt a message in my browser, where can I save it to handle correctly the history ? The current Movim architecture is designed to save all the messages in the server SQL database ? So I'll create a second place to save only the "OMEMO/OTR" messages ? What if I also have unencrypted messages in between (that are coming from the SQL database)… If I send them back to the server SQL database, there's no point of doing this (because the Movim pod will have an unencrypted version), if I don't save them and if you reload your page, you will basically loose your history.

I know that OMEMO is solving most of the issues that OTR had (especially to handle E2E sessions using several XMPP clients at the same time), but it was always designed in a way that the encryption/decryption layer is done at the same place where the XMPP session is handled and where the messages are stored. Movim doesn't have this architecture (and it's not going to have it).

When I'm saying that it's not possible I don't want to tell you that I just don't want to do it because I'm lazy or because it's too difficult. I'd really like to have a nice and standard E2E encryption implementation in Movim like all of you. Just that I prefer to be clear about this point better than having an implementation that is not-secured because I had to do some comprises to do it.

Also, if you really want to do E2E encryption on your XMPP account, Movim doesn't forbid you to use another client to do it, that's the power of XMPP :p

P.S.: @iNPUTmice correct me if I said something wrong or if I totally missed something about this topic

@louy2
Copy link

@louy2 louy2 commented Oct 15, 2016

@edhelas
I see Movim is not a conventional XMPP IM app, which is what excited me to check it out. But part of the reason I am excited about an XMPP SNS is because the E2E crypto XMPP provides may enable a better privacy structure. So as I totally understand the situation, I can't help but feel a bit sad.

That said Movim is still a great step towards that. Will definitely come for inspiration. Take care.

@rhz
Copy link

@rhz rhz commented Oct 15, 2016

What about storing the messages encrypted in the server and using a second password as a master key to decode the encrypted messages in the client?

@edhelas
Copy link
Member

@edhelas edhelas commented Nov 5, 2016

I'm definitely closing this ticket. If you still want to talk about it, please join us on our chatroom : movim@conference.movim.eu.

@edhelas edhelas closed this Nov 5, 2016
@edhelas
Copy link
Member

@edhelas edhelas commented Jan 20, 2017

Reopening the ticket. I'll give more information about it soon.

@edhelas edhelas reopened this Jan 20, 2017
@ghost
Copy link

@ghost ghost commented Apr 21, 2019

Any progress?

@Natureshadow
Copy link
Contributor

@Natureshadow Natureshadow commented Apr 21, 2019

@Natureshadow
Copy link
Contributor

@Natureshadow Natureshadow commented Apr 21, 2019

So, let's see:

  • protobuf: I just submitted a patch to build the PHP package in Debian, but it is also available from composer - PECL extension is not needed
  • crypto: Do you mean bukka/php-crypto (an experimental OpenSSL binding library)?
  • curve25519: This one? mgp25/curve25519-php
@edhelas
Copy link
Member

@edhelas edhelas commented Apr 22, 2019

Basically the idea would be to use https://github.com/mgp25/libsignal-php :)

@joe-average-user
Copy link

@joe-average-user joe-average-user commented Oct 13, 2019

I would like to use movim as webclient for xmpp. Unfortunately most of the people I chat with use OMEMO. So at the current stage movim does not make a lot of sense for me. Nevertheless I read the issue and understand the authors' basic concerns of not really being end-to-end encryption based on the whole concept of movim.
Nevertheless I would like to speak up on the issue. I have years experience in ISP business and had to learn that most endusers have few - not to say no - control over their own PCs. Basically they click on every "confirm" button that pops up. Of course I don't say that it a good way to work on a home PC, but one has to understand that there is merely no knowledge about internet, ip, http, java, javascript and all the other things needed for using a PC today at all.
Which leads me to this statement:
dear author, please assume that the security on a webserver no matter who set it up, is for sure better than on any enduser PC with a local end-to-end encrypting app. And don't forget that the ones not being satisfied by a webclient with its drawbacks can still ommit it and use their favourite client software. That's the good thing about an open standard like XMPP.
I can assure you there is currently no web client for XMPP with useable OMEMO encryption available, and it would be great if you can movim the first one.
All infos on omemo.top about web clients supporting it are plain wrong. As an example lets name converse.js which does omemo on text messages but not on any binaries sent. And believe me, it won't in the future. That's not a useable implementation for standard users. Most of them have seen the pretty astonishing Conversations app (android) and are not content with any less.
Hope you can do it!
Thanks for your work

@Natureshadow
Copy link
Contributor

@Natureshadow Natureshadow commented Oct 13, 2019

@joe-average-user
Copy link

@joe-average-user joe-average-user commented Nov 28, 2019

How are things going in this issue?

@deuill
Copy link

@deuill deuill commented Nov 29, 2019

Is there a public branch we can follow? I can help push this over the edge, if there's a clear plan for the implementation.

@edhelas
Copy link
Member

@edhelas edhelas commented Nov 29, 2019

I'm still waiting for the dependencies to be there to start to work on it :)

@joe-average-user
Copy link

@joe-average-user joe-average-user commented Nov 29, 2019

Can you name what is missing? I try to look after that then ...

@Natureshadow
Copy link
Contributor

@Natureshadow Natureshadow commented Nov 29, 2019

@edhelas
Copy link
Member

@edhelas edhelas commented Dec 3, 2019

@Natureshadow it seems that there's another way to add OMEMO within Movim.

Since PHP 7.4 (that was released a few days ago) you can map C libraries to PHP (https://www.php.net/manual/en/book.ffi.php). It would then be simple for me to map the C libsignal library (that is already in the repos) to PHP and simply use it in Movim.

It's still some big guesses that I'm making, but I'll have a look as soon as PHP 7.4 lands in the testing repos ;)

Cheers

@Natureshadow
Copy link
Contributor

@Natureshadow Natureshadow commented Dec 3, 2019

@apimon
Copy link

@apimon apimon commented Dec 9, 2019

It is totally absurd talking about end-to-end encryption and doing it "on the server".
Dangerous nonsense.

@edhelas
Copy link
Member

@edhelas edhelas commented Dec 10, 2019

Wow damn, guys, lets STOP EVERYTHING. Looks like we overlooked that E2EE on Movim will have to be done "on the server".

I'm glad that we noticed that after 5 years of discussion in this open ticket.

@joe-average-user
Copy link

@joe-average-user joe-average-user commented Dec 10, 2019

It's really hard to not call him an idiot. Nice cartoon nevertheless :-)

@edhelas
Copy link
Member

@edhelas edhelas commented Dec 10, 2019

@joe-average-user I'd prefer to not give bad names to eachothers :p
Whatever, let's go back to this OMEMO topic, shall we :D ?

@Natureshadow
Copy link
Contributor

@Natureshadow Natureshadow commented Dec 10, 2019

@joe-average-user
Copy link

@joe-average-user joe-average-user commented Dec 20, 2019

@edhelas well, I'd love to, but after 4 completed years of no real action and after more or less being told to shut up by @Natureshadow because "he is working on it" I have very low expectations. Maybe we have quite a different method in software development (which I do for about 35 years now). In my company no code after 3 months means a project is plain dead and is dropped.

@Natureshadow
Copy link
Contributor

@Natureshadow Natureshadow commented Dec 20, 2019

@joe-average-user
Copy link

@joe-average-user joe-average-user commented Dec 20, 2019

In times of EU GDPR asking publicly for a photo is somewhat odd :-)
Nevertheless, debian is not the only distribution available. If you want to use the latest versions of something maybe you are better off with a rolling release distro like arch linux anyway?

@Neustradamus: how about posting a hint to these/this other web interface(s)?

@Natureshadow
Copy link
Contributor

@Natureshadow Natureshadow commented Dec 20, 2019

@joe-average-user
Copy link

@joe-average-user joe-average-user commented Dec 20, 2019

Iff the stuff you want to use already exists, why don't you compile it yourself (which is more or less anyway what e.g. gentoo does) and implement the movim features, so that when someday your packages are available for the distros movim can already use it? This way there is no time lost waiting for Godot ...

@Dragnucs
Copy link

@Dragnucs Dragnucs commented Dec 21, 2019

There are also PECL packages, Docker images, snaps, flatpaks, PPAs, COPR, AUR, other distributions. Why should we be limited only yo what Debian provides?

@Natureshadow
Copy link
Contributor

@Natureshadow Natureshadow commented Dec 22, 2019

I am not convinced the discussion about whys will lead anywhere. I can assure you that Movim lacking OMEMO support is a huge issue for me as well, and both @edhelas and I are working on it with the best efforts we can (while also waiting for your PR, of course - again, if you think you can do it now, please do it.)

@Dragnucs
Copy link

@Dragnucs Dragnucs commented Dec 23, 2019

@Natureshadow I cannot do it and donnot have enough time to learn how to do it. XMPP has its challenges.

I, like many others, switched to other thechnologies supporting end to end encryption, matrix for instance.

For now, I am just trying to discover solutions.

@edhelas edhelas modified the milestones: 0.15, 0.19 Oct 1, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Linked pull requests

Successfully merging a pull request may close this issue.

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