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 support for OMEMO Encyrption #540

Open
Flowdalic opened this issue Sep 7, 2015 · 88 comments
Open

Add support for OMEMO Encyrption #540

Flowdalic opened this issue Sep 7, 2015 · 88 comments

Comments

@Flowdalic
Copy link

Flowdalic commented Sep 7, 2015

The offspring of this years GSOC XSF projects is OMEMO. An axolotl and PEP based open standard for end-to-end encryption. Would be great to see support for it in Xabber.

XEP: XEP-0384: OMEMO
Related Smack issue: SMACK-743
ProtoXEP: http://conversations.im/xeps/multi-end.html
More info: http://conversations.im/omemo/

@TurkeyMan
Copy link

Finally, security has arrived in IM without compromise. Please add this protocol! I will switch back from Conversations when it comes.

@Buntbart
Copy link

Buntbart commented Sep 8, 2016

+1

@ghost ghost mentioned this issue Oct 18, 2016
@falsefifth
Copy link

+10

@vanitasvitae
Copy link

I'm working on an OMEMO Smack module as part of my bachelors thesis, so Xabber might use this in the future.

@imp1sh
Copy link

imp1sh commented Jan 23, 2017

yes, please support OMEMO in xabber.

@climf
Copy link

climf commented Mar 1, 2017

Thanks for all the fish, but the addition of this fish would be more better.

@vanitasvitae
Copy link

I'm considering to implement OMEMO in Xabber using smack-omemo and smack-omemo-signal. How can I get further in touch with you?

@tdemin
Copy link

tdemin commented Oct 8, 2017

Looks like smack-omemo has been implemented, any progress on it in Xabber?

@andrewnenakhov
Copy link
Member

We have some other more immediate plans. We have 100% confirmation that at least 80-90% of Russian Xabber users use it for buying drugs. And since our crowdfunding campaign goes rather slow,we... Let's say, not too interested into stretching ourselves and give one more encryption method for this cathegory of users. In fact, we are considering removing Xabber from Russian play store at all,we have some very unwanted attention from authorities because of OTR, but to add yet more to it... No. Definitely not now.

If patreon campaign will reach certain milestones,maybe.

@Buntbart
Copy link

Buntbart commented Oct 8, 2017

Can you explain how unwanted attention by authorities is affected by crowdfunding efforts?

@rugk
Copy link

rugk commented Oct 8, 2017

Not good. Time to setup a warrant canary, is not it?
Also with this background the crowdfunding campaign will certainly not go faster… if we have to fear interference of some authorities.

Also, you hopefully know that this argumentation is definitively crap. And unless you track your users (which I don't think so) you cannot know what your users are doing with your messenger. So where did you got this number?

@andrewnenakhov
Copy link
Member

@Buntbart that's easy. On one hand we have some difficulties with authorities who vaguely threat they can destroy my business in an instant (it's very easy in russia. police just storms the office, takes away all computers, returns it after 3 years, if ever, end of story). On the other we have an audience of users who constantly moan of a feature I don't personally need at all, and pay me nothing. If we put these two together, a clear solution is to screw Russian audience, I don't really care what client they will use.

@rugk this argumentation is based on facts. Over the years we have seen just so many help requests on our email support in so many languages, requests in Russian stands out in it by some very unusual metrics rarely present in other groups - phony names and inadequate requests, users clearly have no idea how XMPP works. Plus we've recently launched our own XMPP service that requires users to provide name and surname. And guess what, out of several thousands registrations Russian locale names and surnames once again look very... different from Germans.

So, since I have zero sympathy for junkies, and Russian audience is proving to be worthless to me, while giving me some headache. So, I think we'll be removing Xabber from Russian Google Play.

And once again on OMEMO: so far I'm the only one who paid for development of Xabber, I had some spare money to create an app that I like. I like current Xabber, and I have some plans to redesign it to make it even better looking. I have some plans to create several protocols to make XMPP work much better on mobile devices. I have some plans to bring Xabber for Web to many desktop platforms with Electron framework. I have some plans for all these versions of Xabber to work seamlessly with one another, so you can pick up your conversation on phone after chatting on desktop. That what I want and what I'm paying developers for.

What I don't want is OMEMO, it's worthless to me. And since I'm a bit out of spare money, I have to make Xabber a viable source of income, I have some Ideas how to do that, and OMEMO does not play into any of these ideas. If some of you want this feature badly, pay me a for development of it (we charge $3500 per developer man/month). If you are not willing - well, sorry, we serve only customers, not freeriders.

I actually don't understand this desire for encryption. Some ejabberd developer recently said in email group that XMPP community is affected by severe crypto-cancer, and I fully agree with him. For most uses, OTR or OMEMO just gives user an illusion of safety, not really meaningful increase in it. If you want your messages to be safe, you can just run your own server, that's easy and rather cheap. Just be wary of certificate errors.

TL,DR: OMEMO is for junkies and crypto-nerds who pay us nothing, get lost, or pay.

@imp1sh
Copy link

imp1sh commented Oct 8, 2017

It's sad to hear that you have problems with the authorities. Don't let them oppress you if you didn't do anything wrong.
On the other hand there are normal people - who don't use this to deal drugs - who just want their privacy to be protected and also have some convenience. That what's OMEMO is all about.

@andrewnenakhov
Copy link
Member

@imp1sh convenience... For me, convenience is using multiple devices, syncing history between them, making in searchable, etc. You can have all of that by running own server, that's not too hard or costly. And with OMEMO, once chat is encrypted, you cant' search it, you can't really sync it, etc. - and if you somehow can, then it means that you have an illusion of safety, not better safety.

My endgoal for Xabber, is to make XMPP messaging as ubiquitous for instant messaging as email. But to fight Telegram or Whatsapp we need to bring a knife to a knife fight, and OMEMO is hardly that knife. I don't really mind it's addition to Xabber, but, well, someone better pay for it. Btw, OTR was added on precisely same terms - some guy from Moscow volunteered and paid for our initial expenses developing OTR encryption back in 2013 (or 2012? don't remember... )

I prefer to receive payments with bitcoin. Oh, if you ask me, integration to send bitcoin is more essential for Xabber than OMEMO.

@schiessle
Copy link

schiessle commented Oct 8, 2017

And with OMEMO, once chat is encrypted, you cant' search it, you can't really sync it,

How do you come to this conclusion? With OMEMO and Message Carbons (XEP-0280) I can have encrypted chats synced to all my devices, i can switch seamlessly between the clients during a chat and on all devices I can search the chat history just fine.

@andrewnenakhov
Copy link
Member

@schiessle login from new device and try searching your history like you do on telegram. Client-side search is fail. Anyway, I don't mind you doing a PR with this functionality, we'll test it and accept it in project if it's done well. I don't get it why you all want me to work for free so you can have convenient OMEMO in your device. I don't need or want OMEMO, so I have very little incentive to pay for development of OMEMO. Isn't it fair to be paid by those who actually want it? Anyway you all have free alternatives.

Also, message carbons is NOT sufficient to fully sync messages. You at least need to use an archive on server to catch up with those messages sent while you were offline (offline messages will not do if you had 2 devices offline- only one of them will receive offline messages, other will have nothing without archive).

@schiessle
Copy link

I don't get it why you all want me to work for free so you can have convenient OMEMO in your device. I don't need or want OMEMO, so I have very little incentive to pay for development of OMEMO. Isn't it fair to be paid by those who actually want it?

Nothing wrong with that. And I don't want to force your to do anything. Just want to challenge your assumption about OMEMO encryption.

@andrewnenakhov
Copy link
Member

@schiessle my assumption is that heavy lifting should be done by server (client-centristic mentality has already cost XMPP it's potential place as a mainstream messaging protocol). If server does not know contents of messages, it can't search it.

Also, if you store ALL you history on device, instead of small portion of recent messages, well, if your device gets seized, guess what happens? all your history belongs to them, so much for 'security'. Better way would be having a trusted server and having just an immediate portion of your history on device, while accessing more distant history with PIN checked by server. But with this crypto-cancer in community it'll hardly happen anytime soon.

(I'd order implementation of server-side search in Xabber in no time, if I had any server available that would support such feature)

@rugk
Copy link

rugk commented Oct 8, 2017

Please keep to the facts:

  • Your link about "crypto cancer" is about server-to-server SSL connections as far as I see. Also what drives users away according to the comment is spam. (That was taken out of context. Read: "Spam is a bigger problem that missing s2s encryption." Actually as far as I understand the user replying meant: In the XMPP community there is crypto cancer, because many people still do not want to use s2s encryption.)
    So if you quote stuff, please make sure it fits into what you actually want to prove and don't twist the facts. As far as it goes the topic was not about e2e crypto at all.
  • I feel like you have no (correct) information about OMEMO/how OMEMO works. In short: OMEMO is far better than OTR. See this page.. TL;DR: In contrast to OTR it actually allows you to use multiple devices, search your messages, send messages when the other is not online, etc.
  • The thread model you describe in the last comment is solved very simple: Encrypt your messages locally (i.e. full disk encryption). When the messages are stored on the server and someone gets your device, they can also just instantly download all the old messages. Saving (unencrypted) messages on servers only saves space on the client and makes it easier for authorities to scan messages when they seize a server. (Because if you run your own server, they could also seize your server instead of your local device.)
    TL;DR: Only encryption helps. (whether it is FDE on the local device, or server or something like OMEMO)

What I agree with is that people can of course support you, if they want to have a good coverage of OMEMO clients and want this feature. Especially as it is not easy to implement. (You certainly need to find a library for it, as otherwise you can do too much wrong in the crypto.)

▶️ So anyone who wants this feature, here is a BugBounty: Xabber – Add support for OMEMO Encyrption Support it or use another client software, which already has OMEMO support. That are your choices.

@andrewnenakhov
Copy link
Member

andrewnenakhov commented Oct 9, 2017

@rugk facts are:

  • crypto-cancer has taken over all XMPP community, especially users who do not program anything themselves, they just want it for no real reason but their paranoia. It's not only about s2s connections, it's about 'let's encrypt everything'. That link is just one example of this. This thread is another. Dozens of frequent requests 'do us OMEMO' in our email is another. We'd do OMEMO if these requests were based on something more than endless moaning
  • client-side search is fail, I tell you once again.
  • you do not read what I say above. Search for word PIN and read once more. Yes, server should be updated for such security model. But securing data on device is infinitely harder and less reliable than on server

OTR or OMEMO solves only one security problem - if you don't trust your chat provider, because the only real advantage it gives you over unencrypted messaging is that XMPP.org admin can read your messages. If you have your own server, this risk goes away. Yes, it requires some efforts to maintain server, but you want security or illusion of security? Unlocking your device without your consent is much easier than unlocking server.

What is particularly hilarious with this XMPP crypto-cancer is that all these folks who email me about how essential is encryption for messaging usually email me via gmail.com

TL;DR: please, stop trying to convince us to implement OMEMO. We know what it is. We don't want it for now, because we have limited resources that we prefer to put on things we believe more important for Xabber. If you want us to divert resources in direction you want, we have commercial rates for such work. Thank you for your attention and interest in our project.

@schiessle
Copy link

OTR or OMEMO solves only one security problem - if you don't trust your chat provider, because the only real advantage it gives you over unencrypted messaging is that XMPP.org admin can read your messages. If you have your own server, this risk goes away.

FWIW, not really unless you you chat only with people who have a account on the same server. Otherwise you don't know at which servers your messages end up. Also thhe argument "if someone hacks your device, he has complete access to the chat history" is also true for the server aka "if someone hacks your server (or one of your chat partners), he has complete access to the chat history"

@andrewnenakhov
Copy link
Member

@schiessle prime audience for the use of end to end encryption (drug addicts) are far more likely to have their device seized than their server.

@Buntbart
Copy link

Buntbart commented Oct 9, 2017

Thank you for the clear words. Then I know now that I don't have to wait for Xabber with OMEMO anymore and stay with Conversations, although I don't want to buy drugs at all.
Consistently, you might want to take OTR out so that Xabber becomes useless for junkies and the authorities leave you alone. OTR is certainly also one of the functions for junkies that you don't need personally. After that, you could take care of a nice surface in peace.

@andrewnenakhov
Copy link
Member

@Buntbart you know, every single junkie user I talked to said exactly the same. :-D

We certainly won't remove OTR functionality from Xabber - most likely we'll simply pull down Xabber with OTR from Russian Google Play store. Our authorities are luckily not too interested in foreign drug dealers and addicts. Then we'll possibly provide a "Xabber for Business" version without encryption for our normal Russian users (all seventeen of them)

And I'm not saying we won't ever support OMEMO - it's just not our first, second or third priority. Have you seen Xabber for Web? Creating a multi-platform chat app that works extremely well for federated chat, everywhere - that's what we are truly aimed at.

@vanitasvitae
Copy link

The way you talk about your users makes me feel really sorry for you :(

It feels like Xabber is really not the app I'd recommend to privacy aware users anymore. Neither because its encryption, nor the will of the devs to protect their users.

I respect that decision though and will stop bothering you anymore :)

@yurkobb
Copy link

yurkobb commented Oct 9, 2017

From xabber.com:

Xabber is secure. You may choose to encrypt your conversations. Say ‘no’ to David Cameron and his NSA/FBI/CIA/FSB friends!

You should probably change that to reflect you actual "priorities".

@andrewnenakhov
Copy link
Member

@vanitasvitae the only privacy-aware users we've encountered so far are junkies, drug dealers and encryption nerds like folks in this thread. Nerds comprise maybe 1 or 2% of users who are interested in data protection. Any yes, I think you would talk even worse of our users if you did get to read contents of our inbox on support email.

And I'm actually offended by your insinuations about our 'will of the devs to protect their users'. Luckily for us, we DON'T have any user data, and we clearly won't submit to installing backdoors or stuff to our app. However you CLEARLY don't understand dangers of such stance in Russia.

Linkedin is already blocked in Russia because it refused authorities access to user's data. Facebook will be blocked too if it won't submit. Viber has submitted too, so... it's either you are working in Russia and providing info or being blocked. Company like mine can be instantly seized by armed police, computers taken away, property sealed, company instantly bankrupted, I get jailed. Courts and laws don't really function in Russia, I might very well be sentenced for 'organizing a darknet criminal network to sell drugs and weapons', all because some crypto-nerds want OMEMO.

So we simply plan to put our users (even junkies, yes) out of danger to their data being compromised by pulling our app from our country play store.

(and to think I've personally spent more than $150k to listen to this.... how cool is that?)

@andrewnenakhov
Copy link
Member

@vanitasvitae don't wanna delete it, it's the most amusing part of this thread!

@ghost
Copy link

ghost commented Jun 3, 2018 via email

@vanitasvitae
Copy link

@heideline I'm sure your daughter can help you :) Please show her our discussion afterwards ;)

@Buntbart
Copy link

Buntbart commented Jun 3, 2018

What a bunch of nonsense! Developers want money in advance for code they don't want to write, don't think it makes sense and aren't allowed to offer. Then they accuse their more interested customers for the mistakes of overtaxed noobs and find that funny. Why is this discussion not simply closed if you do not want to fulfil this desire for OMEMO? By the way, thanks to Liberapay I donate regularly for the further development of my xmpp client. However, this is another app that OMEMO already masters and does not abuse its users as junkies. So, what am I doing here? Waiting for Godot? Goodbye!

@ghost
Copy link

ghost commented Jun 3, 2018 via email

@andrewnenakhov
Copy link
Member

@Buntbart earlier we differentiated users interested in encryption in two groups: junkies and cryptonerds. However, recently we came to a conclusion that there is also a subset of users who should rather be called cryptojerks. Now, please leave our issue tracker. Forever.

@ghost
Copy link

ghost commented Jun 3, 2018 via email

@andrewnenakhov
Copy link
Member

@heideline don't worry about that. Just send us email to support@xabber.com with details of your account.

@rugk
Copy link

rugk commented Jun 3, 2018

Wtf happened here? @andrewnenakhov could not you please delete the comments added by @heideline, which have this huge bunch of email stuff there?

And yeah, I'd also suggest to close this issue here. (maybe even lock it – it may be better 😉) You seem to not want to implement it, or better can't, because of the legal things discussed before, so leave it as it. Users wanting to use OMEMO should use a different client.

And I better unsubscribe this issue…

@samphunter
Copy link

Users wanting to use OMEMO should use a different client.

All users should use other client, as thankfully E2E encryption is finally starting to be enabled by default, so this client is starting to be incompatible with modern clients such as Conversations.

@andrewnenakhov
Copy link
Member

@samphunter yeah, Conversations users were very happy when they were forced to have that e2e bullshit forced on them. Processone even changed default config in so OMEMO encryption in Conversations wouldn't work out of the box in ejabberd.

@samphunter
Copy link

samphunter commented Jun 3, 2018

yeah, Conversations users were very happy when they were forced to have that e2e bullshit forced on them.

I was not Converastions user before OMEMO was turned on by default by I am one now and I am very happy that it is forced on users. Unfortunately not everyone cares about e2e and that is fine when two such people communicate. But it is a pain to explain to people how to configure and/or use it as a person who actually cares about privacy. So yeah, even companies like Whatsapp got the memo and enabled e2e by default. And XMPP, which should have been leading the charge is lacking behind, because all the developers can't agree about anything except basic message sending. Here it is OMEMO, Conversations don't want to implement eCards because I don't know... It is ridiculous. I am not surprised XMPP never caught on.

So yeah, you say it bullshit but you are exactly the kind of person who holds everyone back.

@andrewnenakhov
Copy link
Member

@samphunter if you care about privacy, run your own server and communicate within it. The only persons e2e helps against are admins of yours and your chat buddy's servers. But while encryption brings users a false sense of security it also breaks a lot of things that are really important in real life, like server-side history search and device convergence.

@samphunter
Copy link

samphunter commented Jun 3, 2018

But while encryption brings users a false sense of security

First of all, e2e if done right is the only thing that can even start to provide some security without unreasonable amounts of effort.

if you care about privacy, run your own server and communicate within it.

What would be the point? I would not trust myself to run it properly. All my friends would have to use my server or their own, both of which is impractical. The server can't be at my home because village internet and having it at a datacenter ruins the point.

it also breaks a lot of things that are really important in real life, like server-side history search and device convergence.

I really don't understand how it breaks device convergence and modern devices are powerful enough to run client-side searches, so who cares.

@andrewnenakhov
Copy link
Member

So you want to keep all your very safely transmitted messages decrypted on your pocket device? Lol. So if it gets lost, stolen or taken from you, whoever gets access to device will have all your data. So by trying to eliminate one security risk you introduce many others much more severe.

What you don't get is that security and convenience don't fit together well. Encryption nerds lull themselves to be safe because they pressed some magic buttons in some app, only to get hacked via some security hole totally not related to message encryption protocol. Heard about that recent Signal code injection bug?

@samphunter
Copy link

samphunter commented Jun 4, 2018

So you want to keep all your very safely transmitted messages decrypted on your pocket device?

First of all, if nothing else, FDE.

Second of all, what the hell is your point? Yes, if someone can walk up to me and get my device, they will get my messages, whether they are e2e encrypted or not as long as I store them. But for one, I can delete them and be reasonably sure they are deleted unlike with servers, which I can only hope they are doing something. And walking to me and taking my phone is a one time thing. They would probably need a probable cause and a warrant (law enforcement) or risk trying to robb me (other attackers). With unencrypted messages, they can monitor them long term and in bulk without any such extreme measures.

As for code injection bug, sure. How does not encrypting messages prevent that? Or should we just give up, because once in a while, there is a one time bug that almost no-one will be affected by?

E2E is not the final solution, it is a first step. I know that. But without the first step, all the other steps are pointless.

Also, just to illustrate I was thinking about the obtained/hacked device problem and how I think it can be mitigated to reasonable extent: https://github.com/siacs/Conversations/issues/557 Got shut-down as well though. But that is a problem for another day.

@vanitasvitae
Copy link

I don't get why you are still discussing. If you read the backlog, you can see that both sides already brought every point up against each other.

Xabber devs are not going to implement OMEMO in Xabber by themselves, no matter what great arguments you bring up.

If you want OMEMO in Xabber, fork it and do it yourselves :) Xabber is based on Smack and Smack does have a module for that.

@andrewnenakhov
Copy link
Member

First of all, if nothing else, FDE.

That can be quite routinely unlocked by any party that is really interested in getting what's inside. Encrypting database is a bit better, we do it for one of our customers.

Second of all, what the hell is your point? Yes, if someone can walk up to me and get my device, they will get my messages, whether they are e2e encrypted or not as long as I store them.

Point is that crypto-fetishists like the feeling of being secure, but when talking about providing themselves real security, nope, that's too hard to keep own server and control all communications.

You introduce many more security risks to disclosure all your preciousss data to a potential attacker (or thief) by carrying it with you all the time, but you choose to be oblivious to those risks, pretending instead that e2e is the final solution to privacy (while running this perfectly secure messenger on an Android phone). And because real security is too damn hard and requires discipline and dedication, users don't really want that, opting for a cosy feeling of being safe.

@andrewnenakhov
Copy link
Member

Xabber devs are not going to implement OMEMO in Xabber by themselves, no matter what great arguments you bring up.

@vanitasvitae money is good enough argument. I think we could do this for just 1₿ ;)

@samphunter
Copy link

samphunter commented Jun 4, 2018

but you choose to be oblivious to those risks, pretending instead that e2e is the final solution to privacy

I specifically said the opposite, that it is just the first step. And once more, attacks on server are many many times easier than on your phone. Especially considering nothing is stopping them to attack your phone anyway.

You introduce many more security risks to disclosure all your preciousss data to a potential attacker (or thief) by carrying it with you all the time

Having them on the server does not protect them unless you log out every time you close the app. It is irrelevant to whether e2e should be used, as this can be solved by encrypting the database.

Xabber devs are not going to implement OMEMO in Xabber by themselves, no matter what great arguments you bring up.

I honestly don't care much. I gave up on xabber as I wrote. I just thought I should reply here to prevent someone from buying the anti-encryption BS that is spreading around. E2E is not the whole solution, but it is certainly part of it. The most important first step, as while E2E does not provide perfect security by far, it decreases your attack surface massively.

@andrewnenakhov
Copy link
Member

And once more, attacks on server are many many times easier than on your phone.

Who told you that? Did you ever think that all your assumptions are based on wrong ideas?

Having them on the server does not protect them unless you log out every time you close the app.

It does if you care to do some things to prevent access to message history. We actually implemented it for one of our customers, who really cares about security, and does not only pretends to be caring like most folks here.

Speaking of spreading bullshit, that's exactly why I respond to all this massive outcry to encrypt everything instead of locking it down. Desire to encrypt everything is silly, and most sane developers know this, except those few who promote it as the main feature of their applications.

btw, I wonder if all emails on that Gmail mailbox of yours are encrypted too, or is your e2e crusade
targeted only at chats?

@samphunter
Copy link

samphunter commented Jun 4, 2018

btw, I wonder if all emails on that Gmail mailbox of yours are encrypted too, or is your e2e crusade
targeted only at chats?

I have PGP set up for email, but I practically never use it, because it is more convenient to switch to a secure IM. Using PGP for mail is just unreasonably hard and there is no reason not to use IM (use best tool for the job).

Desire to encrypt everything is silly, and most sane developers know this

Maybe I am not a sane developer, but I don't believe this. Maybe my assumptions are wrong or maybe yours are.

Did you ever think that all your assumptions are based on wrong ideas?

Yes, but I never found a flaw in them. But considering you seem to be knowledgeable on the topic, you can point out my error if you see any. Here are my asumptions:

  1. There is no practical way a server can improve security in case of device compromise beyond what encryption can do.
    Reasoning for that is: The only security feature reliant on server I ever heard of in connection with IM is protecting the chat history with additional passphrase. This can be done using encryption for example like this. Let Km be master key derived from sufficiently strong passphrase by sufficiently slow KDF. Let K0 be randomly generated key. Store K[0] in file encrypted by Km. Generate future keys as K[i] = H('1' + K[i-1]), where H is a one-way function (hash). Generate K[1] and destroy K[0] (form memory, not from encrypted file). Keep n starting from 1 as message counter. When a message is supposed to be protected by passphrase (is old enough), encrypt it with K[n], generate K[n+1] and store it. Throw away K[n]. Increment n. Your messages are encrypted and you need to enter the passphrase to decrypt them. To optimize this, after decrypting them for the first time, you can store them in the file encrypted by Km directly and replace K[0] with the current K[n] (+ increment the current n). This is just as resistant to device compromise as server side protection. If a malware is inserted, it can gain future messages in both cases and if passphrase is entered into infected device, it can be captured in both cases. Old messages can't be retrieved from stolen device without passphrase in both cases. Of course there may be other features I never heard of. If there are, please name at least one. But even then, they are not much use if they are not commonly implemented.

  2. Trusting server in addition to the client (phone) creates new attack vectors and therefore increases the attack surface even with a well secured server (nothing is perfect). E2Ee mitigates this, as the server does not have to be trusted.

  3. The assumptions 1 and 2 together mean E2Ee can only improve security, not weaken it.

  4. Regular users who don't know a server provider can't verify providers trustworthines.

  5. Only very few users (insignificant amount) have the skills, resources and time to run their own server. I don't believe I would be able to keep up with all the latest in security of servers let alone pay for all the equipment and SW such as firewalls, IDS... Even then, it is a lot of spent time and resources for something that can be better achieved by E2Ee. And running your own server insecurely would be the real false sense of security.

  6. Assumptions 4 and 5 together mean, that most users can't fully trust the server they use. This is compounded by other factors, such as the inability to physically monitor (and restrict) access to the server room the way you can carry around and always see your phone. Or that you can't use encryption at rest efficiently for server as server needs constant access to the data.

  7. Even users running their own server securely can't easily trust the server of the other communicating party.

  8. If trust is ever eroded in the server for some reason or just plainly better option arisses, it is not trivial to move to a new server as all your contacts need the new ID and you need to changed it wherever it is shown (which if it is somewhere written down in physical format may be near impossible).

  9. Having a secure server only adds security to E2E scheme, it is not mutually exclusive. You can for example store the encrypted chat history on a server to further secure yourself (both server authentication and encryption would have to be broken to obtain your message history).

  10. Trusting a server is at the end of the day reliant on trust in the DNS (and PKI). More accurately trusting the domain name will never be obtained by the attackers. If for example your server closes down and an attacker buys the expired domain, they can get a valid certificate for it and impersonate an XMPP server. All the users trying to communicate with you using your old ID will inadvertently communicate with the attacker instead. This is mitigated by including your OMEMO fingerprint with your ID, for example on business cards.

@andrewnenakhov
Copy link
Member

I have PGP set up for email, but I practically never use it, because it is more convenient to switch to a secure IM. Using PGP for mail is just unreasonably hard and there is no reason not to use IM (use best tool for the job).

@samphunter thank you for proving my point with your own confession. Everything you write boils down to this: you yourself preach encryption everywhere, yet, you yourself use in only when it is convenient enough (or "not unreasonably hard").

And, since e2e is convenient enough for you, you want to force everyone to your level of convenience, and you don't really care if they want it or not. That, my friend, is hypocrisy.

You see, I don't totally oppose the idea of encryption. It should be used when it is appropriate. It is nicely done in best messaging service out there - Telegram. It uses 'super reliable encryption' as it's marketing gimmick, yet, users love Telegram, not for their encrypted chats (that don't even work across all platforms, by the way), but because it works seamlessly on all their desktops, tablets and browsers, because you can search history, because it has great group chat experience. All of this is possible only because Telegram does what WhatsApp and Viber do not try to do (for reasons beyond my understanding) - it stores all users archives on central servers. And encrypted secret chats are used very sparingly in it, only when specifically enabled.

That is a sane model that merges security and convenience in a good enough proportion, and users like it. That's what we're going to build too, one day. And you are pushing everyone to use e2e whether they like it or not.

@samphunter
Copy link

samphunter commented Jun 4, 2018

yet, you yourself use in only when it is convenient enough (or "not unreasonably hard").

You misrepresent what I wrote. I have PGP set up and my PGP key published, ready to send or recieve encrypted mail. I just deem it "unreasonably hard" to ask other people to use it when there is a better solution (IM). I am certainly not ashamed to ask everyone to use IMs that are encrypted by default, as that is virtually ZERO effort on their side. There is no excuse not to use encrypted IM these days, it is that easy. But if they prefer to send me PGP mail, it is not a problem for me either. I just don't ask others to use PGP exactly because they don't have to share my priorities and asking them to use it would be bothersome (inconvenient?) for them.

All of this is possible only because Telegram does what WhatsApp and Viber do not try to do (for reasons beyond my understanding) - it stores all users archives on central servers.

Because that is a relic of an age when mobile devices were not fast enough to do all that locally. Thankfully most companies see that.

PS: And case in point, WhatsApp is vastly more popular than Telegram.

@andrewnenakhov
Copy link
Member

@samphunter no excuse, really? Just one thing, like the capability to have a nice history search in a web client, is a deal breaker for almost anyone who does some real work with XMPP.

@samphunter
Copy link

samphunter commented Jun 5, 2018

@andrewnenakhov Great, so somehow we got from it being useless and bad for security all the way to, it disables one feature and only in webclients, who can't easily do OMEMO properly anyway... Are you trying to argue something or just throwing stuff around, hoping something will stick? Obviously webclients probably can't support this, but we are not on a github page of a webclient.

@andrewnenakhov
Copy link
Member

@samphunter I never told it's totally useless. But the desire to force everyone to press a magic button and pretend they are totally safe and secure is silly. It also breaks not 'one feature' but a number of killer features, like good device sync and server search, which are of paramount importance. And downloading all history from a server to client perform a search is not just stupid, but ultra-stupid.

Anyway, you are totally free to do whatever you like, use whatever products you like, create whatever software you like, just don't try to press me into buying this bullshit about e2e and infect me with this crypto-cancer. For any capable user who really cares about security absolutely same security level can be achieved by running own server without e2e, all without losing all the other features we're working on.

And I'll go on creating software as I like it and as my customers require it - and so far we didn't have any customers who would pay us for development of OMEMO in Xabber. You see, there is no real market demand for that, unlike, say, iOS version of Xabber, proper group chats or voice and video calls and fast device synchronization that we're working on now. Hope that makes my argument clear.

Official public offer:
Anyone who wants us to add OMEMO functionality to Xabber for Android should pay us 1 bitcoin. Adding it to iOS and Web version would cost additional 0.5 bitcoin each. With this, I'm locking down this thread until further notice.

@redsolution redsolution locked as too heated and limited conversation to collaborators Jun 5, 2018
@redsolution redsolution deleted a comment from grigoryfedorov Jan 27, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests