[Taler] Synchronization and backup

[Christian Grothoff]

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