taler
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Taler] Synchronization and backup


From: Jeff Burdges
Subject: Re: [Taler] Synchronization and backup
Date: Wed, 21 Feb 2018 17:31:50 +0100

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

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]