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

[Torsten Grote]

Hi all,

I am trying to split out the technical discussion of backup and sync
from the UI discussion.

On 2020-04-21 15:25, Christian Grothoff wrote:
> We basically do 'sync' by restoring from backup. So indeed it is both
> the same mechanism.

That is interesting.

Normally, syncing data and backing it up are two different use-cases and
processes:

Backup is for storing a copy of data so you can restore it it when
needed, so you never lose that data.
Syncing is for having the same data and state available in different
devices.

Doing both separately is already hard, but doing both within the same
process seems even harder. I am curious how you solved that.

For example, when doing a payment on device A, a user expects that this
payment will show up on the synchronized device B instantaneous or at
least very soon. Similarly, when there's only a small balance available
and it is spend on device A, the user should not be able to spend it
again on device B, because device B picks up the reduction in balance
before the user even attempts the payment and warns about the
insufficient balance.

I imagine that it is rather difficult to back up the complete data and
state on device A and upload it as a single (potentially quite big)
archive in a timely fashion and then download this on device B and
reconcile the potentially changed state with what is found in the backup
of device A. Is Taler using CRDTs for the latter?

>> To sync their wallet with another device, the user is shown a secret (we
>> should probably *not* expose the private key here)
> I doubt we can avoid that. Besides, whatever we do expose will basically
> allow anyone who gets hold of it access to the full wallet (including
> all the private keys in it). That's after all the point.

Wouldn't it be safer if each device had its own backup key? The docs
don't say how additional devices are added or removed, only that backups
are uploaded to the account key, encrypted with the private key. So if
all devices share the same private key, how can you reasonably revoke a
(potentially compromised) device?

>> Further feature that were desired in the documentation is a way to
>> export the backup config (key + url) and to disable sync and backup
>> entirely. I am not sure it is a good idea to expose the key material in
>> a second time as it becomes available to physical attackers this way and
>> can't be stored in a secure element (available on most modern mobile
>> devices).
> I doubt the secure element solution will work anyway, because you're not
> yet having Anastasis in your scopes (which is fine, that's after all the
> _next_ step after Sync/Backup).

Right. I haven't looked at that yet, but I would have expected the
Anastasis core secret to be different from the backup private key.

Is the idea here that Anastasis requires backup and that it recovers
your private backup key, so you can restore from backup, even if the key
is lost?

Kind Regards,
Torsten