Rid is not being sent if the other user is offline OMEMO MUC

Smack Smack Support
1

Hi,

When the recipient is online then it is sending the omemo encrypted message with Rid as follows

HELLO MwohBY/WlG0nG0SwBKR1FOo1xhICk5aiYoD1BkmkPSLoyvoxEAMYBiIwWONua7Z9S4K0c/lAvw2p8RtzrtM4vC6qvlbCzs+QJ1LRwrSrCRztk6UPskcxN+ZkIsFyDYVmh78= c/rOGVhovo4PVe3U GAPGUgOZtOhflDGZ00V+sy72RQ==

But when recipient is offline then it is not sending Rid in stanza as follows

HELLO HGzh7aagpKav/U0z S+QmFt1JOFAsZrKoUrEfv9EDRQ==

So the issue is that if recipient is offline and then he comes back online and received this message then he cannot decrypt message without Rid.

So what i am doing here?

Thanks
Firoz Saifi

2

When recipient is online then it sends stanza with rid

<message to='encinternal11655892610695@conference.dbchatdev.iworklab.com' id='BMB5G-158' type='groupchat'>
      <body>
        HELLO
      </body>
      <encrypted xmlns='eu.siacs.conversations.axolotl'>
        <header sid='216604864'>
          <key prekey='true' rid='267960959'>
            MwhhEiEFwplfnk9PJaWziGTFOA7NF/0hCngw2FnQLTuyVqWiPikaIQUIfWYYea+IuNa+6k0j9+2M+7TYFM6XGdHKbNv3Uj2iVCJiMwohBfuo1Z9Rjj6eKVrFNIPZ4f26iQvkAwadS4TZMbNR97Q3EAUYACIwFi/lDOffXyYoehdjUV+Hig3js7GvyTnYGLHgHd8j4oy0yO+IKFZH3nXLY8QH8VdOLd0MFBZgQ7koADAB
          </key>
          <key rid='1763335818'>
            MwohBfpfzSIPZcasxBtFB1XdzHoYm52MRuWkUxtXltsjQU1cEAUYACIw2FZPahgj1iga22I3Zc6iBUK0jzCAutLquAZS7knbaAUHSzZ4jcrpXnRCavpaiN8MeaAgN+bhZcU=
          </key>
          <key prekey='true' rid='995007388'>
            MwiLARIhBYni5GMJJ7Y/KsHaJnFAXLrtHXLFIvDbwda/5jNpdMNvGiEFCH1mGHmviLjWvupNI/ftjPu02BTOlxnRymzb91I9olQiYjMKIQUp05aAu48RpiiEvXCPCJskOprWOi5QHkIzwBaZRz2YdRAEGAAiMEX9d5/kQv5PfTI/Au5ytxYfhRgW3miaDqCvZVB8eAR1++y9mSC6QijJcCBjTVkeL/IeaLhh0q4XKAAwAQ==
          </key>
          <iv>
            w2x+exNL4p6JXgly
          </iv>
        </header>
        <payload>
          I5GglRh5Q0C+6DO7VVA3UVcAXA==
        </payload>
      </encrypted>
      <origin-id xmlns='urn:xmpp:sid:0' id='CG7D-6CAT-YMPR-I'/>
    </message>
    <r xmlns='urn:xmpp:sm:3'/>

when recipient is offline then it sends stanza without rid so when recipient comes online he cannot decrypt the message.

   <message to='encinternal11655892610695@conference.dbchatdev.iworklab.com' id='BMB5G-158' type='groupchat'>
      <body>
        HELLO
      </body>
      <encrypted xmlns='eu.siacs.conversations.axolotl'>
        <header sid='216604864'>
          <iv>
            w2x+exNL4p6JXgly
          </iv>
        </header>
        <payload>
          I5GglRh5Q0C+6DO7VVA3UVcAXA==
        </payload>
      </encrypted>
      <origin-id xmlns='urn:xmpp:sid:0' id='CG7D-6CAT-YMPR-I'/>
    </message>
    <r xmlns='urn:xmpp:sm:3'/>
3

Somebody please response why it is not encryting message for offline users in MUC

4

If a user is not online, they are not part of the MUC. There is no way for the sending client to know which users are supposed to receive the message if they are not online.

5

I am wondering if Smack’s API could be improved here: should not Smack throw a meaningful exception instead of sending a stanza without ‘rid’ in that case?

6

I’m not sure if it makes sense to distinguish between “there is no rid for a particular offline device” and “there is no rid at all”.

What would be the added value for the API?

7

But it must have been part of the MUC even if user is not online. Why smack is not supporting this? Even Gajim pc client have this feature. I am developing a chat application with E2E encryption using OMEMO but if it doesn’t encrypt message for offline users then we can’t use E2E as the user can’t receive messages. In this case, OMEMO is useless.

8

Gajim must be doing something smart, like “remembering” members of the chat.
However, there is no way to tell with certainty whether a specific user is part of the chat group or not.

Multi-User-Chat does not know persistent membership afaik. However, you can keep track of participants yourself and simply encrypt the message to all recipients you intend to send the message to.

Set<BareJid> myMucParticipantList = database.lookupKnownParticipants(muc); // your own logic
OmemoMessage.Sent omemoMsg = omemoManager.encrypt(myMucParticipantList, "Hello, World!");
Message message = omemoMsg.buildMessage(msgBuilder, mucJid);
...
9

ok so isn’t there any way to fetch the all the members of this group instead of storing them in db

10

For querying members (not participants) read this (XEP-0045 7.11 Getting the Member List):

https://xmpp.org/extensions/xep-0045.html#getmemberlist

in combination with chapter 9.5, you could try to query like this:

<iq from='crone1@shakespeare.lit/desktop'
    id='member3'
    to='coven@chat.shakespeare.lit'
    type='get'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='member'/>
  </query>
</iq>

and you should get an answer like this:

<iq from='coven@chat.shakespeare.lit'
    id='member3'
    to='crone1@shakespeare.lit/desktop'
    type='result'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='member'
          jid='hag66@shakespeare.lit'
          nick='thirdwitch'
          role='participant'/>
  </query>
</iq>

but keep in mind that you have to be member of this room and admins, owners have to be queried separatly

or try 6.5 Querying for Room Items:

<iq from='hag66@shakespeare.lit/pda'
    id='kl2fax27'
    to='coven@chat.shakespeare.lit'
    type='get'>
  <query xmlns='http://jabber.org/protocol/disco#items'/>
</iq>

and get

<iq from='coven@chat.shakespeare.lit'
    id='kl2fax27'
    to='hag66@shakespeare.lit/pda'
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#items'>
    <item jid='coven@chat.shakespeare.lit/firstwitch'/>
    <item jid='coven@chat.shakespeare.lit/secondwitch'/>
  </query>
</iq>

But in theory the best way is to keep the presences sent out by the server if you enter the room and track the users presences by yourself.

11

MUC has such a concept, it’s just not required for MUC. But in theory, you could create a OMEMO MUC configuration and expose this as a data form variable of the MUC, if enabled, the MUC

  • would require a persistent member list
  • would disallow non-members
  • would be non-anonymous, so that clients can retrieve the key material
12

This topic was automatically closed 62 days after the last reply. New replies are no longer allowed.