Motivation
One of my internet friends had quit Discord and decided to use Element/Matrix for a more secure, privacy-respecting option.
I would be using Element more often, but every time I try to use it, I run into consistent errors that have perplexed me for years. Allow me to document them here, for two reasons: (a) to perform a sanity-check to make sure I am not missing any UI options, and (b) to invite somebody more knowledgeable than me to suggest a solution.
I have seen other people (on the Fediverse) complain about Element, but it is only in the relatively superficial ways, like, "the developers won’t permit my custom emoji!!!" or "the app doesn't work on Graphene!!!" These strike me as relatively petty complaints. By contrast, my complaint is: I literally cannot view my chat history (encrypted messages that had been sent in previous sessions), no matter how hard I try. A pretty fundamental problem.
Allow me to explain.
User Experience
I open "Element" and it shows a standard list of my servers (and a few Direct Messages), but in the upper-left corner, there is a small popup saying: "Verify this session. Others may not trust it." So I click "verify" to make sure others can trust it and send encrypted messages to me, because, why else would I be using the app in the first place? My two options, as you can see below, are "verify with another device" and "verify with security key." I try to apply a key that I had downloaded in early January 2022, but I immediately see, in red letters "wrong file type."
The next logical step is to investigate the contents of the key file. I do this, and I see a header and footer that specifies “MEGOLM SESSION DATA.” This is awfully similar to the kind we see in ASCII-armoured PGP key file. But the weird part is, when I use the Unix `file` command on such a key file, I'll see a description like "PGP public key block Public-Key." Are the magic bytes in the session key inaccurate? This would be counter-intuitive, given the fact that I downloaded the session key using the Element client itself! Meanwhile, if I enter in a Security Key manually (rather than by uploading a file), it says “Invalid Security Key.” None of it works!
Figure 1. Verify This Session
Figure 2. Security Key option.
Let’s try the other method for verification, shall we? I try to verify using another device. For now (since I have refused to put encrypted chat on my phone, given the slew of security vulnerabilities that exist on mobile devices), this means pulling up a tab on my browser and using that as my “second device.” Sure enough, this environment does indeed receive a request from my Element app that seeks to verify itself. I jump through a couple of hoops, basically confirming that on both windows, a random sequence of seven emojis appears in the same order; and finally, I see a confirmation popup that reads “You’ve successfully verified Element Desktop Linux.” It also contains a ten-letter long code in parentheses – presumably, the same Security Key that failed in the previous paragraph.
I move to the “Settings” icon, navigate to “Security and Privacy,” and see a list of “unverified devices.” Here, there is a huge list of my previous sessions, marked as “app.element.io: Firefox on Linux.” It even specifies the timestamp of “last activity” on that “device.” The problem is, I cannot access most of these sessions. One would think the root of the problem is that my browser is set to “Delete cookies and site data when Firefox Developer Edition is closed;” however, the problem with that hypothesis is that I have long since listed “app.element.io” as an exception to this rule (see Figure 2), so any relevant data should not be getting deleted!
Figure 3. Exceptions to Browser Cache Deletion
Basically, there appears to be a difference between “Encryption Keys,” which may or may not be the same as the keys used for encrypted rooms, and the “Security Key,” which is a second-order construct that protects said Encryption Keys. In the settings page, the text reads, and I quote, “This session is not backing up your keys, but you do have an existing backup you can restore from and add to going forward.” The first source of confusion is the use of “backup” as a noun rather than an adjective or a verb; but presumably there is one and only one Collection where all my encryption keys had been stored. Under this heading, there are three buttons: a green button saying “Connect this session to a Key Backup,” a red button reading “Delete Backup,” and another red button labeled “Reset.” I still have no idea what the difference is between deleting a backup and resetting it, but as soon as I click to “Connect,” we’re right back to the problem in Figure 2, i.e. “Use your Security Key to continue.” This whole troubleshooting adventure is turning into a flowchart with arrows heading backwards and no end in sight!
To make matters worse, while I was doing experiments in the course of writing this article, I tried “checking” all the boxes beside these old sessions (“unverified devices”) and clicking the “Sign out” button – which evidently made it more difficult for me to “verify” sessions in the future! Perhaps this was a mistake. You tell me.
Judging by web results, other people have had similar problems as recently as 2020 and 2021. This Reddit post seems to match my problem fairly well, but there is only one response, and it says to post an issue on GitHub. The OP says he solved it by “creating a new account.” Sure enough, somebody else did post an issue on GitHub, but the only advice there was to “reset secure backup first” and then reset “cross-signing keys,” which appears to be a third, entirely different kind key! One comment that I am still processing says that “cross-signing and secret storage have somewhat complex, cyclical dependencies between each other” (jryans). The more I read it, the more my head spins.
Conclusion
If you’re reading this far, I invite you to suggest a solution for me. But really, this is just another opportunity for me to ask, am I the only one who struggles with this?
Perhaps there are multiple takeaways to this article: one is the gradient between theory and applications. I have taken a course in cryptography, yet I still do not understand what the hell the Matrix devs are doing. Even if you understand public key exchange protocols and can name private key cryptography protocols like AES-256, there is a certain depth of understanding that needs to be established in order to actually implement the protocols.
Or perhaps the takeaway is that Matrix devs need to improve their UI – which is quite the statement coming from me, the guy who manages a retro website and loves Unix terminals. People have argued to me that PGP is complicated and tedious to use, but I would sure rather type short PGP commands at a shell than struggle through vague and self-contradictory dialogue boxes.