Add support for OMEMO Encyrption

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/

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

+1

+10

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

yes, please support OMEMO in xabber.

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

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

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

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.

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

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?

@Buntbart

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

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.

@imp1sh

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

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.

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?

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.

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.

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.

@vanitasvitae

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₿ ;)

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.

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?

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:

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.
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.
The assumptions 1 and 2 together mean E2Ee can only improve security, not weaken it.
Regular users who don't know a server provider can't verify providers trustworthines.
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.
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.
Even users running their own server securely can't easily trust the server of the other communicating party.
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).
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).
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.

@samphunter

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.

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.

@samphunter

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

@andrewnenakhov

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

@samphunter

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

Navigation Menu

Repository navigation

Add support for OMEMO Encyrption #540

60 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Add support for OMEMO Encyrption #540

Description

Activity

TurkeyMan commented on Oct 11, 2015

Buntbart commented on Sep 8, 2016

falsefifth commented on Nov 6, 2016

vanitasvitae commented on Jan 19, 2017

imp1sh commented on Jan 23, 2017

climf commented on Mar 1, 2017

vanitasvitae commented on Mar 2, 2017

tdemin commented on Oct 8, 2017

andrewnenakhov commented on Oct 8, 2017

Buntbart commented on Oct 8, 2017

rugk commented on Oct 8, 2017

andrewnenakhov commented on Oct 8, 2017

imp1sh commented on Oct 8, 2017

andrewnenakhov commented on Oct 8, 2017

schiessle commented on Oct 8, 2017

60 remaining items

andrewnenakhov commented on Jun 3, 2018

samphunter commented on Jun 4, 2018

vanitasvitae commented on Jun 4, 2018

andrewnenakhov commented on Jun 4, 2018

andrewnenakhov commented on Jun 4, 2018

samphunter commented on Jun 4, 2018

andrewnenakhov commented on Jun 4, 2018

samphunter commented on Jun 4, 2018

andrewnenakhov commented on Jun 4, 2018

samphunter commented on Jun 4, 2018

andrewnenakhov commented on Jun 4, 2018

samphunter commented on Jun 5, 2018

andrewnenakhov commented on Jun 5, 2018

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions