Psi indicates outcoming OMEMO-encrypted messages as unencrypted

[yessiest]

When an outcoming message is sent, Psi seems to be showing that it isn't encrypted, even if encryption is enabled. Despite this, the message is received as if it was a proper OMEMO message, and xml dump shows that the message body contains <encrypted> tag, <payload> tag and <encryption> tag.

I'm using Psi+ 1.5.2021.01.02 on Windows 10.

XML log of the message (to/from stripped)

<message> 
  <active xmlns="http://jabber.org/protocol/chatstates"/>
  <request xmlns="urn:xmpp:receipts"/>
  <encrypted xmlns="eu.siacs.conversations.axolotl">
     <header sid="1887302399">
         <iv>5dt4+C/s8apCIGcf</iv>
         <key rid="636297163" prekey="true">Mwi8o4QHEiEFIhnsQa3OGxfjntMkXcoJYbzNsTUGx7q5IhHiEL5QzzIaIQUyeoC8XugZd
         2K6Zo6S/xHXTIJrn5m8I/F9HLKchcMVJSJiMwohBSpjAThq3LSkPFblq6LmYPYFk+iRznvMSz1bJMbZ0NEMEDAYACIwbX6wzJyinzlFc
         f7VlaSf3ggQfoXj+sd6tzM9tX7V7ReUnfw0G6YOO9bG4tsa13kidajWcm60Az0o/+X3gwcwAQ==</key>
         <key rid="900459693">MwohBVBEhJULwnGIwkrLaE/9RBDlEfMmHE/2CvHdo9rtVcVWEAEYACIwEaO0dlgcMHE4O56Q+oxO7e78nez
         Cp/rPPUD+v0K2Q07mw0skGkcE956xtIZe1ys3Wv3zkqxrsmY=</key>
         <key rid="547510437" prekey="true">MwgyEiEFFiMdsHG5qyRzL/Sj1RW4y0gCsjvrYKh75XSsINE/7wMaIQUyeoC8XugZd2K6Z
         o6S/xHXTIJrn5m8I/F9HLKchcMVJSJiMwohBQOW4IPxQD1wqiXEvWIHQg0dDUwyFP0OKdkG8vQh0dFPEDAYACIwaKQLsjFGm7WLtlutJ
         b7/+VmPdT+kvmC+6NShRAZ15E444Lqg0TaN/qdsF4c5iz2J6Z0G4+uq9y0o/+X3gwcwAQ==</key>
     </header>
     <payload>TqMtjQK63kYp</payload>
  </encrypted>
  <store xmlns="urn:xmpp:hints"/>
  <encryption namespace="eu.siacs.conversations.axolotl" xmlns="urn:xmpp:eme:0"/>
</message>

[tehnick]

As I see OMEMO button on toolbar is enabled. Have you tried to disable and then to enable OMEMO encryption from your side? Does it change anything?

[yessiest]

Tried it, didn't really work. The messages that were sent out with OMEMO disabled were unencrypted. Once I turned it back on, the problem started reoccuring. Messages were still getting encrypted and they were still being indicated as if they were not encrypted.

[Neustradamus]

@yessiest: Thanks to confirm OMEMO problems, I have done several tickets etc. without solutions. @tehnick has done some changes but it is not always perfect at this time.

[Ri0n]

Maybe misinterpretation of the chatlog when when incoming unencrypted message also triggers "encryption disabled". In this case nothing wrong with outgoing message. If you don't receive anything but just send, everything will be encrypted

[tehnick]

@Ri0n No, in this issue is described problem with outgoing messages. But not with incoming ones.

@yessiest Could you check this problem in my builds for MS Windows? https://sourceforge.net/projects/psiplus/files/Windows/Personal-Builds/tehnick/ To switch program to usage of your system profile just rename of executables as described in README.txt from archive.

[Neustradamus]

@yessiest: Have you looked with last @tehnick build?

[yessiest]

So i have tested this with the latest build by @tehnick (v1.5.1524) under approximately the same conditions as before (Windows 10 x86_64, Psi+ as recipient, Profanity v0.10.0 as sender, OMEMO enabled and fingerprints were exchanged). This issue seems to have been fixed as far as I can tell - both incoming and outcoming OMEMO messages are marked as encrypted and "Encryption is disabled" messages no longer pop up.

[Neustradamus]

It is possible to test with another accounts?

[yessiest]

I have tested this on a different machine (Windows 7 x86_64) with two builds - one that I have mentioned in the head post and the v1.5.1524 one, both running portable. The issue has resurfaced on the v.1.5.1524 build - once again the outgoing messages are being marked as unencrypted, while Profanity receives them as OMEMO encrypted messages.

I have tested this again on the original hardware (Windows 10 x86_64), and the issue resurfaced there, too.

[Neustradamus]

@kssytsrk: Can you look this ticket?

[kssytsrk]

Can't reproduce on Psi+ 1.5.1551 (2021-08-16) / FreeBSD 13.0 and Profanity as sender. Might this be Windows-only?

[Neustradamus]

@kssytsrk: Thanks for your reply.

Can you test with 2 new test accounts without OMEMO used before?

Please use Psi+ and Psi+.

You will find the problem...

[kssytsrk]

Isn't this ticket specifically about

Psi+ as recipient and Profanity v0.10.0 as sender

?

[Neustradamus]

No.

[Neustradamus]

@yessiest: Do you confirm that the bug is always here with new Psi+ builds?

[yessiest]

I have tested the newest version available on sourceforge.net, that is, version 1.5.1552, on a Windows 7 machine. I can confirm that the bug still persists. Worth noting is the fact that this time I have been using Psi+ on both ends, so it's not specifically "Psi+ as recipient and Profanity v0.10.0 as sender" issue.

I have managed to reproduce both the state where the issue didn't show up and the state where it reappeared. The issue becomes apparent only if the receiving device uses Psi+ and the sending device has multiple OMEMO keys for the receiver's account. Then this issue appears on the receiver's Psi+ client.

[nullobsi]

This bug seems very strange. I had come across it a lot when my server was running Prosody; far less often when using Ejabberd, and now it has come back again.

[Neustradamus]

@Ri0n: You can confirm this bug, you have seen few days ago

[Neustradamus]

Linked to:

• https://github.com/psi-im/plugins/issues/92

Screenshot from @yessiest:

• https://user-images.githubusercontent.com/70776062/109429325-a3bded80-7a14-11eb-8c74-ae40876344e2.png

[yessiest]

Found where OMEMO fails. Tested with OTR, in iris/src/xmpp/xmpp-im/xmpp_tasks.cpp, there's this bit of code

void JT_Message::onGo()
{

    Stanza      s = m.toStanza(&(client()->stream()));
    QDomElement e = s.element(); // oldStyleNS(s.element());

    if (auto encryptionHandler = client()->encryptionHandler()) {
        Q_UNUSED(encryptionHandler->encryptMessageElement(e));
    }

    // See: XEP-0380: Explicit Message Encryption
    const bool wasEncrypted = !e.firstChildElement("encryption").isNull();
    m.setWasEncrypted(wasEncrypted);
    m.setEncryptionProtocol(encryptionProtocol(e));

    // if the element is null, then the encryption is happening asynchronously
    if (!e.isNull()) {
        send(e);
    }
    setSuccess();
}

This code sets the flag that tells whether the message was encrypted. It works fine with OTR because "e" is actually set and is not null. However, for OMEMO, e.isNull() returns true, and so wasEncrypted is probably also not present as an element of e.

So the gist of it is that if encryption is happening "asynchronously", there is no way to actually check that the message was encrypted and so it defaults to saying that message was never encrypted. Currently researching into potential ways of fixing this without being too intrusive, hopefully there is a solution.

[Neustradamus]

@Ri0n, @Vitozz, @tehnick, @stigger: Have you seen the comment of @yessiest?

[stigger]

Now I have.

@yessiest You are right that the OTR and the OMEMO encryptions are handled differently. It's not consistently broken, though, you've said it yourself:

I have managed to reproduce both the state where the issue didn't show up and the state where it reappeared

The only thing left is to investigate what's happening differently between the working and the broken states. For my use-cases the messages are always indicated properly.

[Neustradamus]

@yessiest: Have you seen the @stigger comment?

[yessiest]

@Neustradamus yes I have. Unfortunately I have been unable to reproduce the issue lately, things kind of just work for the most part. I'm not quite sure whether anything has changed, and disappointingly enough, my initial judgement on this issue being tied to having multiple contact fingerprints seems to be invalid - i have just tested this, sent messages to various resources, with different keys, everything worked as expected.

[ghost]

I discovered for myself that at least on my end, the issue is caused by untrusted OMEMO keys from other devices logged in. If I send a message from Psi+ to these other devices on my account, it'll build and add the device key to my trusted contacts list, which will no longer display the warning at all. My clients tested is Psi+ v1.5.1653 and blabber.im v3.1.4.

[Neustradamus]

@yessiest and others: Have you tested with latest Psi+ build? The problem is always here?