Conversations: Encrypted OMEMO group messaging

[knoy]

OMEMO is based on the Axolotl ratchet developed by Moxie Marlinspike, which is used in TextSecure and other applications with P2P-encrypted group messaging. Do you think it would be possible to expand the message encryption to include MUCs, like these competing applications have ?

I think this could be the tipping point for a lot of people that convinces them to switch away from PGP.

[Tokodomo]

I think Axolotl/OMEMO is not a replacement for PGP, because it won't work with MAM, carbons and multiple devices. Sure, Axolotl/OMEMO provides deniability, forward and future secrecy and all that good stuff, but in some scenarios, its not the best choice.

Anyway, encrypted Axolotl/OMEMO group messaging for Conversations would be nice.

[strb]

@Tokodomo None of those things are true. OMEMO works with MAM, carbons, and multiple devices.

@knoy There are plans for encrypted group messaging, but there are still some problems we need to work out, but hopefully MUC2 will solve most of them

[Tokodomo]

@strb
Tell me how! How will it work with MAM and carbons and for multiple devices with different clients? Maybe in theory, yes. But how will you implement this stuff in real life?

[strb]

@Tokodomo We will release an FAQ with technical description as well as an XEP soon. In the meantime, feel free to browse my development blog.

[knoy]

@strb Exactly what kind of problems do you expect MUC2 to solve? It's my understanding MUC2 is still being discussed and no XEP has been released. I would expect the core problems (message distribution and key exchange while maintaining PFS and deniability) would remain the same.

[iNPUTmice]

The 'core' problems are basically already solved in OMEMO. (At least to
some extend. OMEMO will probably not scale with larger conferences - but
i'm not sure we need to.) We are already perfectly capable of sending
messages to multiple instanzes no matter if those instances are multiple
clients of the same user or different users.

However there are a few limititations to be solved in MUC before we can
attempt to run OMEMO over it. For example MUC members can not query the
member list. Meaning if a user is offline for a brief period of time other
users won't be able to send messages to that user. (Because they have no
way of knowing the user is in that room). There are other limitations
regarding history and so forth.

Of course one could attempt to do this with MUC as a proof of concept - but
I don't believe we need to do a proof of concept. The one-on-one
implementation already proofes enough.

And it's not like MUC2/Group chats is a distant thing in the future. I will
start working on that very soon.

[SamWhited]

And it's not like MUC2/Group chats is a distant thing in the future. I will start working on that very soon.

This gives me much more hope that this will actually get done, thanks (I've been arguing against waiting to do things until MUC2 comes out because I don't have any faith when most people say "soon"). As always, feel free to ping me if you need help; I was planning on pushing for us to start this at the summit this year, but if there was already a draft before that there's a good chance we could get it cleaned up and published there instead.

[SafwatHalaby]

@Tokodomo It works in practice. You can check out the XEP for technical details.

[Tokodomo]

@SafwatHalaby
It works in practice with MAM? Actually, OMEMO messages aren't even stored in MAM, and even if they are stored on some point in the future, how should it work if you integrate or use a (previously unknown) new device and fetch all the previously encrypted OMEMO messages stored in MAM (for decryption) from the server? That is my main scenario for using MAM, for example, I actually have one jabber account with 3 devices and now I want to add a new one (device 4), how can the new device decrypt all the old (previously) stored OMEMO messages in MAM? How does it work if I reintegrate a device that was not used for a longer period of time, or the Conversations data (in Android) has been cleared, etc.

Don't get me wrong, OMEMO is great stuff, but has still some way to go. And that is exactly the reason, why I still think OMEMO is not the best choice in some scenarios and not a replacement for PGP really soon. Of course, PGP provides no forward secrecy, but I can live with it. It is integrated in many clients and manually usable on nearly every system.

[SafwatHalaby]

It works in practice with MAM?

Yes.

Actually, OMEMO messages aren't even stored in MAM.

Yes they are, quoting the XEP:

As the asynchronous nature of OMEMO allows decryption at a later time to currently offline devices client SHOULD include a Message Processing Hints (XEP-0334) [6] hint in their OMEMO messages. Otherwise, server implementations of Message Archive Management (XEP-0313) [7] will generally not retain OMEMO messages...

New devices are indeed problematic as of now.

[Tokodomo]

No, not at all! Did you test it? I guess not. You should take a look at the second quoted sentence, please don't confuse offline messages with MAM, these are two different things!

Anyway, it is stated clearly in XEP:
"Otherwise, server implementations of Message Archive Management (XEP-0313) [7] will generally not retain OMEMO messages, since they do not contain a

[iNPUTmice]

both the current prosody mam module as well as mod_mam_mnesia should be
able to store omemo messages

[iNPUTmice]

Also as this is getting way off topic please refer to our conference for
further discussions.

[Tokodomo]

@iNPUTmice
Jabber.at uses ejabberd 15.06, last time I tested MAM and OMEMO was with Conversations 1.6.7, and all OMEMO messages were not stored in MAM.

Okay, last question, did you mean a jabber conference?

[SafwatHalaby]

@Tokodomo He meant the support MUC at [email protected].

[singpolyma]

For example MUC members can not query the
member list.

Except they receive the full list of participants on every join... how is this limitation a problem in practise?

[knoy]

I think this issue has become pretty side-tracked from the original request.

In order for Conversations to be competitive with Telegram, Signal, etc. it will need to have group messaging. This is a major holdback for users of IRC and other protocols as well.

I'd love to see this happen and would like to contribute whatever code or money is needed to make this a reality. As far as I can tell right now MUC2 seems pretty stagnant.

[SamWhited]

As far as I can tell right now MUC2 seems pretty stagnant.

The first draft of MUC 2 (MIX) was just published a few days ago as XEP-0369.

It is being actively worked on, and the last few TODO's are probably going to be wrapped up during the summit at the end of the month.

[knoy]

I wasn't aware of this! This is great news. I was checking earlier this month and didn't catch this

Is MUC2 going to be a technical prerequisite for implementing OMEMO support for MUCs? Or is the reasoning that it will be less work to re-implement only for XEP-0369 instead of both 0369 and 0045 ?

[SamWhited]

Is MUC2 going to be a technical prerequisite for implementing OMEMO support for MUCs?

Yes, in MUC there is no way to share pre-keys if the MUC is semi-anonymous (you can't do PEP in a semi-anonymous MUC). MIX, however, is designed on top of PubSub, so you can just publish a new PEP node for pre-keys.

[therob84]

Is there any news about OMEMO for group messaging support in conversations meanwhile?

How would be the timetable/roadmap after the XEP-0369 is usable to implement this to conversations? Days, weeks or months? (I hope "never" is no answer..)
Cheers, Robert

[knoy]

I think the power of this feature may be underestimated, with OMEMO's support for HTTP upload, MAM and offline messaging, this could be extremely compelling to businesses and organisations. Without this, to them Conversations is marginally better than pidgin. With it, this is a Slack killer.

There are entire companies formed around the idea of encrypted group collaboration:
https://www.stackfield.com/
https://peerio.com/
http://motherboard.vice.com/read/dear-slack-please-add-otr

[iNPUTmice]

I implemented OMEMO encrypted group chats on top of MUC as a proof of concept. This is highly experimental because MUC is clearly not suited for group chats. But it proofs that OMEMO itself doesn't have any problems with multi-party encryption.

[therob84]

@iNPUTmice But we cannot use this feature in current Conversation, right?

Is there any progress you could share with implementing Group-OMEMO via other methods (MIX etc.) for using it in one of the next stable version?

[iNPUTmice]

This is available in HEAD right now as well as in the beta on Google Play.

MIX doesn't exist yet. And there is very little I can do about that.

[therob84]

As I surprisingly read today at change log at google play:
==Version 1.11.0==
• OMEMO encryption for conferences. Conditions apply. See README.md on Github

THAT's GREAT news!!!!
But why you found it not worth to mention HERE? (Or did I misunderstand the word "HEAD" in any way? Or is "conference" different from "group messaging"?)

(btw: Thats exactly the point about the current information policy of conversations-team about I struggled quite before some times and already expressed myself without real response!)

[iNPUTmice]

@therob84 not sure what you understood when I said

This is available in HEAD right now as well as in the beta on Google Play.

In any case this is a bug tracker and not a news portal. If you want some way to stay up to date besides reading the changlog I'm on Twitter @inputmice and in our conference: [email protected]

[amenk]

In a perfect world, the commits should be tagged with the issue number, so there is automatically a notice here in the issue :-)

[danielegobbetti]

I'm using Omemo in group chat and it works, thanks!

I have a question though, just to understand if this is a known limitation or there's something wrong with my setup: omemo messages cannot be exchanged between users that do not belong to the same domain of the muc server.

I tried between users of my server (everything is fine) but as soon as an user from another domain chimes in we both see the prompt to trust omemo keys, but then the encrypted messages aren't received on the other end.

I checked the debug output of my server (prosody) and see no differences between normal messages ( that go through) and encrypted ones (that don't ).

[amenk]

But Omemo 1:1 messages work between you and the user of the other server? If not, it would be a general OEMO problem of the other user's server.

[danielegobbetti]

sorry, yes! everything works well for 1:1 messages.

[iNPUTmice]

I have a question though, just to understand if this is a known limitation or there's something wrong with my setup: omemo messages cannot be exchanged between users that do not belong to the same domain of the muc server.

This is not a known limitation. In my limited testing I haven't experienced any issues with cross-server communication. That isn't to say they aren't any though.

Could you try to capture the XML stream on the receiving end? (Maybe join the conference with gajim as well (which has an XML console) and see if there are stanzas arriving? Also adb logcat output of Conversations would be helpful. (Not sure if Conversations will log anything useful though)

[danielegobbetti]

Sorry it took a while to get the logs. This is from gajim:

03/15/2016 15:35:04 (I) nbxmpp.transports_nb pollin called, state == CONNECTED
03/15/2016 15:35:04 (I) nbxmpp.idlequeue read timeout removed for fd 33
03/15/2016 15:35:04 (I) nbxmpp.idlequeue read timeout set for fd 33 on 55 seconds
03/15/2016 15:35:04 (I) nbxmpp.idlequeue read timeout set for fd 33 on 120 seconds with function <bound method NonBlockingTCP.read_timeout2 of <nbxmpp.transports_nb.NonBlockingTCP instance at 0x7f7327333d88>>
03/15/2016 15:35:04 (I) nbxmpp.client_nb raising event from transport: :::::DATA RECEIVED::::
_____________
<message id='ec41ba30-76ee-4bfa-bb59-cc8700203064' type='groupchat' to='me@server2/Gajim' from='conf@server1/daniele'><encrypted xmlns='eu.siacs.conversations.axolotl'><header sid='334833106'><key rid='1136524210'>MwohBYigNnUJGGwQFmplbU1CDRViJBrGCZCzxsXDPKXF0sI6EAkYACIgfcr6mju87cn+ni7h/jSs
gPRZ3YdbMTfDQsWMiTkkh8ejkfmpPE5yNg==
</key><key rid='2123642760'>MwohBV+uoy8pf6ho9/jR7iqUE1JLURY0guFpv1/WI4XRmGBKEAgYACIgAZymt4EhVyl5PSiNRdqx
qSjceHsfr+Ymqmo7orkBjsriyfnXtx5TNA==
</key><key rid='1191381915'>MwiU388FEiEFmy3i7LpfSHg8nfCAxXR+6lHrW+UU9K0TCSByggTI5zwaIQXW2d6rC1fyY/2MJCAd
xZZJYQUIhBzcZ37kQGkAI/5PaSJSMwohBYzSrDx8sEXpQI9lGnA/EDxs/nv3ZQtl/dW+uLzE9Lxz
EAMYACIgRS/I/BFdPMQeKGB5ZwNMsiCIYeizz2LdZeTMMSKFlS5lug/bm910/yjSy9SfATDkag==
</key><key rid='1352423531'>MwiGAxIhBa8d6p7cYqGUvUCgxwubwyRjPv6jCt0BhJJM/pEFP3oJGiEF1tneqwtX8mP9jCQgHcWW
SWEFCIQc3Gd+5EBpACP+T2kiUjMKIQXKp2oAyjxWGsaJVrxb4oC0xkoRtIwP7mKOCykL99TAYBA/
GAAiIBQy5DkqgEeY7SGDiQZm0t1KWNV53FQsjXOnzUp4rt5cjo1kSl9sxJAo0svUnwEwBA==
</key><key rid='2125878448'>MwiOARIhBfjG0ko+uJTph6Vx+9f7pPCsU3oWGMXWCdjgGR+edWlsGiEF1tneqwtX8mP9jCQgHcWW
SWEFCIQc3Gd+5EBpACP+T2kiUjMKIQWsSlduCEeLP+xtcyPce/COS2jBe0Putw15aKlxZen4eBAD
GAAiINTlhPbfyZca9sOJEPxgaclv0cnTKEPMaxQBSkqoKeCXTdymNC2bA14o0svUnwEwAg==
</key><iv>c9Lz9wF9DBUAQlKmAYdbjQ==
</iv></header><payload>3bn4+BoMPfXF+gaGo12mPcozLU5l
</payload></encrypted><store xmlns='urn:xmpp:hints'/></message><r xmlns='urn:xmpp:sm:2'/>
_____________

03/15/2016 15:35:04 (D) gajim.c.ged stanza-received
Args: (<common.connection_handlers_events.StanzaReceivedEvent object at 0x7f732c0138d0>,)
03/15/2016 15:35:04 (I) nbxmpp.simplexml STARTTAG.. DEPTH -> 2 , tag -> message, attrs -> {u'to': u'me@server2/Gajim', u'type': u'groupchat', u'id': u'ec41ba30-76ee-4bfa-bb59-cc8700203064', u'from': u'conf@server1/daniele'}
03/15/2016 15:35:04 (I) nbxmpp.simplexml STARTTAG.. DEPTH -> 3 , tag -> encrypted, attrs -> {u'xmlns': u'eu.siacs.conversations.axolotl'}
03/15/2016 15:35:04 (I) nbxmpp.simplexml STARTTAG.. DEPTH -> 4 , tag -> header, attrs -> {u'sid': u'334833106'}
03/15/2016 15:35:04 (I) nbxmpp.simplexml STARTTAG.. DEPTH -> 5 , tag -> key, attrs -> {u'rid': u'1136524210'}
03/15/2016 15:35:04 (I) nbxmpp.simplexml DEPTH -> 5 , tag -> key
03/15/2016 15:35:04 (I) nbxmpp.simplexml STARTTAG.. DEPTH -> 5 , tag -> key, attrs -> {u'rid': u'2123642760'}
03/15/2016 15:35:04 (I) nbxmpp.simplexml DEPTH -> 5 , tag -> key
03/15/2016 15:35:04 (I) nbxmpp.simplexml STARTTAG.. DEPTH -> 5 , tag -> key, attrs -> {u'rid': u'1191381915'}
03/15/2016 15:35:04 (I) nbxmpp.simplexml DEPTH -> 5 , tag -> key
03/15/2016 15:35:04 (I) nbxmpp.simplexml STARTTAG.. DEPTH -> 5 , tag -> key, attrs -> {u'rid': u'1352423531'}
03/15/2016 15:35:04 (I) nbxmpp.simplexml DEPTH -> 5 , tag -> key
03/15/2016 15:35:04 (I) nbxmpp.simplexml STARTTAG.. DEPTH -> 5 , tag -> key, attrs -> {u'rid': u'2125878448'}
03/15/2016 15:35:04 (I) nbxmpp.simplexml DEPTH -> 5 , tag -> key
03/15/2016 15:35:04 (I) nbxmpp.simplexml STARTTAG.. DEPTH -> 5 , tag -> iv, attrs -> {}
03/15/2016 15:35:04 (I) nbxmpp.simplexml DEPTH -> 5 , tag -> iv
03/15/2016 15:35:04 (I) nbxmpp.simplexml DEPTH -> 4 , tag -> header
03/15/2016 15:35:04 (I) nbxmpp.simplexml STARTTAG.. DEPTH -> 4 , tag -> payload, attrs -> {}
03/15/2016 15:35:04 (I) nbxmpp.simplexml DEPTH -> 4 , tag -> payload
03/15/2016 15:35:04 (I) nbxmpp.simplexml DEPTH -> 3 , tag -> encrypted
03/15/2016 15:35:04 (I) nbxmpp.simplexml STARTTAG.. DEPTH -> 3 , tag -> store, attrs -> {u'xmlns': u'urn:xmpp:hints'}
03/15/2016 15:35:04 (I) nbxmpp.simplexml DEPTH -> 3 , tag -> store
03/15/2016 15:35:04 (I) nbxmpp.simplexml DEPTH -> 2 , tag -> message
03/15/2016 15:35:04 (D) nbxmpp.dispatcher_nb Got jabber:client/message stanza
03/15/2016 15:35:04 (D) gajim.c.connection_handlers MessageCB
03/15/2016 15:35:04 (D) gajim.c.ged raw-message-received
Args: (<common.nec.NetworkEvent object at 0x7f732c0343d0>,)
03/15/2016 15:35:04 (D) gajim.c.ged message-received
Args: (<common.connection_handlers_events.MessageReceivedEvent object at 0x7f732c034450>,)
03/15/2016 15:35:04 (D) gajim.c.ged decrypted-message-received
Args: (<common.connection_handlers_events.DecryptedMessageReceivedEvent object at 0x7f732c034290>,)
03/15/2016 15:35:04 (I) nbxmpp.simplexml STARTTAG.. DEPTH -> 2 , tag -> r, attrs -> {u'xmlns': u'urn:xmpp:sm:2'}
03/15/2016 15:35:04 (I) nbxmpp.simplexml DEPTH -> 2 , tag -> r
03/15/2016 15:35:04 (D) nbxmpp.dispatcher_nb Got urn:xmpp:sm:2/r stanza
03/15/2016 15:35:04 (I) nbxmpp.transports_nb Plugging fd 33, W:True, R:True
03/15/2016 15:35:04 (I) nbxmpp.transports_nb pollout called, state == CONNECTED
03/15/2016 15:35:04 (I) nbxmpp.transports_nb Plugging fd 33, W:False, R:True
03/15/2016 15:35:04 (I) nbxmpp.client_nb raising event from transport: :::::DATA SENT::::
_____________
<a xmlns="urn:xmpp:sm:2" h="77" />
_____________

And NO text is shown in gajim. (I am not using the omemo plugin on gajim / I disabled it for this test).

As for conversations log. It's kind of confusing for me because I am connecting with two separate accounts and getting the right log messages isn't trivial.

If you prefer I can join the support conference and invite some of you to this group chat?

[danielegobbetti]

Update: setting the conference room as non anoymous makes omemo work for me. Somehow I missed the setting when creating the conference with another client, but after toggling the checkbox in conversations everything started to work. Thanks!

[Allanitomwesh]

Hello
I recently installed this application and tested it with a friend.
The issue I have is,when I create a conference and set it non - anonymous, my friend can encrypt in omemo,but I cannot. The reverse is also true,when he is owner of the conference,I can omemo,but he cannot.
It may be because we are only two in the conference,but I wanted to make you aware.

[knoy]

Hey I think it's safe to close this ticket now. OMEMO group messaging has been seemingly stable for me for sometime