Re: [Taler] Synchronization and backup

[Florian Dold]

Jeff,

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
>