Re: [Taler] Technical questions for backup/sync (was: UI considerations for backup & sync)

[Torsten Grote]

On 2020-05-27 12:17, Christian Grothoff wrote:
>> This made me thinking: Could a removed device still upload a
>> malicious update? It still knows A and the new X and Dx.
> Yes. That could only be fixed by changing the account key, and thus 
> paying for a fresh sync account. I don't think this can be fixed by
> any other means.

Could there be some sort of nonce included in S that the next update
needs to include in E_M() to prove that it could decrypt E_K?

When a device is removed from X, a new nonce is added to S which the
removed device can't read anymore, so if it would attempt to upload a
new state, it would be rejected because the nonce is wrong.

However, the problem here seems to be that devices missing some updates
(e.g. because they were offline) would not have the latest nonce thus
rejecting all future state updates cutting themselves off.

Only changing the nonce (which wouldn't be a nonce anymore then) when
removing a device wouldn't solve the issue as there could be a device
offline while removing two devices.

Or is there maybe a way to derive a signing key from K and use that to
sign the entire blob?

Just brainstorming here in the hope somebody has an idea to fix this
unfortunate issue.

>> However, the QR code would also need to include the service domain
>> and path. What happens if there's more than one sync service? Does
>> the same page show two codes or does one code include the domain
>> and path of each service potentially makes the code too big? Or do
>> we need to show different codes on each service page/screen?
> Yes, in addition to the key material we need to include the URL 
> (taler://sync/$HOSTNAME/$KEYMATERAL). But unless 
> you.pick.a.freakishly.bad.domain.name.com, this should still be OK
> and the $KEYMATERAIL will be the biggest part.

Yep, however I am still thinking about the UI here. You said we could
just show one master secret in a single place to add new devices even if
we have multiple sync services and I wonder how that would work.

So I basically see these options:
* include all sync services in the single QR code and add new devices to
  all of them
* show several different QR codes on the single page
* show a different page with a different code for each service

Or would they just be added to one sync service and then learn about the
others automatically via the first?

>> Btw. any thoughts about using mnemonic codes like BIP39 to make
>> writing down and entering secrets easier, without having to copy
>> the secret around and expose it to a printer?
> It's a valid option to offer/support, but I would want to offer the
> user the choice of showing/scanning/printing the QR code as well.

Three different choices could be confusing for users, not understanding
if they need all three or just one or two out of three. But I am no UX
expert, so we could try with three: QR, URI and mnemonic code.

>> No that part is fast, but according to the docs, in the worst case
>> it takes 2h5min for a device to upload its state and another 2h5min
>> for another one to get it.
> Huh? How do you arrive at those numbers? Which "docs" are you talking
> about?

I am talking about
https://docs.taler.net/core/api-sync.html#synchronization-frequency
where it says:
> the client should attempt to synchronize at a randomized time
> interval between 30 and 300 seconds of being started, unless it
> already synchronized less than two hours ago already

Kind Regards,
Torsten