Re: [Taler] Synchronization and backup

[Christian Grothoff]

Hi Jeff,

A few thoughts:

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.

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.  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).  Similarly, your notion of sending "via the exchange" is a
much more involved process than you likely imagine. Besides, if "via the
exchange" is OK, then why not use the backup/sync server I proposed?
This is really not the kind of feature to bloat the highly sensitive
exchange service code with.


Overall, I mainly disagree with your notion that this is "vastly
simpler", primarily though this not being vastly simpler to implement.
My best guess is the sync I envision for now should take Florian and me
1-2 PM, and yours looks like at least 12+ PM.  That still assumes we
find a good fix for (2) and that users don't care about (1), and that
user's are OK with backups working only between a user's devices (i.e.
no backups if you only have one device!).


As a result, I don't think this proposal is viable in the short term.
The benefits are too restricted/specific/narrow, and way too much work
to implement this right (there are hundreds of things I'd prioritize
over this), and too many open issues on all kinds of levels (from UX to
protocols). So not really something to think about before say Taler 3.0 ;-).


My 2 cents

Christian

On 02/16/2018 11:12 PM, Jeff Burdges wrote:
> 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: OpenPGP digital signature