Re: [Taler] Synchronization and backup

[Jeff Burdges]

There are three senses in which the scheme I proposed is "via the
exchange": 
- Any server based sync is "via the exchange" in threat model terms.  
- It avoids altering the threat model by only syncing withdrawal related
data, plus a small fixed size message identifying spent coins.
- It can exploit data the exchange stores anyways, but this is minor.

On Sat, 2018-02-17 at 06:12 +0100, Christian Grothoff wrote:
> 1) Your proposal ignores other key benefits of sync, like that when I
> bought a news article with wallet A, I would not have to buy it again
> with wallet B, wallet B would just re-play the purchase of wallet A.
> That would not seem to be possible with your solution, or at least is
> not covered in your write-up.  Hence, your reserve/withdrawal-sync is
> more limited than the 'full sync' (or backup) that is planned for 0.9.

Interesting, we cannot sync contracts without altering the threat model
because they're too big, but..

We could sync contracts within Tor's threat model, just not quickly
unless you add a "sync now" button with scary warnings about privacy. 

I therefore claim we still not heard a single concrete benefit to fast
automatic sync.

> 2) Exchanging 3x 256 bits of data (any type of keys) via QR codes is
> impractical. You can barely get 256 bit QR codes for GNS to scan in
> practice.  

Ugh.  At minimum, you must identify a reserve and communicate an
ephemeral secret.  You could identify the reserve with a 128 bit hash
and fetch the actual, and also the ephemeral curve point might as well
double as the initial root key r_0 too, but that's 1.5 x your GNS keys.

> So how to communicate that kind of state would require some
> more thought -- or again some third-party service (in the absence of an
> NFC channel).  

You could save a file to disk and ask the user to back it up or give it
to another wallet. 


We've another concern here :  

It's common for devices to be out of their user's control for short
periods.  If an adversary establishes sync illicitly then they can steal
small amounts from our user's wallet over an extended period, which
violates our assertion that users should think about Taler like cash.  

It's less bad if (a) the adversary has less up to date information about
valid coins, ala my proposals, and (b) the adversary cannot spend any
coins without triggering notifications in the user's wallet, which again
sounds more like my proposals than anything else.  

Yet, all proposals remain vulnerable to sleeper attack in which the
adversary waits until they see a large increase in wallet value and then
steal the whole wallet.  Avoiding this even requires you password
protect the reserve private key, which sounds unworkable.  Ugh! 

Jeff

signature.asc
Description: This is a digitally signed message part