Clients should be trusted to write to online megolm backups if they own the priv half of the backup key.

[ara4n]

In the current implementation we only trust an online megolm backup as a valid destination for our megolm keys if we have verified the device who signed the backup's pubkey when it was created.

This is problematic if we're logging into a new device and restore the backup by providing our recovery key, because by definition we won't have access to other devices for crossverification (otherwise we'd be accessing the backup via crossverification rather than providing the recovery key).

So instead we need a different mechanism to decide whether we should write our keys into the backup and ensure it wasn't created by a malicious server admin.

Proposal is that we should take our copy of the recovery privkey, generate the pubkey from it via Curve25519, and then do a binary comparison with the pubkey which the server is advertising for the backup before letting the user trust the backup for storing keys. This code doesn't exist yet, and needs to be written.

@uhoreg, does this seem correct? ^

[sidenote @lampholder: n.b. that is completely independent of the question of whether the private key is provided directly by the user from their sock, or whether the user downloaded an encrypted copy of their privkey from the server and decrypted it via their passphrase.... other than by implementing this correctly, it should be very unusual for users to start new backups, unless they are deliberately rotating their recovery key every N days, in which case they'll have to deal with the faff of maintaining the sock-copy of the private key themselves if they're not storing it on the server, but that's entirely the user's problem.]

[uhoreg]

Yup, that seems correct.

[uhoreg]

This seems to have been implemented.