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

[Torsten Grote]

Hi Christian,

thanks for explaining further!

On 2020-05-26 16:52, Christian Grothoff wrote:
>> What is S_A? A signature made over everything stored separately?
> Yes. Needed by sync so we know this is an authorized update, as sync
> updates are destructive.

This made me thinking: Could a removed device still upload a malicious
update? It still knows A and the new X and Dx.

>> How is A exposed? It seems to appear only in a signature made with it.
> The private key is deterministically derived from M. The public key is
> used by sync as the identifier of the account.

OK, so A is only (fully) exposed to who knows M, but the sync service
only knows the public part of A.

> The adding device learns Dx via 'J'. As J is not encrypted with K, the
> joining device can append its own data there. So the adding device can
> learn Dx (and add x to X) by syncing after the joining device updated
> the backup (without having been able to actually read the backup
> contents yet).

Ah clever, so it only needs to scan M once.

However, the QR code would also need to include the service domain and
path. What happens if there's more than one sync service? Does the same
page show two codes or does one code include the domain and path of each
service potentially makes the code too big? Or do we need to show
different codes on each service page/screen?

>> 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?
> You would need to write down M and Dx for your single device x.

Right. That's a possibility, but require us to expose the private part
of Dx which would be good to avoid.

>> 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?
> Good idea, we could generate an initial root secret, "R", and then say
> M=H1(R) and D0 = H2(R).  Given "R", one can then compute the D0 device
> key for the backup, and the master key. And R could be just 256 bits.

Sounds good!

> However, we then must not store R, and thus really could only show this
> once at the beginning, and not later again.

I personally consider this fine.

> If the user looses R, we
> could of course have an expensive process to migrate to a new M, but
> that would change A and the user would have to re-pay for sync.

Yeah that wouldn't be nice, but then the user shouldn't have lost R in
the first place ;)

> Or, we first show "R", and if the user looses it, we remove D0 from X
> and show a 512-bit secret with M and a fresh D9.

This could be a recovery strategy. Look, you lost your secret, now you
need to write down twice as much.

Btw. any thoughts about using mnemonic codes like BIP39 to make writing
down and entering secrets easier, without having to copy the secret
around and expose it to a printer?

We would probably need some identifiers or device type flags to make it
easier for users to see the current set of devices.

> Why should syncing be slow? Unless the wallet state is huge (bad, we
> should try to avoid that -- for example by expanding RMS's proposal for
> forgettable contract state to include product preview images!)

Yeah huge backup size due to accumulating product images is one concern.

> I would
> hope that neither bandwidth nor crypto nor CRDT-based merging makes this
> take more than a few hundred milliseconds.

No that part is fast, but according to the docs, in the worst case it
takes 2h5min for a device to upload its state and another 2h5min for
another one to get it.

>> 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. 
> Right, they see the updated X, which should be enough to be "informed".

The Sync-Signature mechanism also ensures that no device can upload a
new state without an added device, because it needs to have seen and
incorporated the latest version before uploading first.

Kind Regards,
Torsten