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

[Torsten Grote]

On 2020-05-25 09:46, Florian Dold wrote:
> It doesn't really make sense to have multiple "Anastasis services"

Maybe you want to be really sure to not lose your backup and later don't
trust the chosen Anastasis service anymore?

> or multiple core secrets that we separately back up with Anastasis.

My suggestion wasn't to have multiple core secrets, but to not have
static core secrets at all. Rather use fresh random keys each time you
encrypt a backup and make these keys only available to a known set of
public keys that might change over time. The secret used for Anastasis
(one or multiple services doesn't matter) would be the private key of
the keypair specifically generated for Anastasis by the provisioning
wallet which ideally purges this private key after passing to Anastasis
providers.

> Anastasis already *inherently* has the notion of multiple Anastasis 
> providers which all have different shares of the core secret. 
> Managing multiple secrets in the wallet with multiple different 
> "Anastasis provider sets" is just a plain nightmare, and we should 
> never implement this.

Ah ok, so the wallet manages various Anastasis providers and how to
split the secret between them. My suggestion was (as with devices) to
use a dedicated key (pair) for Anastasis instead of disclosing a static
master secret that is also used in other places.

> There should be one core secret per wallet, but this secret might 
> change over time when adding/removing more backup providers.

Would the secret change, because it includes the backup domains/paths of
the new providers or would you generate fresh keys?

> Changing Anastasis policies (i.e. adding/removing providers) shall
> be completely orthogonal to managing sync servers.

Agreed. However, it might be a nice feature to be able to generate a
completely fresh Anastasis secret (key pair) when removing providers.

> (Maybe you're responding without the context of my response to 
> Christian's email.  The idea of one immutable master secret per 
> wallet leads to way more complications and problems than it solves.)

I had understood your exchange as a discussion between a single static
master secret vs. a single static master secret per backup service. My
notion is about static secrets you keep passing around over the wire and
the UI being a problematic approach.

I don't claim that my proposal does match all your requirements or is
better in every aspect. It is only meant as a quick naive example of how
using a different encryption scheme could avoid problems with the
current single static master secret approach.

The UI and core API for backup depend on the encryption scheme, so I
think it is worth discussing the latter before moving forward with the
former.

Kind Regards,
Torsten