taler
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Florian Dold
Subject: Re: [Taler] Technical questions for backup/sync (was: UI considerations for backup & sync)
Date: Sat, 23 May 2020 01:57:56 +0530
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0

On 5/23/20 12:28 AM, Christian Grothoff wrote:
> I think each service should have its own secret, but we can and should
> be able to simply derive all of them from some immuatable master secret.

Is there a good reason to have this immutable master secret, as opposed
to fresh secrets for every sync service?

My understanding was that the sync blob will contain the secrets of all
other sync services used.

The Anastasis core secret can then be the sorted list of (url, sync priv
key) tuples.

> However, there is a possibly HUGE issue here, in that I may start with
> two independent devices, two wallets, and thus two independent master
> secrets. I may even setup Anastasis for _both_. Now what happens if I
> then start to sync those devices? Now I have two master secrets. I think
> in this case we need to pick one of them (i.e. the numerically smaller
> one), update the derived sync secrets, update all backups on the sync
> servers, update all Anastasis policy documents, and somehow (hard step!)
> inform/teach the user which of the two master secrets they need to
> preserve. Messy.

We would not have this problem without master secrets.

When "merging" two wallets that don't have a master secret, we might end
up in a situation where a wallet has multiple sync accounts at the same
sync server, because the backup blobs will be merged and converge.

But that's much easier to resolve than having these "immutable master
secrets" around that are in some situations do not really fit "master"
or "immutable" ;-)

The "immutable master secret" also makes migrating to a new set of sync
accounts impossible or at least much harder!  We might want this in case
one synced device is suspected to be lost/compromised.

Am I missing some reason for why you want this master secret?

- Florian



reply via email to

[Prev in Thread] Current Thread [Next in Thread]