3 ms·
This just sounds like a description of Matrix's key sharing mechanism? Messages are supposed to be unencryptable if you don't have the keys, and bringing online
by creatonez 3y ago
This just sounds like a description of Matrix's key sharing mechanism? Messages are supposed to be unencryptable if you don't have the keys, and bringing online another device (or having all your keys pre-shared so you don't have to) is what provides the keys. If you want to avoid this altogether, the UI prominently advertises the optional encrypted key backup service provided by the homeserver, and various manual options for sharing keys.
If FluffyChat is not having this issue, it is probably overly eager to share encryption keys instead of allowing the user fine-grained access to control keys, which is successfully hiding the complexity of the ratchet encryption but potentially exposing the user to attacks to force the sharing of keys.
Edit: I was looking around. While Matrix is well documented, Element's documentation is poor because they expect you to figure things out from popups in the UI -- fair enough, unfortunately most apps are like this, and Element's popups have gotten a lot clearer. But I did find these two pages from a university that seem to serve well as "Element's missing manual". Worth a read if you are trying Matrix for the first time, because it discusses some things that can look like bugs but are really user error.
https://docs.matrix.kit.edu/en/settings/ https://docs.matrix.kit.edu/en/settings/
https://docs.matrix.kit.edu/en/faq/ https://docs.matrix.kit.edu/en/faq/
- rcxdude 3y agoreading a manual for a chat app to fix 'user error' that results in bizarre behaviour like this is not a reasonable solution.
- wakeupcall 3y agoA bit late to respond, but this is not an user error. From the bug description it SEEMS (because there's still zero feedback from the dev's front) that it's Element itself failing to send the keys in the first place, probably due to a mishandled connection/transmit error and not attempting to retry. It's not a protocol error, unless you count the fact there isn't a mechanism in place to ack at least asynchronously that decryption is ok. This is compounded by the fact that there seems no mechanism to recover for the receiver. The receiving client is just oblivious, it will _never_ be able to decrypt the messages and thus also never be able to backup the session keys if none of the clients associated with the account ever received the keys. The suggested work-around is forcing the sending client to rotate the session keys earlier and thus fix the _following_ messages only. I've been in situations where two element clients (both sending and receiving) failed to decrypt each other's messages. This is a pretty damning issue for a client that enables encryption by default.