Re: [Taler] Synchronization and backup

[Florian Dold]

While of course more anonymity for the user is always desirable, nothing
is gained if it the system is not usable enough in the first place.  So
I'm gonna argue from a practical perspective now.

By the way, my discussion with Jeff (including his suggestion about some
bigger master secret that everything is generated from) was triggered by
my remark that not all browsers have "flush to disk" support for their
database operations, since they are generally optimized for performance,
and the local database is typically just a cache of some online service.
 Firefox has a "readwriteflush" mode for transactions, but this is a
non-standard extension to the IndexedDB standard ...

But back to the discussion, in general I think the prioritization *must*
be as follows:
1. Make it as seamless and "non-weird" for users as possible, by default
2. Have an easy way to get better anonymity, typically by trading off
some convenience (even if it's just one more one-time setup step).

Of course these two points can be a bit at odds, since the majority
sticking to (1) might disadvantage people wanting (2), just like if only
people who want to do something illegal were using Tor.

For normal operation of the Taler wallet, syncing pretty much instantly
is IMHO unavoidable for usability.  At least browsers are starting to
have APIs [1] that allow us to judge when it's appropriate to send cover
traffic.  If we send cover traffic just like that, people who are on
metered connections will be very unhappy (especially on mobile devices
dynamically switching between metered/non-metered that's very common).

I wonder if we can have cover traffic / cover read+write operations to
the backup without receiving/transmitting the whole wallet, and without
going full SMC.  Could we have some scheme where we append smaller
encrypted blocks and eventually, less frequently compact them?

I'd add that it is probably more acceptable to (optionally?) add a tiny
random delay to spending than it is to have delayed backups or
operations that failed to back up / sync completely.  When I spend with
a merchant, I'd expect that we first mark the coins as spent in the
backup, wait a bit (randomly!) and then do the spend with the merchant.
This is probably not feasible though unless we have the ability to
append smaller updates instead of pushing the whole wallet, like I
described in the paragraph before.

Now for (2) I would not go so far as to have people run their own backup
service.  They could use a normal backup service, but access it via a
state-less active relay that generates cover-traffic for them.  This
hides from the backup service when they're online.  Such a service would
be easier to manage yourself (who'd want to back up their backups?).

Of course your options (n), (p) and (s) would be great to have, but as
you said (n) and (p) are not always applicable.

- Florian

[1] https://developer.mozilla.org/en-US/docs/Web/API/Network_Information_API


On 02/16/2018 01:49 AM, Christian Grothoff wrote:
> Jeff wrote (in PM, but he won't mind me sharing, as it really belongs here):
> 
>> It's too risky to keep the same coin in two different active wallets
>> anyways (...).
>>
>> It's not great for a restored wallet to quickly run through all it's
>> coins trying to refresh or link them because it breaks unlinkability.
>> I'd think wallets should save to their backup more aggressively if it
>> needs to save to a backup at all, although that's vulnerable to traffic
>> analysis too.
> 
> I've actually been thinking (and worrying) about this a bit myself, now
> that I've drafted a first spec for the Taler wallet 'sync/backup'
> protocol (see api.git, api-sync.rst file for details).
> 
> 
> Basically, there are two points to this:
> 
> 1) Backup/sync frequency leaks information about the user; basically,
> doing a 'full' sync (instead of just seeing that the delta is zero)
> shows even over TLS that the user did a purchase (or other
> Taler-activity, like withdraw).  If we sychronize often, that's quite a
> signal. If we synchronize rarely, we run into (2).  If we synchronize at
> a fixed frequency, we do lots of "wasteful" ops that leak that the user
> is online. If we synchronize based on triggers (purchase, about to
> purchase, etc.), we leak even more information.  Note that this applies
> even if we do it all over Tor, as the backup/sync server does see the
> event and it is linked to the respective public key (which the server
> must know so it can check the signature and attribute the activity to
> the same 'account' / rowid in the database).
> 
> 2) Echoing Jeff's other point, if we share the same coins across
> devices, either device may attempt to spend it, and if we accidentally
> spend the same coin twice (via device A and device B) because we failed
> to synchronize, we disclose a link between the two purchase operations.
> We could try to add information to the DB saying something like "this
> device will use the coins in order X-Y-Z if it can, so a second device
> should use Z-Y-X (and mark that in the DB) and a third X-Z-Y (and again
> upload that into the sync'ed DB so everybody knows!).  That could
> _reduce_ the chance of two wallets picking the same coin more-or-less at
> the same time by accident (albeit not prevent it, we may be spending X,
> Y AND Z depending on the amount...).
> 
> 
> Possible approaches to this that I see:
> 
> c) Constant-frequency, constant-bandwidth backup/sync.  Basically, throw
> bandwidth at the problem, always uploading and downloading the full
> wallet DB, even if nothing changed, regardless of the user being
> 'active' with Taler.  If an acceptable frequency is low enough, and we
> can keep the wallet DB small, that might be viable, but feels a bit extreme.
> 
> i) Ignore the issue. Design and build for usability and performance
> today.  Naturally, without implementing anything, we can document the
> problem properly and tell users how to work around it. For example, that
> if they want the best privacy, they should either run their own personal
> (!) Tor hidden service for backup/sync, or just not use that feature. We
> can facilitate this solution a bit by providing nice, easy instructions
> for how to setup such a Tor hidden service. (Note that it has to be
> personal, as otherwise the provider can still do the correlation attacks.)
> 
> p) P2P sync. Once we have a working GNUnet and the Internet has been
> obsoleted, we could just directly sync between wallet devices, using a
> secure mix network communication channel. That'd be ideal, cutting out
> the middleman and the information leakage.  But, that's a bit far into
> the future.  In the meantime, STUN/TURN/ICE may _sometimes_ allow us to
> achieve something similar, but as they still require a third party to
> coordinate/rendezvous, I don't see this fundamentally solving the problem.
> 
> n) NFC sync. Again, same problem as (p), might not always be available
> as not all devices we may want to synchronize will be available for some
> type of NFC-communication.
> 
> s) Secure multi-party computation magic where the backup/sync server
> operates on encrypted wallet data (instead of merely storing encrypted
> wallet data).  If we don't have to always upload the full wallet, but
> can somehow more efficiently transmit deltas, then (c) becomes much more
> affordable.  However, without some significant crypto-advance I would
> expect any zero-knowledge operation on the server would just be crazy
> expensive computationally for client and server, and possibly still use
> quite a bit of bandwidth, so the gains vs. (c) would be offset by far
> from computational losses.  So this sounds more like a highly
> experimental long-term PhD-crypto-thesis proposal than something we
> could actually do in the near term (and maybe (p) is the more realistic
> plan for the long term...).
> 
> 
> Naturally, we can combine these. (i) is trivial, (p) is being worked on,
> and (n) could be implemented as an option once we have a wallet on
> mobiles; (c) could influence our general behavior for sync; however, I
> think we should for the first iteration avoid constant-traffic, and I
> don't see how constant-frequency buys us anything without constant-traffic.
> 
> 
> Any other opinions? Other options I'm missing?
> 
> 
> Happy hacking!
> 
> Christian
> 
> 
> 
>

signature.asc
Description: OpenPGP digital signature