Element-web: Explain manual and automated key backup a little better

[aaronraimist]

Lots of people tend to think manual key backup is something like GPG, ie if you export the key as soon as you create your account you'll be able to decrypt all future messages that are sent after you exported the keys.

[aaronraimist]

It also needs to be more clear that key backups to the server are stored on your homeserver. Not some central matrix.org server.

[drathir]

Agree clarify of remote storage in use would be nice in description, also taking on mind if that some kind of private kinda keys would be nice as well get possibility of gpg/passphrase/one time paste style send to email address protection type i guess (theoretically speaking only, bc not checked/searched for type of data send by this feature).

[matthijskooijman]

I just tried setting up automatic key backup and found that there's a lot of stuff that's not really well-explained through the UI. Here's some questions that crossed my mind:

• What is stored on the server exactly? A backup of my room keys, I suppose. Encrypted using a recovery key? Or my passphrase? Or both?
• Where is the backup decrypted? I assume in the browser, so the server never sees the actual keys? Of course, a malicious server could still easily inject malicious javascript to sniff the passphrase and keys, of course...
• How do the recovery key and the passphrase correspond to each other? It seems these are basically equivalent in how they can be used? Or does the passphrase normally encrypt the recovery key?
• How does key backup work with multiple devices? Normally, multiple devices seem to have their own E2E keys I believe? Does key backup allow sharing a single set of keys among devices? Or will they just have their own parallel backups? How does this interact with the key sharing feature?
• Does the recovery key ever change? I've tried a some things with different browsers (also coming back to existing browsers) and found that I got different keys.
• As long as your browser (or other device using key backup) remains logged in, you can always access the original keys, and also setup new backups (even if you forgot your passphrase or recovery keys), right?
• When I enter a passphrase or recovery key, is it stored in the browser? I guess it should (or perhaps an underlying backup encryption key) since it must be able to add new keys to the backup later?
• What does it mean for a backup to (not) have a signature from a device?
• How are backup versions handled? Does any change to the backup (content / keys / etc) result in a new version?

I don't think all of these questions should be answered in the interface directly, but perhaps the UI could be changed to support a more useful mental model of what goes on in the background, and perhaps also link to more complete documentation (I just found https://about.riot.im/help#end-to-end-encryption which has some info already).

[lampholder]

Agreed - we're trying to strike a balance between informative and overwhelming, and to provide enough information to reassure encryption/privacy novices, experts and everyone in between.

This list of questions is very useful - we can take another look at the wording/UX with this in mind and see what we can change to answer more of these questions as you work your way through setup.

[turt2live]

This is becoming more prevalent thanks to recent events. There's numerous reports of people taking their exported keys from months/years ago and trying to import them, expecting that to work. We should fix the messaging so that in N years we don't have to tell people that export !== backup.

[cyphar]

I will admit when I first turned on key backups I went to read the MSC to make sure I understood how the system actually worked -- which is far from ideal if we want the security of the system to be self-apparent (as an aside I think the design is really brilliant). I think the simplest way to improve people's understanding of how key backups work is to apply a couple of helpful tips (which might help some of @matthijskooijman's questions):

• Add a (probably red) warning to the key export feature explaining that in encrypted rooms the session keys will roll over quite regularly and thus exported keys will not be useful for decrypting future messages soon after you've done the export. This is the biggest mistake I've seen and it's a shame we didn't have better text on this before (I know I've made this mistake before -- and only realised when I noticed the key exports were getting larger each time I did an export).

  • There should also be a button for using key backup on the key export page to hopefully explain that key export requires more work on the users' side. Most of the text on key export could probably be dropped to make it more likely people will read it.

• Change the key backup setup flow, so that you first get the recovery key and then are asked for the passphrase (with some text on the passphrase prompt saying that it's optional -- but recommended -- that the recovery key be encrypted and saved to the homeserver so that the user doesn't have to keep track of it). This might help users understand that the recovery key is the primary recovery system and the passphrase is just there to not require you to keep track of the recovery key (the current text is "We'll store an encrypted copy of your keys on our server. Protect your backup with a passphrase to keep it secure." which is quite misleadingly-written -- arguably it's more secure to not set a passphrase since then the private key never hits the server).

• I would suggest having a (skippable) "getting started" screen for enabling e2e encryption which might explain some of the questions that @matthijskooijman mentioned above. Since the plan is to make all private rooms e2e-only we should probably work on the onboarding flow now rather than later.

  • I think there is a fairly good "intuitive" way of explaining how key backups work (you could even do it graphically to help get the point across) -- padlocks and keys. When you set up key backups, you create a new key and a large number of corresponding padlocks. You keep this key safe, and whenever you're chatting with someone and you get a new session key you put it inside a safe box and lock it with a padlock and send it to the homeserver -- you only need the recovery key when you need to do a recovery. I bet that a lot of confusion could be avoided with some picture-based explanations (something like the Keybase art style would be great IMHO).

[jryans]

Perhaps we could restructure some of our in-app messaging to show first the simplified explanation for everyone, but then add a disclosure something like:

More details

Advanced encryption explanation details go here.

so that we can still offer more detail for those who want without overwhelming those you don't.

[cyphar]

That would be a good stop-gap to at least provide some sort of information to those who should be aware of things, but I think that all the E2E messaging needs to be made layperson-friendly if we want people to turn it on (or make it the default) without being surprised when the last 12 months of chat history with their loved ones has gone up in smoke (I'm a technical user and this happened to me, but it's a painful mistake to make).

I'm aware (and really grateful) that the technical side of this is being worked on very hard (and the results speak for themselves -- the new e2e features are really top-notch), but making a good on-boarding experience with encryption (or even Matrix in general) would really help users avoid some pitfalls.

I'm fairly convinced the best shot of making it reasonable is to do it graphically (I'm _really_ not an artist but I could knock up some mock-ups to hopefully show why graphical explanations would help). Unfortunately you'd need a designer to actually make them usable -- and they are painfully hard to find within free software communities (despite how desperately we need them in most free software projects).

[35609902357]

@cyphar

it's more secure to not set a passphrase since then the private key never hits the server

Is this a thing embedded into the client (such as Riot) or does this happen at the protocol level (Matrix)?
Is it possible to delete the backup from the home server once the passphrase has been inserted by removing the passphrase or are there any methods to do it?

[cyphar]

Is this a thing embedded into the client (such as Riot) or does this happen at the protocol level (Matrix)?

The protocol defines how key backups work. Basically, your "recovery key" is the private half of an X25519 keypair. All new session keys get encrypted by clients using the public key (so you only need the private half when you first import your keys). Optionally, you can symmetrically encrypt the X25519 private key with a passphrase, and then that encrypted private key gets stored on the server. But since the private key is generated on your client, if you don't set a passphrase then the server never sees the private key.

Is it possible to delete the backup from the home server once the passphrase has been inserted by removing the passphrase or are there any methods to do it?

There's a "delete backup" button in the key backup settings. I don't think you can currently delete only the passphrase (while keeping the backup), but if you delete the backup and then create a new one it will contain all of your keys (and you can not add a passphrase).

[35609902357]

@cyphar I'm having trouble understanding how it works. Whether I encrypt the backup with a passphrase or skip the passphrase and go directly for the recovery key, the backup status shows Backup key stored: not stored in both cases, but I figure it should say it's stored if I input a passphrase, thus saving it on the homeserver, why is it not the case?

Moreover when restoring a backup protected with a passphrase I get the passphrase prompt, but if I can't remember it I can skip to the recovery key without providing the passphrase, but then where does it retrieve the backup from? If it's on the device's internal storage then skipping the passphrase and inserting the recovery key on another device added for the first time should not recover any key, is this correct?

[cyphar]

@35609902357

but I figure it should say it's stored if I input a passphrase, thus saving it on the homeserver, why is it not the case?

I think it should say that too, that might be a bug, I'm not sure.

Moreover when restoring a backup protected with a passphrase I get the passphrase prompt, but if I can't remember it I can skip to the recovery key without providing the passphrase, but then where does it retrieve the backup from?

The actual session keys (the keys you are backing up) are always stored on your homeserver, encrypted using a asymmetric Curve25519 keypair. If you enter the "recovery key" you are actually entering the private key for a Curve25519 keypair (the server keeps the public half, and gives it to your devices -- so they can add entries to your key backup without storing or prompting for the private key). However if you add a passphrase then your homeserver also stores a copy of the Curve25519 private key (the "recovery key"), encrypted with the passphrase you chose.

From my understanding this design has changed somewhat since the introduction of SSSS (which is how cross-signing has been implemented), but the broad strokes should be the same.

[35609902357]

@cyphar
So inserting a passphrase and saving the private key on the homeserver simply means adds the convenience of choosing the passphrase to restore backups instead of saving the random recovery key?

And that IF you choose a strong passphrase the history is safe, but if the passphrase is weak then you might potentially compromise the security of all your messages?

So if I lose access to all my devices, and I only have my passphrases, I add another device without any trace of previous local activities/backups, would I be able to recover all my encrypted history by only providing the recovery key? Would the only difference be inserting the recovery key by myself instead of inserting the passphrase to decrypt it and letting the homeserver insert it for me?

[cyphar]

@35609902357

So inserting a passphrase and saving the private key on the homeserver simply means adds the convenience of choosing the passphrase to restore backups instead of saving the random recovery key? And that IF you choose a strong passphrase the history is safe, but if the passphrase is weak then you might potentially compromise the security of all your messages?

Yes, though in order to exploit this you'd need to either be a homeserver owner or have the users' password to get access to the key backup.

So if I lose access to all my devices, and I only have my passphrases, I add another device without any trace of previous local activities/backups, would I be able to recover all my encrypted history by only providing the recovery key?

Yes. This is what I do, and I have lost my devices before (both before and after the introduction of key backup -- it was much easier to deal with when key backup was added).

Would the only difference be inserting the recovery key by myself instead of inserting the passphrase to decrypt it and letting the homeserver insert it for me?

Yes, though the server doesn't do the decryption of the recovery key or key backup for you (for obvious reasons) -- it's done client-side. Aside from that, that is correct.

[35609902357]

@cyphar
Then it sounds like a silly feature to have, not only it's a waste of coding effort, but it can only endanger the security of the backup because a passphrase secure at least as the recovery key will most likely have to be stored in a password manager (or other means) anyway, and the average Joe will certainly choose a weak passphrase. So the whole thing sounds entirely like a detriment and should not be explained better, but totally removed. Or are there any upsides I'm not seeing to having it?

[ara4n]

So the whole thing sounds entirely like a detriment and should not be explained better, but totally removed. Or are there any upsides I'm not seeing to having it?

It's hard to guess what you're not seeing.

The pros are:

• You can recover all your message keys if you lose all your devices (particularly easy if you only have one device).
• You don't have to rely on manually exporting your message keys.

The cons are:

• If you choose a weak passphrase, someone with access to the backup (a server admin, or someone who has compromised your account password) can get all your message keys.

It's not clear why you think that storing a recovery key or recovery passphrase in a password manager is a bad thing.

[cyphar]

@ara4n To be fair, they're arguing that recovery passphrases are a "bad feature" because if the user could pick a strong passphrase they're probably using a password manager and thus could just store the recovery key. If they can't store a recovery key, then their recovery passphrase is probably weak and we shouldn't encourage them to use passwords if they're likely to be weak. Not to mention that most users (sadly) do not use password managers.

My view is that it's a trade-off which is entirely up to the user, and the pain of losing messages with your loved ones is much more likely to disenfranchise users than any system which permits weak passwords. (Not to mention losing your messages was basically guaranteed with the old key backup system, because you had to constantly keep backing it up -- something that even more technical users like myself managed to misunderstand.)

Personally I think we could do more to make authentication less vulnerable to bad passwords (such as having 2FA support :wink:), but this is perhaps an example where explaining to users that the password is optional (and should be very strong) but that it requires more work on their side is probably a good idea.

[ara4n]

oh, okay. yeah, we could forbid recovery passphrases and just mandate recovery keys.

[35609902357]

@ara4n I apologize if I came across as dismissive, it was not my intention. @cyphar made an excellent job explaining my concern and providing the reason I was not able to see, that there are users who care more about preserving message history than security. Then yes, it makes sense passphrases should stay, but should be explained better to make as clear as possible the risks stemming from a weak passphrase, and above all the fact that providing the passphrase itself is not mandatory, nor added security and that it means the recovery key will touch the server if provided. It should also be the other way around, the recovery key should be provided at first with a secondary toggle to enable passphrase backup.

[cyphar]

It should also be the other way around, the recovery key should be provided at first with a secondary toggle to enable passphrase backup.

I agree with this suggestion -- I struggled to understand what was going on with the key backup setup flow until I looked up the MSC. If it was explained as "here is the important secret, and if you can't remember it safely you can store it on the server by encrypting it with a passphrase" it would be much more approachable -- right now it looks more like the recovery key is a randomly-generated passphrase because you have to click away from a password dialogue to get it.

[35609902357]

Matrix is on the verge of enabling E2EE for 1:1 chats by defaults (#6779), this means this issue has become more urgent. I thought of a way to phrase the Key backup dialog, which I think will satisfy both technical and non-technical users. Please modify/improve it as you see fit.
In order to avoid confusion, the Recovery key should only be displayed if the "Safest" option is selected, with the current dialogue with "Copy" button. A user should not be allowed the possibility to undermine the safety of all recipients by choosing a weak password, thus matrix-org/synapse#5112, MSC2000, matrix-org/synapse#5214 and matrix-org/synapse#7118

#

Matrix protects your 1:1 chats with end-to-end encryption by default (for group chats E2EE can be enabled in the room settings). This means that messages can be read only by you and your recipient(s) and no one else, not even server administrators. Your encryption keys change constantly to ensure Perfect Forward Secrecy and they are backed up encrypted on your home server of choice.
WARNING: if you lose access to your devices your Recovery key is the only mean to recover history and there is no way to recover a lost Recovery key.

Choose an option for managing your Recovery key:

[Safe] Your Recovery key will be backed up on your home server and encrypted using your account password.
[Safer] Your Recovery key will be backed up on your home server and encrypted using a password you will choose in the next step.
[Safest] Your Recovery key will not be backed up on your home server and it will be displayed to you in the next step. Be sure to save it somewhere safe. We strongly recommend you use a password manager such as Bitwarden (recommended for non-technical users) or KeePass (recommended for advanced users).

#

[aaronraimist]

Your Recovery key will be backed up on your home server and encrypted using your account password.

I don't think that is an option?

Also for the other two options, the recovery key is not being backed up AFAIK, the keys for decrypting messages are. It is always on you to store the recovery key.

[35609902357]

I don't think that is an option?

It is not. I opened #13263.

Also for the other two options, the recovery key is not being backed up AFAIK, the keys for decrypting messages are. It is always on you to store the recovery key.

The Recovery key is actually backed up. Read @cyphar's good explanation about it.

[aaronraimist]

OK yes I misread your wording. Yes the recovery key can be backed up in an encrypted format but that doesn't do anything for you if you lose the password.

I don't think #13263 is a good idea. Key backup needs to get simpler (less options), not more complex (more options).

Imo the UI should be something like this:

---

Your private chats are end-to-end encryption by default (encryption can be enabled in other rooms in the room's settings). This means that messages can be read only by you and your recipient(s) and no one else, not even server administrators.

To ensure you don't lose message history you can backup the message keys. Riot can automatically back up message keys up in an encrypted format to your homeserver or you can manually download them to your computer.

If you chose to do manual key backups, they must be done regularly to ensure you don't lose messages since encryption keys change constantly to ensure Perfect Forward Secrecy. The downloaded key file can only decrypt messages sent before you pressed the download keys button. It cannot decrypt any future keys. Automatic key backup is recommended for this reason.

[ Button: Use automatic key backup ] [ Button: Use manual key backup ]

---

If the user chooses to use manual key backup then all of the automated key backup stuff is hidden and can be shown again by some small button saying switch to automatic key backup.

If the user chooses to use automatic key backup then the user is walked through setting that up. Imo the only way to set this up should be to use a recovery key which the user is told to store in a password manager or print and store securely. Having a second password is not great because most users are going to get confused on what the difference is between the two passwords and will likely either use the same password for both or will use a less secure password.

The manual key backup buttons are still available in this mode but are smaller/de-emphasized.

[35609902357]

@aaronraimist
Word it like that and you are guaranteed to push away 100% of users who you will propose Riot to. #13263 will grant non-technical users a familiar experience. For them step 2 is one step too much. If you tell them "download this app, but be sure you regularly backup keys and store the Recovery key in a safe place, else you may loose chat history" and you will make sure they continue using Zoom forever. How many people need manual backup? I would go as far as to say #13263 should be the default and the other options should be unlockable clicking a toggle, all in order to ensure ease of use by non-techhies, but I think the multiple choice I wrote should be a happy medium for everyone. GPG failed because it was not easy to use, for non-techies to use a software it must be idiot-proof, otherwise enjoy your loneliness in Matrix while the others hang out in Zoom, which you yourself will be forced to use some way or another. I wrote it like that because I don't want to explain users how they should use the application, I want to say "Install Riot and let's hang out there" and let them understand everything by themselves on first use.

[aaronraimist]

The account password cannot be used for encryption if want to prevent the homeserver operator from reading encrypted messages. The account password is sent to the homeserver and the homeserver operator has full ability to change it.

It's impossible to please everyone. I agree it would be great to just have one way to do it and not need two options but the ultra privacy conscious would have a fit if automated key backup was the only way to backup keys. Yes that's probably only a small percentage of users but I don't know a better way to handle it.

Maybe it could be reorganized to present automatic key backup as essentially the only option while still leaving manual key backup there but you have to go looking for it.

---

Your private chats are end-to-end encryption by default (encryption can be enabled in other rooms in the room's settings). This means that messages can be read only by you and your recipient(s) and no one else, not even server administrators.

To ensure you don't lose message history you can backup the message keys. Riot can automatically back up message keys up in an encrypted format to your homeserver.

[ Button: Setup automatic key backup ]

Advanced: Manual key backup

If you chose to do manual key backups instead of automatic key backups, they must be done regularly to ensure you don't lose messages since encryption keys change constantly to ensure Perfect Forward Secrecy. The downloaded key file can only decrypt messages sent before you pressed the download keys button. It cannot decrypt any future keys. Automatic key backup is recommended for this reason.

[ Button: Use manual key backup ]

---

[35609902357]

The account password is sent to the homeserver and the homeserver operator has full ability to change it

If this is true it's a problem, first because many people simply use their account passphrase for that too, which it usually is the same password for all their other accounts, and second because this complicates things for normies. Could it be possible to match the hash in order to refuse the backup passphrase if it matches the account passphrase?
I'd say leave manual backup out of the first time wizard, it would be a scarecrow. Things should be as easy as possible for the Whatsapp/Zoom folks. I think if Matrix play this good, it's still in time to steal millions of users to Zoom and unify them and the Signal/Wire folks in a huge matrix of people, but for this to happen effort should be addressed toward ease of use, easy and pleasant first time wizard with clear options and easy to use default values, with the possibility for power users to choose more advanced options, and pleasant UI. I could easily get many people on board since Zoom exploded, if we only had a fully functional RiotX client or at least an experience which doesn't require further instructions than "install it and go". This is Matrix's golden chance to become a matrix of people, not only of services. The most important bridge it needs is the one to get non-techies on board. @ara4n what do you think the best solution would be?

[aaronraimist]

Yeah I agree to leave it out of the first time wizard. It wouldn't do anything at that point anyway. I meant that would be the UI in settings for people who hadn't setup automatic key backup during account creation.

[aaronraimist]

although some of that text explaining automatic key backup should make it to the first time wizard

[LinAGKar]

The account password cannot be used for encryption if want to prevent the homeserver operator from reading encrypted messages.

What if you hash the password the user enters, and then send part of the hash to the server for authenticating, and use the other part as the key backup password (and maybe for automatically being trusted by your other clients)? That would prevent the server from using your account password from reading the key backup.

It wouldn't keep the server from reading it if you reuse an old account password, and it would require entering the hash fraction as the password in other clients (unless the server stores multiple passwords), but it could work to make key backup easy in the long run.

[35609902357]

It sounds too complicated for normies, probably that feature can't be implemented in a way that's both safe and easy, then just forbidding the users to use the account password for key backup should at least avoid disasters in case of password leaks. Then when cross-signing will be properly implemented it will further reduce chances of losing data.

[LinAGKar]

Quite the opposite, it should be easier, since the key backup would be set up automatically just by logging in, no further action required. Though only in clients that support it, but that's a transitional problem.

[Perflyst]

I personally dont want a key backup on the server. And I dont think I am alone. "Automatically" wouldnt fit for everyone

[bigCrash]

A little bit OT, but I found no other place and it is more or less a documentation request regarding the recovery key, so here comes my question.

If I change the recovery key, do I keep my message history as long as at least 1 of my devices is logged in? Can this device "share" the history of encrypted chats with the new recovery key?

I am asking since I changed my recovery key and subsequently my other devices were classified as non-trusted (e.g. cross signing for those devices was disabled).

This does not make sense to me since I would assume that the respective encryption and cross-sigining keys are already on those other devices and only the backup of those keys (on the homeserver) would be updated with the new recovery key.

[aaronraimist]

Related: #14421

[LinAGKar]

It sounds too complicated for normies, probably that feature can't be implemented in a way that's both safe and easy, then just forbidding the users to use the account password for key backup should at least avoid disasters in case of password leaks. Then when cross-signing will be properly implemented it will further reduce chances of losing data.

The same thing I suggested is already used by Firefox sync: https://hacks.mozilla.org/2018/11/firefox-sync-privacy/

[LinAGKar]

And deriving both the account key and the recovery key from the user entered password would allow completely getting rid of recovery key management and device verification, since it could establish trust using the derived recovery key just logging in, which would significantly reduce friction for new users. Having to explicitly verify devices to establish trust could then be an advanced option most users wouldn't need.

Add TOFU to that, and most people would never to bother with device verification.

[t3chguy]

@LinAGKar it would also be incompatible with LDAP auth and SSO/SAML