Re: [Taler] Synchronization and backup

[Christian Grothoff]

Florian,

I think we're not that far apart here.  Jeff and I agreed that to avoid
double-spending, it would be good to 'tag' coins by the device-ID of the
device that withdrew the coins.  Then, if another device is sync'ed (or
the backup is restored to a different device), we know about the danger
of these coins being used at the same time at another device.

At this point, we have three options:
1) warn the user, ask if this is an 'accidental' sync;
2) allow the user to manually re-tag coins to the new device,
effectively shifting the available balance between devices (the sync
would then communicate the change of device ID of those coins to the
other device)
3) automatically do (2), maybe trying to balance the coins between the
different devices (so each device owns 1/n of the overall balance). When
a device spends coins, it first uses the coins it owns, and then starts
to re-tag ("steal") coins from the other devices (effectively
rebalancing the remaining balance).  That _minimizes_ the chance of
accidental double-spending without the user being involved at all (!).

Now, (1) seems unproblematic from a usability point of view (simply
telling the user that this is a new device in the sync group and
checking that he _intends_ this is one Y/N question upon first sync, and
I can see how it may help prevent problems. Naturally, I don't quite
know how severe/frequent those problems are, but for now a Y/N question
is not something I'd say is a bad feature without more data. And, it's
easy to remove if we find out it is a real problem.

(2) is clearly a usability issue, complex UX, difficult concepts. Here
your critique of Jeff applies, but I could imagine this being a valid
thing to implement for a Wallet 1.x for power/Tor users.

(3) if done right has no implications at all for the user experience,
it's 100% behind the scenes. It may not satisfy Jeff as there are no
guarantees (only reduced probabilities depending on transaction amounts
in relation to balance carried), but as it reduces the chances of /pay
failures and higher latency transactions due to re-tried /pay
operations, it's mostly an implementation-effort issue. So you could
argue that 0.9 is too ambitious and we should leave it for 1.x, but I am
not sure it is that much work.

My 2 cents

Christian


> 
> I'm confused about the context for this key material, please elaborate.
> 
> I'm even more confused why you expect users would want to explicitly
> maintain "ownership" about which wallet owns which coin.  I'm talking
> about the bug report now, not just what's in the email I'm responding to.
> 
>> All coins created by withdrawal or refresh should be marked as being owned 
>> by the current wallet. All normal coin operations like displaying the 
>> balance, spending, or refreshing should be restricted to coins owned by the 
>> current wallet. 
> 
> No, this is not synchronization anymore.  It's a shared, connected
> backup wallet at best.
> 
>> In future, we shall add features to give coins to, or take coins from, other 
>> wallets by changing this field, and pushing those changes to a backup/sync 
>> server
> No, this is a usability nightmare.
> 
> If we really introduce this concept of coin ownership (which in my
> understanding is only there to avoid accidentally double spending), then
> it needs to be completely transparent.  Rather newly withdrawn coins'
> ownership should be distributed according to how we expect them to be
> used, and transferring ownership between devices should be completely
> transparent, automatic and immediate (at least by default).
> 
> Your "threat" of another user stealing your coins while you're in the
> check-out line of a store is very simple to avoid:  Disable sync.
> 
> Let's not remove useful features and replace them with something that
> only a small fraction of even the expert users would want to cope with.
> 
> Again, just turn off the sync feature.
> 
> This is a prime example a fallacy that seems to be prevalent in parts of
> the infosec community: restricting what users can do will result in
> better security for them.  It won't, they'll get annoyed and simply
> install the "Easy Taler Wallet" app written by somebody else.  We won't
> control this app, it'll have ads, tracking and will be insecure.  But it
> will be more usable than our wallet, so that's what everybody will
> install (well, if anybody will use it at all).
> 
> Is there any concern you have that's *not* solved by just turning off
> sync, Jeff?  Your collaborating spending is just another feature, that
> IMHO has less priority than (single user) backup and sync.
> 
> - Florian
> 
> On 02/21/2018 05:31 PM, Jeff Burdges wrote:
>>
>> I briefly spoke with Christian more about sync usability issues.  At his
>> request, I filled an initial issue for adding an owner field to coin
>> database, which should address my concerns:
>>
>> https://gnunet.org/bugs/view.php?id=5285
>>
>>
>> As for connecting wallets using QR codes, we want to pack the following
>> elements into 256 bits, plus possibly additional messages.
>> - backup server used
>> - wallet backup account
>> - ephemeral curve25519 point
>> - symmetric key that provides post-quantum security
>>
>> I'll ignore identifying the backup server for now, so our QR code might
>> consist of a 64 or even 32 bit hash identifying the account, plus the
>> remaining two fields.
>>
>> In theory, the symmetric key should be 256 bits all by itself, for 128
>> bits post-quantum security for anonymity functions, but we can shrink
>> this because early quantum computers will be too slow for Grover's
>> algorithm anyways.  We can ignore the symmetric key entirely thought
>> *if* the curve25519 point is ephemeral and not shared outside the QR
>> code, as hashing in the point itself gives us this symmetric key for
>> free.
>>
>> If we do not send the curve25519 point in the QR code, which actually is
>> 256 bits all by itself, then an adversary who observes the QR code can
>> break into the connection.  We've four choices here:
>>
>> (0) Ask the QR code to handle 288 or 320 bits.
>>
>> (1) Do two simultaneous QR codes.
>>
>> (2) Send a long-term curve25519 point that doubles as wallet backup
>> account identifiers, but drop any pretense to post-quantum anonymity for
>> people who utilize backup functionality.
>>
>> (3) Use a smaller curve than curve25519, like brainpoolP192r1
>> (slowish??) or NIST's 192 bit curve (disreputable).  We could claim
>> almost 192 bits of classical security here from keeping the curve point
>> ephemeral and hidden, but only 96 bits against an attack who either sees
>> the QR code or possess a quantum computer.
>>
>> (4) Send the curve25519 point in another message sent over the network.
>> I do love Axolotl but Christian felt this added too much complexity.
>>
>> A priori, I think doing two simultaneous QR codes sounds best, as we
>> cannot actually ignore the backup server URL, but this may encounter
>> issues too: 
>> https://stackoverflow.com/questions/15107610/how-to-read-multiple-qr-codes-from-one-image-using-zxing-library
>>
>>
>> Best,
>> Jeff
>>
>

signature.asc
Description: OpenPGP digital signature