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

[Florian Dold]

On 5/25/20 6:41 PM, Torsten Grote wrote:
> 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?

Yep, exactly!

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

That's a very good point.  I think we do need to explicitly define how
(and to what degree) we deal with synced wallets becoming "adversarial".

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

Ah.  I also initially has this idea that every wallet should have a
separate key pair that is then encrypted with the backup, but there are
some questions regarding what's possible there with Anastasis.  I'll
take my question to the Anastasis team and then clarify here further.

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

Sure, and what you suggested might even be similar to what we'll go with
in the end, I just wanted to clear up one Anastasis misconception, as
well as highlight problems with having one master secret common with all
wallets (Christian's initial 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.

Yes, I think we have to thoroughly discuss this first!

- Florian