Re: [Taler] Synchronization and backup

[Jeff Burdges]

On Fri, 2018-02-16 at 18:32 +0100, Christian Grothoff wrote:
> Finally, yes, I agree with you that due to the risks and usability
> issues (privacy, balance change, need for authentication/key
> exchange),
> sync may not be a feature for everybody or all devices.  But there are
> users that will be able and willing to navigate this.

In that case, we cannot depend upon syncing to replace alternative
features like collaborative spending, which we can push for all users.

I believe the withdrawal syncing I proposed sounds completely safe.  All
it does is reveal that reserves are linked, but reserves have real names
attached already.  We could even model it in our security games if
desired.  :)


We could do my withdrawal only backup with a wallet "pairing" process
which works as follows:

First, our users transport from wallet A to wallet B a pairing start
message containing: A's 256 bit reserve public key A_r, a single-use 256
bit ephemeral public key A_0, and a single-use 256 bit initial axolotl
ratchet root key state r_0.  As this transfer goes only one way, even a
QR code suffices, but NFC might work too.  This gives scary warnings
against pairing with other people, explains that pairings should
sometimes permit only one direction, and ask if this pairing goes both
ways or only one way.

Second, wallet B automatically sends wallet A an initial hello message
via the exchange.  These hello messages are empty but they include the
hash of A's ephemeral public key, B's ephemeral public key B_0, B's
reserve public key B_r, maybe encrypted and MACed with H(r_0 ||
DH(B_0,A_0) || DH(B_0,A_r)), and an overall MAC tag t.  They initialize
the root key with 
 r_1 = H(r_0 || DH(A_0,B_0) || DH(A_r,B_0) || DH(A_0,B_r) ||
DH(A_r,B_r))
and compute the 
 t = poly1305(r_0, A_r || A_0 || B_r || B_0 || r).
A learns about and authenticates our ratchet works when it next checks
its reserve for money to withdraw.  It destroys r and send B back
another empty message advancing the ratchet to A_1, so now both A or B
can message one another. 

Now anytime A or B withdraw coins they encrypt all coin private keys and
blinding factor seeds to one another, and advance the ratchet whenever
possible.  Axolotl header encryption is usable now if desired.  Actually
A or B may skip sending these depending upon the pairing direction
permissions selected, not sure if users should ever gift coins through
this channel.

Also anytime A or B receive a message for withdrawn coins they
redownload the blind signed planchet, recompute the coin private key and
blinding factor, unblind the planchet, and save the coin marking it as
belonging to another wallet. 

Finally, if the users tells say wallet A to close out wallet B then
wallet A notifies wallet B that it was closed out, and refreshes any
coins from wallet B about which it knows.  This part is not fast, but we
could provide users a button to sacrifice wallet B's past anonymity to
do it fast.  We could likely survive with abandoning all change, but if
the wallet A noticed and coins with high value refreshes then it could
pursue them with our newly secured linking protocol, but also on a slow
time scale.  

There is a stolen insecure device variant that runs the above and then
refunds all known valid coins from all devices the stolen device has
permission for to non-stolen device's reserves and rewithdraws them
without the stolen paired device.


In this protocol, we safely use only the existing exchange servers and
database for communications, but never syncs any coin activity after
initial withdrawal.  In fact, we could communicate some spent coins
information speed up recovery, and make fast recovery less bad, by
attaching some fixed size data structure, like a bloom filter, to all
withdraw messages between wallets.  

There is nothing too wrong with users who do not care about anonymity
running this protocol casually just to move around balances, and doing
so need not destroy the closed out reserve, but doing so requires
clicking through some scary messages about deanonymizing themselves.
It's better for anonymity sets if users with money in their bank account
simply do normal withdraws.

It's clear this withdrawal only protocol is *vastly* simpler than
anything that manages live coin data more actively.  It's still requires
users make complex decisions like asses which devices can close out
which other devices though. 

I donno if there is even any reason to encrypt B_r in the ratchet
startup message, but maybe if A and B can communicate with the exchange
via .onion addresses then doing so lets them use the channel for gifting
coins, so maybe we want a fourth pairing direction in which neither
wallet can reclaim the other. 

Jeff

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