Prompt to import keys rather than create new ones

[madduck]

If the Riot webapp can't find existing keys in local storage, it just generated new ones, which makes sense if keys can't be imported. However, as this is now possible, I think Riot should instead ask for confirmation and default to nudge the user to import existing keys, unless Riot has a firm belief that this is indeed the first time it's being used on this device (no idea how it would do this).

Otherwise, the user might inadvertedly generate a new key, which is probably undesirable for multiple reasons.

[richvdh]

There is no support for importing and exporting your device keys currently.

[madduck]

@richvdh the "develop" version sure seems to support that…

[richvdh]

No, it only supports import/export of keys for existing conversations.

[ara4n]

@madduck the confusion here is that there are two different types of keys: identity keys (generated per device at login) and "session keys" which are what you use to decrypt particular group conversations. The import/export that Rich talks about is strictly for the conversation session keys, letting you share encrypted history between devices. There is no way or desire to move identity keys between devices. In future we may cross-sign identity keys to make things easier. I think in the end you're basically asking for cross-signing keys, which is #2714.

[madduck]

@ara4n I understand you don't want to share keys between devices, but so many times now my browser lost local storage due to whatever reasons, and there isn't an atomic way to restore just that without clobbering the entire config from backup, which isn't desirable most of the time.

Worse: you might not be aware of what's happening, while your browser or app comes online with a new key, meaning you can't read old messages anymore, and if you were to recover the key, you now can't read new messages encrypted to the new key (which you never wanted).

So I think there's benefit to exporting a backup of the identity key and one should be able to restore it from backup…

[ara4n]

I think we're talking cross purposes :)

On 08/03/2017 20:05, martin f. krafft wrote: @ara4n <https://github.com/ara4n> I understand you don't want to share keys between devices,

You are conflating the two entirely different types of keys together (which is probably our fault for not making it clearer in the UI). Identity keys are used purely for establishing secure 1:1 "Olm" channels of communication between pairs of devices (for sharing additional key data - e.g. session keys). They are *not used to encrypt or decrypt conversation history*. Conversation history is encrypted using "Megolm session keys", which exist for each session of messages sent by a user into a given room. These are what you use to decrypt messages, and these are what we let you export & reimport currently. They get frequently replaced as people join/part rooms, or every N messages, etc.

but so many times now my browser lost local storage due to whatever reasons, and there isn't an atomic way to restore just that without clobbering the entire config from backup, which isn't desirable most of the time.

There absolutely is. This is precisely what export/import session keys does.

Worse: you might not be aware of what's happening, while your browser or app comes online with a new key, meaning you can't read old messages anymore, and if you were to recover the key, you now can't read new messages encrypted to the new key (which you never wanted).

The reason you can't decrypt old messages when you log on with a new browser is because you don't have the *session keys*. For now, you can import them from an export; in the future we'll probably give other ways to migrate them between devices (https://github.com/vector-im/riot-web/issues/2286).

So I think there's benefit to exporting a backup of the identity key and one should be able to restore it from backup…

Just to be entirely clear: it is absolutely nothing to do with identity keys. If you logon with a new device, it will categorically get a new identity key; the entire model is that each device has its own unique keypair. To make *verifying* the ownership of the new device easier, we may in future cross-sign them from an old trusted device: #2714 However, the new device, with its new identity key, is *absolutely* capable of decrypting the message history in the room... if it can be given a copy of the session keys required to decrypt that history. It is absolutely critical to understand that Matrix's "Megolm" encryption is layered on top of conventional public-key encryption. hope this makes more sense! :)

[go2null]

I think this is actually properly described/recognized in #4104