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

[Christian Grothoff]

On 5/27/20 3:09 PM, Torsten Grote wrote:
> 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.

Yes. That could only be fixed by changing the account key, and thus
paying for a fresh sync account. I don't think this can be fixed by any
other means.

>>> 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.

Yes.

>> 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?

Yes, in addition to the key material we need to include the URL
(taler://sync/$HOSTNAME/$KEYMATERAL). But unless
you.pick.a.freakishly.bad.domain.name.com, this should still be OK and
the $KEYMATERAIL will be the biggest part.

>> 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.

... or pay extra and really have no problem with lost devices still
having access ...

> 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?

It's a valid option to offer/support, but I would want to offer the user
the choice of showing/scanning/printing the QR code as well.

>> 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.

Huh? How do you arrive at those numbers? Which "docs" are you talking about?

>>> 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.

That's more the Etags mechanism, but yes, the sync protocol does ensure
devices don't override state that they have not seen.

signature.asc
Description: OpenPGP digital signature