Add OMEMO encryption [$100] #63
Comments
|
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. |
|
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 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. |
|
edhelas not to belabor the point but there is also this jappix/jappix#305 |
|
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. |
|
There is a quite new encryption "method" designed for instant messaging, currently implemented in conversations android app: It's worth a lock. |
|
+1 for implementing OMEMO instead of OTR. |
|
I'm currently having a look at a possible OMEMO implementation in Movim. |
|
Any updates on this or areas assistance would be wanted in? |
|
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. |
|
Do you mean that there is no possibility to store user's keys/fingerptints? |
|
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. 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. |
|
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. |
|
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). |
|
Hey @iNPUTmice, just wanted to ping you on this thread so you know about the OMEMO implimentation discussion going on. |
|
What are the advantages of single session for all devices? |
|
@edhelas So what we need is a client side javascript OMEMO implementation? |
|
@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 |
|
@edhelas That said Movim is still a great step towards that. Will definitely come for inspiration. Take care. |
|
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? |
|
I'm definitely closing this ticket. If you still want to talk about it, please join us on our chatroom : movim@conference.movim.eu. |
|
Reopening the ticket. I'll give more information about it soon. |
|
It is totally absurd talking about end-to-end encryption and doing it "on the server". |
|
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. |
|
It's really hard to not call him an idiot. Nice cartoon nevertheless :-) |
|
@joe-average-user I'd prefer to not give bad names to eachothers :p |
|
OMEMO or Oh-Meme-Oh :D?
|
|
@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. |
|
It is like Duke Nukem Forever ah ah Solution: There are other XMPP web intefaces with OMEMO :) |
|
In my company no code after 3 months means a
project is plain dead and is dropped.
Can you do me a favour and ask one of your company representatives what the average salary of their employees is? If they agree that $100 matches approx. 6 full-time days of developer work, I would very much like to see both your developers and your company representative for a group photo. If they don't, please either stop such comparisons or get @edhelas and me those 6 full-time days' salary and we will most certainly get OMEMO ready before end of the year.
In any case, I did not tell you to shut up. I asked you to not interfere *with the Debian packaging of PHP dependencies*. This is somewhere near 10% of the efforts of this project, and if you have the resources to do the remaining 90%, noone stops you from anything and I am looking very much forward to your timely implementation.
|
|
In times of EU GDPR asking publicly for a photo is somewhat odd :-) @Neustradamus: how about posting a hint to these/this other web interface(s)? |
|
In times of EU GDPR asking publicly for a photo is somewhat odd :-)
How does GDPR have any opinion on someone asking you for a meeting to take a photo, and how does it have an opinion on photos whatsoever if taken for private purposes :-)? (I know you are joking, but the inflatious abuse of GDPR as a buzzword somewhat spoils such jokes)
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?
Only that we are talking about Debian sid, which is more or less a rolling release distro, and neither Arch nor Gentoo having the required packages :D.
|
|
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 ... |
|
There are also PECL packages, Docker images, snaps, flatpaks, PPAs, COPR, AUR, other distributions. Why should we be limited only yo what Debian provides? |
|
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.) |
|
@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. |
|
XEP-0384: OMEMO Encryption has been updated to 0.7.0: OMEMO 0.4.0+ breaks all:
The minimum is to have compatibility with 0.3.0 and 12 byte-IV. |
Just read the issue, and even if I'm not sure if that was irony or not but 100$ is, maybe, 1 billed hour of freelance full-dev time not nearly one week.. To arrive straight to the point instead of complaining the people interested should:
Because what is plainly misunderstood with FOSS, is that while the software might be free, the time of people behind that is not and they basicly donating that time to you. Just a thought. |
|
I'm pushing an early OMEMO implementation branch. With the financial help of NLNet and a specific architecture it seems that OMEMO is finally coming to Movim ;) I was able to send and receive encrypted message with other XMPP clients without doing any encryption server side. More information soon! |
|
Good news, thanks NLnet! |
|
I merged the #983 branch. It's an early working version, there is still bugs and weird behaviors but the one-to-one OMEMO chat works :) So now, let's |
|
As OMEMO is now part of Movim master and that the main working features are working I'm considering this ticket as solved. It took 6 years but Movim is finally having end to end encryption. |
|
OMEMO has been added in Movim 0.20! Announcements:
|
and others
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.
The text was updated successfully, but these errors were encountered: