Re: [Taler] Technical questions for backup/sync (was: UI considerations for backup & sync)

[Torsten Grote]

On 2020-05-25 17:28, Christian Grothoff wrote:
> I think we can have both: a single master key and the crypto-visibility:

Thanks! Now things get interesting :)

I'll add some questions below to be sure I understand things. Maybe it
also helps others to understand your proposal better.

> Let the master key be M (symmetric!), and each device "x \in X" has a
> device key Dx.  M is shared across all devices. M is used to derive an
> account key "A := f(M)" for the sync process (asymmetric, for
> signatures).

Is f() deterministic, so each device arrives at the same A?

> Then store at the sync service:
> 
>   S_A(  E_M(X, { Ex, DH(Ex,Dx,K) }_{x\inX} || E_K(S) (|| J)+) )

Not sure I fully understand this syntax. Looks like a mix of latex,
concatenation and regular expressions.

> (Note that S_A is required by the Sync protocol, to detect an authorized
> party making a change.)

What is S_A? A signature made over everything stored separately?

The next layer seems to be wrapped in E_M which is encryption with the
symmetric M? In there is S encrypted with K that you get out of DH(), right?

> With this, we know:
> - only devices in the device group (incl. Anastasis) can do the
>   DH to find the current K
> - the Sync service still learns nothing, not even the set of
>   devices, only 'A' is exposed as it must be

How is A exposed? It seems to appear only in a signature made with it.

Ah it is implicitly used to locate the backup blob at the service
provider, right?

> - to add a device via QR code, we now need an additional
>   interaction: basically we teach the new device 'M' first
>   (via QR code), and then we need another interaction where
>   an existing device adds Dx to the device list.

Dx is the new device's key and without that being added into the DH()
computation, the new device can't use its private key to decrypt K, right?

So when *removing* a device from the group, its Dx is dropped and thus
it can't decrypt K and E_K anymore even though having knowledge of M, A
and where the backups get stored. So it gets effectively included and
can only monitor the size of the backup changing over time.

The process of adding a new device with this scheme still isn't
completely clear to me. It seems the new device needs to learn M and the
domain+path of the backup service(s?) it should use.
Then the adding device needs to learn X and Dx of the new device. So
each device needs to scan one code, right?

Also, how does this scheme work if I just want to use it with a single
device as a backup service without Anastasis? Looks like this wouldn't
be possible anymore, because there's nobody left to upload a new blog
with my new device key included, right?

Could there be another "fake" device for offline backups? It seems the
to-be stored secret would need M and all Dx, so rather a lot to scribble
it down on paper. Even worse to stay useful, the offline backup secret
would change with each device that gets added, right?

> Devices that are already in the group see the 'J', prompt the user to
> approve the new device. If the user rejects, they remove J (kicking the
> new device out). If the user approves, they add Dn to the X set, upload
> the result and now the new device can download the state S for the first
> time.

I am a bit worried about the UX of that process. But I guess as syncing
state is very slow anyway it wouldn't matter anymore if also it takes
quite some time for the initial state to show up.

Another concern I had was about devices disagreeing about the current
set of devices X and Dx, but I guess since X is included in the blob
that everybody can decrypt, there can be a mechanism for them to arrive
at a consensus, even if they've missed J for example. So in that case
the worst that can happen is that some devices can't decrypt uploads by
some other devices temporarily, but due to CRDTs would converge on a
single state eventually. Correct?

Kind Regards,
Torsten