Hacker News new | ask | show | jobs
by wakeupcall 839 days ago
A 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.