Created attachment 165985 [details] Image of conversation that appears to have lost the keys SUMMARY Neochat seems to "lose" the encryption keys to conversations/rooms and there doesn't appear to be a way to tell Neochat to re-fetch the encryption keys from other users. STEPS TO REPRODUCE 1. Join a Room with encryption enabled OBSERVED RESULT Everything seems to work fine for a period of time, and Neochat seems to just "lose" the encryption keys at some point. EXPECTED RESULT Neochat would continue to encrypt/decrypt messages, and if things do somehow get desynced between clients, have a way to repoll the other party/parties to resend their keys. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Linux 6.7.4/openSUSE Kalpa/Wayland (available in About System) KDE Plasma Version: 5.27.10 KDE Frameworks Version: 5.115.0 Qt Version: 5.15.12 ADDITIONAL INFORMATION Screenshot attached of a conversation that appears to have "lost" the decryption key of the other party. The message decrypts fine using element, on the same host, and on my android phone.
Please open this chat in element, and check whether the two messages from the other person (the last one you can decrypt and the first one you can't decrypt) are from the same session. You can do that by: - Hovering over the message - Clicking on the three dots -> View source -> Original event source - compare the "session_id" field
(In reply to Tobias Fella from comment #1) > Please open this chat in element, and check whether the two messages from > the other person (the last one you can decrypt and the first one you can't > decrypt) are from the same session. You can do that by: > > - Hovering over the message > - Clicking on the three dots > -> View source > -> Original event source > - compare the "session_id" field I don't know if those session ID's are sensitive or not, but the session_id in the element webclient for the last message neochat decrypted is different than the one for the message Neochat didn't decrypt. I'll just shoot you the first ten characters, just in case somebody can do something nefarious with an entire session_id Neochat Decrypted: "tXOQhYb+6M" Neochat didn't Decrypt: "sBca0BOnYc"
Don't worry; the session ids are not sensitive. This means that the other person's client started encrypting messages with a new key (which is entirely normal and happens automatically) but neochat didn't get the key for it (or failed to decrypt it). Can you please grep through ~/.local/share/KDE/neochat/neochat.log.* for "[WARN ] quotient.e2ee" and see if there's something interesting? There will be messages like "The fixed buffer source is shared", those are irrelevant. If you find something, please send the relevant to me directly (there isn't anything highly sensitive in there, but maybe more than you'd want to send publicly)
Got this from ~/.var/app/org.kde.neochat/data/KDE/neochat/neochat.log.0 2024-02-20T17:01:37 [WARN ] quotient.e2ee: /run/build/libquotient/Quotient/e2ee/e2ee_common.cpp:118: void Quotient::FixedBufferBase::fillFrom(QByteArray&&): The fixed buffer source is shared; assuming that the caller is responsible for securely clearing other copies 2024-02-20T17:01:37 [WARN ] quotient.e2ee: /run/build/libquotient/Quotient/e2ee/e2ee_common.cpp:118: void Quotient::FixedBufferBase::fillFrom(QByteArray&&): The fixed buffer source is shared; assuming that the caller is responsible for securely clearing other copies 2024-02-20T17:01:37 [WARN ] quotient.e2ee: /run/build/libquotient/Quotient/e2ee/e2ee_common.cpp:118: void Quotient::FixedBufferBase::fillFrom(QByteArray&&): The fixed buffer source is shared; assuming that the caller is responsible for securely clearing other copies 2024-02-21T09:13:46 [WARN ] quotient.e2ee: /run/build/libquotient/Quotient/room.cpp:386: bool Quotient::Room::Private::addInboundGroupSession(QByteArray, QByteArray, const QString&, const QByteArray&): Adding inbound session "tXOQhYb+6MsRhgLke/K6kg+vHm7tHbPF8rISFTMpeu0" 2024-02-21T09:13:46 [WARN ] quotient.e2ee: /run/build/libquotient/Quotient/room.cpp:1626: void Quotient::Room::handleRoomKeyEvent(const Quotient::RoomKeyEvent&, const QString&, const QByteArray&): added new inboundGroupSession: 3 2024-02-21T11:30:00 [WARN ] quotient.e2ee: /run/build/libquotient/Quotient/room.cpp:386: bool Quotient::Room::Private::addInboundGroupSession(QByteArray, QByteArray, const QString&, const QByteArray&): Adding inbound session "GG9j0IwmAEmmeg3pu4MTrO/EBPVikwc2f7ovOkdXxlY" 2024-02-21T11:30:01 [WARN ] quotient.e2ee: /run/build/libquotient/Quotient/e2ee/qolmsession.cpp:94: Quotient::QOlmExpected<QByteArray> Quotient::QOlmSession::decrypt(const Quotient::QOlmMessage&) const: "Failed to decrypt the message": BAD_MESSAGE_MAC 2024-02-21T11:30:01 [WARN ] quotient.e2ee: /run/build/libquotient/Quotient/connectionencryptiondata_p.cpp:353: void Quotient::_impl::ConnectionEncryptionData::handleEncryptedToDeviceEvent(const Quotient::EncryptedEvent&): Failed to decrypt to-device event from device "" 2024-02-21T11:30:01 [WARN ] quotient.e2ee: /run/build/libquotient/Quotient/e2ee/qolmsession.cpp:94: Quotient::QOlmExpected<QByteArray> Quotient::QOlmSession::decrypt(const Quotient::QOlmMessage&) const: "Failed to decrypt the message": BAD_MESSAGE_MAC 2024-02-21T11:30:01 [WARN ] quotient.e2ee: /run/build/libquotient/Quotient/connectionencryptiondata_p.cpp:353: void Quotient::_impl::ConnectionEncryptionData::handleEncryptedToDeviceEvent(const Quotient::EncryptedEvent&): Failed to decrypt to-device event from device ""
The relevant line is 2024-02-21T11:30:01 [WARN ] quotient.e2ee: /run/build/libquotient/Quotient/e2ee/qolmsession.cpp:94: Quotient::QOlmExpected<QByteArray> Quotient::QOlmSession::decrypt(const Quotient::QOlmMessage&) const: "Failed to decrypt the message": BAD_MESSAGE_MAC Did this happen just once or more often?
(In reply to Tobias Fella from comment #5) > The relevant line is > > 2024-02-21T11:30:01 [WARN ] quotient.e2ee: > /run/build/libquotient/Quotient/e2ee/qolmsession.cpp:94: > Quotient::QOlmExpected<QByteArray> Quotient::QOlmSession::decrypt(const > Quotient::QOlmMessage&) const: "Failed to decrypt the message": > BAD_MESSAGE_MAC > > Did this happen just once or more often? Looking through the log files available, filtering on "BAD_MESSAGE_MAC", I see the following neochat.log.0: 2 instances neochat.log.7: 4 neochat.log.9: 2 neochat.log.11: 2 neochat.log.18: 2 I do have another Chat/Channel, that has flatly refused to decrypt anything in that channel in Neochat since I installed the application.
Hi, same issue here: (openSUSE Tumbleweed - snapshot 20240321) neochat 24.02.0-1.1 > grep "\[WARN \] quotient\.e2ee" ~/.local/share/KDE/neochat/neochat.log.* &>> NeoChat_libQuotient_error.txt > grep -i bad NeoChat_libQuotient_error.txt > ~/.local/share/KDE/neochat/neochat.log.3:2024-03-23T09:56:36 [WARN ] quotient.e2ee: "Failed to decrypt the message": BAD_MESSAGE_MAC > ~/.local/share/KDE/neochat/neochat.log.3:2024-03-23T09:56:36 [WARN ] quotient.e2ee: "Failed to decrypt the message": BAD_MESSAGE_MAC > ~/.local/share/KDE/neochat/neochat.log.3:2024-03-23T09:58:03 [WARN ] quotient.e2ee: "Failed to decrypt the message": BAD_MESSAGE_MAC
Hi! We're currently completely reworking the support for end-to-end-encryption and related features in libquotient, the library NeoChat uses internally. While this certainly won't magically fix all bugs we're currently seeing in NeoChat related to these features, it is unlikely that the exact same problems are still affecting NeoChat after the new version of libQuotient. You can track this work at https://github.com/quotient-im/libQuotient/pull/820 The ongoing work on the new cryptography backend also means that we won't be able to spend any time on investigating problems with the current implementation, such as this problem. I will thus close this issue, as it won't be applicable after the switch anymore. Thanks for your understanding :)
(In reply to Tobias Fella from comment #8) > Hi! > > We're currently completely reworking the support for end-to-end-encryption > and related features in libquotient, the library NeoChat uses internally. > While this certainly won't magically fix all bugs we're currently seeing in > NeoChat related to these features, it is unlikely that the exact same > problems are still affecting NeoChat after the new version of libQuotient. > You can track this work at > https://github.com/quotient-im/libQuotient/pull/820 > > The ongoing work on the new cryptography backend also means that we won't be > able to spend any time on investigating problems with the current > implementation, such as this problem. I will thus close this issue, as it > won't be applicable after the switch anymore. Thanks for your understanding > :) I see. Good luck with the rewrite.