What is verification? What does it involve doing? A lot of information on why it's useful, but how is it implemented? I hope it's not something like the Play Integrity API, but with no information to go on, I can't say either way.
> After Alice logs in on a new device, she uses her cryptographic identity to demonstrate to Bob that the new device genuinely belongs to her, rather than being added by someone else with access to her account. She can do this either by entering her recovery key (which gives the new device immediate access to her cryptographic identity ), or by carrying out an interactive verification from an existing verified device.
So is this like the Signal PIN which is required when installing on a new device? If you forget, the cryptography changes and old contacts are warned that signatures are rotated, right?
Quite. I have yet to manage a verification between clients.
I have had all variations of clients ignoring requests, reporting requests only for the requesting client to ignore the response. Both ends quitting declaring that the other end cancelled, asking for the other end to input a code while the other end shows no interface for doing so.
It marked the end of me using Matrix as a platform. I'd go back to the old IRC channels if there were anyone still there.
In this case, it's what you do when signing in from a new device (or browser) to attest that it's yours. It avoids warnings to you and your contacts that a device has gained access to your account without your approval.
It involves doing one of these things:
- Comparing a short sequence of emoji on each device and confirming that they match.
- Using one device to scan a QR code displayed by the other.
- Entering a recovery key (a line of text) that you were given when you first set up the account.
Pretty quick and easy in most cases, although some clients can be glitchy in this area and require trying again.
(Gripe: The recovery key approach was unfortunately made painful and error-prone in recent Element releases, by disabling the option to choose a passphrase instead, but most people can simply use one of the other two approaches.)
The experiences reported here seem to say otherwise...
As others, anyhow, I haven't tried again recently
> (Gripe: The recovery key approach was unfortunately made painful and error-prone in recent Element releases, by disabling the option to choose a passphrase instead, but most people can simply use one of the other two approaches.)
I last tried Element about six months ago, but for years using the recovery key was either impossible or close to it, and mostly just for idiotic UI mistakes that were never corrected (something like you had to enter the key where they wanted the passphrase or the opposite).
To my recollection the version from six months ago worked better in that regard, but it was still asking to enter the passphrase where you actually had to enter the recovery key.
I think current Element versions accept either a recovery key or recovery passphrase in the same input field, so there's no getting it wrong. Since you seem focused on UI, it's worth noting that Element X (their beta mobile app) has a greatly simplified interface; their team clearly has been working to make it easier.
Also, other clients exist.
For whatever it's worth, I've been using Matrix for about five years, including some of its roughest times. I seldom see errors these days, but I can understand how folks who were frustrated with earlier iterations would still be soured to it. Such is the nature of an ambitious work in progress, I suppose.
I use it because there is nothing else with the combination of features that are most important to me, and because (despite my gripes) I can see slow and steady improvement. I think it's moving in the right direction overall. I could picture introducing family members to it once Matrix 2.0 is released and the implementations shake out any early problems.
In short, the passphrase works with both and the recovery key with neither, specifically:
Element classic has two separate fields; if I input the recovery key (in the correct field), I get told "Backup could not be decrypted with this PASSPHRASE: please verify that you entered the correct recovery passphrase."
That's how it was the last time I used it, and if I'm not mistaken it's been for years.
Element X has a single field, that supposedly takes both passphrases and recovery keys, but if I enter the recovery key I'm directed to a "Verify with another verified device" screen, even if I had logged out from all other sessions.
Funnily, by the way, it seems that with Element X you can't do anything if you don't manage to get verified, there just doesn't seem to be a way to skip it.
Furthermore, after signing out from Element X I'm unable to even just logging back in, I get an error ("Sorry, an error occurred") after I enter the credentials; even after clearing all the app's storage. Very, very weird.
The new login-via-browser is pretty problematical, by the way, I could only make it work with Chrome.
> Element X has a single field, that supposedly takes both passphrases and recovery keys, but if I enter the recovery key I'm directed to a "Verify with another verified device" screen, even if I had logged out from all other sessions.
I have just tried this on Android.
I am directed to
1) "Device verified - Now you can read or send messages securely, and ... - [Continue]"
2) "Help improve Element X ... [OK] [Not now]"
3) list of chats
Element X Android fyi. No problems logging in using Firefox.
Since you didn't share all the details of your tests, I'm having trouble picturing how I could try reproducing what you did. (That's okay; I'm not an Element maintainer.)
However, a couple of things occur to me:
- No Matrix client that I know of supports setting both a randomly generated recovery key and recovery passphrase on the same account. So in order to test both, you would have to use a separate account for each. If you tried to test both on the same account, it's expected that one of the two would be rejected.
- You didn't specify a platform, but since you wrote "Element classic", I guess you must mean Android or iOS. I used Element Desktop / Web to set up my accounts, which could explain why I saw different prompts.
I hope you reported the error message referring to a passphrase when a key had been entered. I imagine that could leave the user wondering whether they had made a typo or the app had misinterpreted what they typed, which would not inspire confidence in it.
That is true, but what weakens my confidence is that the Element/Matrix team often doesn't present it that way. So much communication from them is about how it's amazing and great and the best messaging app in the world. If they presented it more like a typical slow-growth open source app I think they'd garner more goodwill. By setting high expectations they increase the likelihood of disappointment.
Discord does not do any sort of end-to-end encryption. All messages are fully readable and writable by Discord. Discord decides whether you are who you say you are, and all clients trust whatever Discord says to be trustworthy.
> The recovery key approach was unfortunately made painful and error-prone in recent Element releases, by disabling the option to choose a passphrase instead, but most people can simply use one of the other two approaches.
honestly it's the best thing ever they have done:
- I have heard of someone who failed to use Matrix, because he got frustrated of having not a secure enough passphrase
- people don't choose secure passphrases
- it provides options making things more complex (especially when guiding others)
- you know you won't memorize it, so you are more likely to put it down
1. Generating a random key by default (but still allowing advanced users to prefer a passphrase) would solve your "secure enough" problem.
2. Better yet, a "secure enough" passphrase could be generated by default, à la Correct Horse Battery Staple. A user wouldn't be forced to choose one.
3. When adding an option, interface complexity can be avoided by simply not showing it by default, or by placing it off to the side in collapsed state where it doesn't draw attention.
4. If you're worried about people writing down a passphrase, you should be even more worried about a string of 50 random characters.
That last one is important. Nobody is going to memorize a random key, which means everyone has to write it to a file (or painstakingly write it on paper) for long term storage. When verifying remote devices, they also have to get the key to the other devices, so they are likely to use copy/paste, which will put it on at least two devices' clipboards, where it will be available for harvesting by nosy apps/websites or accidental pasting to random ones. They also have to figure out a way to transport the key from one device's clipboard to another, which might be email or SMS or some other insecure channel that they're accustomed to using. Or in the unlikely event that they choose paper, they have to painstakingly transcribe it again at the other end.
In other words, forcing the use of a random key does not increase security vs. a well-implemented passphrase system, but instead pushes responsibility for security out of the software and into the hands of people who aren't trained in it. Inviting more big mistakes.
A passphrase would avoid most of those exposure risks by not having to be written down or copy/pasted or sent through insecure channels. And with the right UI, it wouldn't be more complex to use or less secure.
Fortunately, Matrix supports passphrase-derived keys at the protocol level, so client developers who understand how to implement them well for humans can still do so. I hope Element's product managers will come around eventually.
I was afraid of that as well given the wording but, no, it's nothing to do with third parties at all. Just when you log into a new device, you confirm it on your old device so it knows it can transfer encryption keys for old messages to the new device
This has been in Element/Matrix since forever and I found it the easiest verification mechanism of all the encrypted messengers I've tried. I'm not surprised they're making this part of the standard process, but the wording in 2025 is... unfortunate. Or perhaps that adjective should be applied to the rest of the world since it's not the Matrix Foundation which changed. For the reader to decide ^^
In the current state, it's basically just a self verification. When you use a new device it shows a series of emoji on each device and asks you if they're the same, then the device is verified.
Thankfully, no, it's not anything evil like Play Integrity is. The simple explanation is that the first time you log in to an existing account from a new device, you need to go on one of your old devices and confirm that the new one is yours.
I’m a server admin and I still couldn’t tell you why when I sign new endpoints in and verify for cross-signing it still also asks me for a recovery key.
For encrypted search on desktop it has to fetch batches of messages and this is configurable in settings. It just had a number? what is that? how large the batch is, how many ms? no clue! good thing we can’t do encrypted search on mobile/web.
Yeah, I was wondering this as well. At the very least, this appears to be an Element requirement that was just enabled by a Matrix protocol update, so moving would be possible, but afaik Element is extremely popular as far as Matrix goes.
