Multi-Device Setup for easier onboarding / QR + noise

[hpk42]

Introduce functionality to core that helps to setup a second device with all contacts, chats, messages and crypto keys.
For this we need to establish a trusted network transport between two DC apps. Core could integrate libp2pin order to establish e2e-encrypted communication between two cores. The address information and a pre-shared key for the e2e-encryption could be transferred through a QR Code, for example a "Request Device Setup" code containing address info and maybe an ephemeral key. The existing DC device can scan this, the user is asked to confirm "do you want to transfer your setup to ..." and if so, will use libp2p and the QR-data to establish a safe connection between the two devices. With #1729 implemented we can then reuse the streamable export/import functionality to complete the setup of the second device.

This issue supsersedes #803 which discusses another way to establish a connection through WLAN with SKT (https://0xacab.org/dkg/openpgp-skt/blob/master/skt-server.c). Given that libp2p already exists as a crate and is used from several projects, it makes more sense to use that.

Update: See #1954 for a PR that was postponed; some work was already started there.
We first planned to use libp2p but the noise protocol is probably better.

[Hocuri]

Also see #1611.

[Hocuri]

@hpk42 As far as I can see that, libp2p works by specifying the ip address. Does this mean that we require the devices to be in the same wi-fi?

[Hocuri]

Or could we maybe use the webrtc connections that are being introduced for calls?

[hpk42]

problem with webrtc is that we don't have any network code in the core and it wouldn't be easy to get it in -- it's a rather complex stack. But yes, we could let the frontends try get a webrtc data connection.

…

On Tue, Jul 28, 2020 at 00:58 -0700, Hocuri wrote: Or could we maybe use the webrtc connections that are being introduced for calls? -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #1731 (comment)

[link2xt]

Prototype of sending files with Rust using hypercore-protocol is at https://github.com/Frando/sendtar

[r10s]

this issue is a bit outdated, recent tests go towards using webrtc; moving issue to resurrection therefore.

[pt1997]

I've just been in the situation of setting up delta chat on three devices.
On iOS there was the option to scan a QR code for setup but i couldn't figure out where that code is in the desktop or android version.

Hence I needed to:

0. use the web interface of the Mail provider to enable IMAP and SMTP
1. enter the E-Mail address, password and server configuration
2. open the settings scroll down click "Send Autocrypt Setup Message"
3. type that long number in the new device
4. go to the settings there - My Profile - password and E-Mail - send copy to myself.
5. repeat 1-5.

It's not ideal if I want to get people to use Delta Chat and then it takes me 15 minutes to set it up. That doesn't make a good first impression.

[link2xt]

Recommended way currently is to setup one device, then take a backup and transfer it to other devices. This issue is about automating the process of backup transfer, currently you have to do it manually.

[dignifiedquire]

reopening, as I am working on this actively

[r10s]

ftr, this is the corresponding pr: #3489

[xeruf]

I just started using DeltaChat, and both me and a friend who tried it with me simply downloaded DeltaChat on multiple devices and logged in using our E-Mail-Account on each.
So we ended up with "This message cannot be decrypted" on all but the most recently setup device and were confused for a while.
Now I tried "Autocrypt key transfer" but it is loading forever on desktop after I entered all the digits.

There are some things tripping me off about this in general:
I would have expected ALL data to be available from the IMAP server, so I do not need to have separate backups and the app can restore full state from just the server, like in Matrix (Element) with the recovery code.
I don't know how the E2EE works in Delta, but Messages could be saved PGP-encrypted on the server, even enabling full interoperability with secure mail clients.
One should check how Protonmail does it, but it seems to save the GPG keys on the server as well, symmetrically encrypted with the email account password. Thus the key can be unlocked upon login by the client and all messages decrypted.

At least it should somehow be able to check on the server whether another DeltaChat client is active on that address and prevent clobbering of encryption keys.

An alternative I am also wondering about would be the direction of the Signal protocol, where devices each have different, individually revokable keys and are independently usable but also independently encrypted.

[dumblob]

At least it should somehow be able to check on the server whether another DeltaChat client is active on that address and prevent clobbering of encryption keys.

Yep, this is IMHO the first necessary step. We have to avoid any harm (i.e. "lost/unreadable" messages). Then we can focus on how to make onboarding smoother.

Btw. what happens if one DC client device gets compromised and the user suddenly wants to use new keys (and revoke old ones if possible) on all other non-compromised DC clients (previously sharing the same keys with the now compromised DC client) while retaining the same email address and provider? Is change of password to the email account enough? How about if the password was not changed (for whatever reason)?

[adbenitez]

isn't this old issue about the new "add second device" feature that got added? I think this can be closed as completed

cc @link2xt @hpk42

[link2xt]

Closed by #4007.

[xeruf]

Very nice!
What about that issue of clobbering encryption keys?

[r10s]

What about that issue of clobbering encryption keys?

the issue of mixed encryption keys is mitigated vastly by the new "Add Second Device" options as the keys are transferred as well and the "Add As Second Device" button is very much in ones face on the welcome screen. future will tell if ppl still try to log in on two devices instead, however, first feedbacks are very promising. surely things can be iterated over and improved further, no doubt.