[Taler] A newbie's questions about TALER

[Bellebaum, Thomas]

Hello everyone,

I have recently read a bit about TALER and some questions came up regarding its 
design, which I hope to be able to get answers to on this mailing list. If you 
have any helpful remarks, thank you in advance :)

I frame the below as criticism despite being in favor of privacy-aware 
solutions like GNU TALER. So please take it light-heartedly, as I am aware that 
I have probably overlooked obvious things left and right :)

### Why blind signatures?

Coins in TALER seem to have a value known ultimately only to an exchange. While 
a signing public key can be used to get information about the initial 
denomination, the measures against double spending and possibility of partial 
deposits during payments imply that it is impossible to determine the actual 
value of a coin without asking the exchange.

But then why is TALER using blind signatures instead of "blind MACs" and alike?
For instance, oblivious pseudorandom functions (OPRFs, [RFC 
9497](https://www.rfc-editor.org/rfc/rfc9497)) could be used, which can be much 
more efficient than actual signatures. If you need to verify that a coin was 
correctly issued (during the withdrawal protocol), you can also use verifiable 
OPRFs (VOPRFs). Note that the one in the RFC can be efficiently batched to 
require a single proof (one scalar + one hash) for however many coins you would 
like to withdraw at once. Or you can just trust the exchange to not betray you, 
which is also an option in practice.

### Why the Withdrawal Loophole?

I have only had a look at the Thesis, so please excuse me if this is a solved 
issue.

A simple way to get rid of the withdrawal loophole is to have a special 
non-anonymous coin consisting of an identity key associated with each 
participant in the system. This coin always has a value corresponding to the 
credit of the participant at the exchange. While paying with this coin is a 
form of non-anonymous payment (which might be required for larger sums of money 
or special kinds of payments like donations to political parties), if instead 
of "withdrawing" from your account you instead "refresh" the coin into 
anonymous coins, you immediately inherit the security guarantees of the latter 
protocol, thereby closing the withdrawal loophole.

That said, there is a reason why you might not want to do this, and it to some 
extend questions the entire refresh protocol:

### What is the actual benefit of the linkability "threat"?

As I understand it, TALER "guarantees" (via a zero-knowledge argument of barely 
any soundness, yes there are arguments that misuse would not be profitable if 
done at scale, but desparate people also play russian roulette) that misusing 
the refresh protocol to transfer money without paying taxes etc. is no better 
of an option than to just share the coin secret keys, by ensuring that the 
owner of the old coin can re-aquire the new coins with the help of the 
exchange. This is called the "link protocol" and introducing it also introduces 
a big weakness into the system:

Instead of perfect unlinkability between coins other than seeing which coins 
have been used together in a transaction, TALER only provides "computational" 
unlinkability. That is, it relies on the security and intractability of the Key 
Exchange used in the randomness generation during the refresh protocol. While 
this sounds harmless at first, it implies that in due time an exchange using 
newly discovered algorithms or a quantum computer can start to calculate 
private keys for all coins it has seen and then use the link protocol to 
efficiently de-anonymize all participants in the system after the fact. Are 
there any concrete privacy guarantees TALER can make regarding a three-letter 
agency working together with an exchange over time (today, in 10 years, in 1 
generation)? Concretely, which information and to what extend do you expect 
information to be revealed?

For the (potential) harm of this protocol, it (of course) is of illusionary 
benefit if no one ever runs the protocol. So has it been automated? To what 
extend is it run automatically or is otherwise run regularly?

For comparison assume that the link protocol did not exist but instead everyone 
would freshly blind their refreshed secret keys. As a simple measure against 
tax evasions, assume that each customer would be presented with a UI which only 
shows a transaction as completed once it received a signature on the customer 
and merchant's agreement by the exchange. Thus unless the merchant and customer 
cooperate, the merchant cannot evade taxes without the customer noticing, and 
if they do cooperate, an efficient protocol for the customer to prove the tax 
evasion attempt by the merchant would certainly be more devastating to the 
merchant than the "threat" of the customer taking back the money for this one 
transaction.

### Age restrictions...

This may be a cultural difference and is less technical critique, but having 
grown up in Germany there are a few reasons I have to not support this protocol:

- Effectiveness:
  - If my child earns a few bucks doing work in my neighbours garden (or any 
other way) I do not get to set age restrictions on those coins unless I control 
their entire wallet.
  - If I ever allow my child to buy something not for their age, I have to give 
them unrestricted coins which they may then use for anything they like.
- Potential for misuse:
  - As a real-world scenario, refugees in Germany currently are being equipped 
with special bank cards restricting their use of their money. Age restriction 
technology like this can trivially be adapted to make this happen, at probably 
much lower costs. The proposed protocol also enforces refugees to lay open 
their status as a refugee, opening them up to physical threats.
- Alternatives:
  - I would actually prefer a digital solution (e.g. based on wallets) which 
mimics the following scenario (e.g. using zero knowledge proofs): If my child 
wants to buy a DVD not suitable for their age (let's be old-fashioned for a 
moment ^^), I can write a statement saying that I am their parent and 
explicitly allow this transaction.
  - Note that the above is an even better fit to the principle of subsidiary, 
since even with age restrictions it is the state setting age restrictions on 
individual products, not me. One degree of freedom hardly fits all use cases.

To some extend one could also argue that technical restrictions on a child are 
less effective than a good relationship to their parents. Especially since the 
protocol has to keep one thing in mind: A child has, as it gets older, an 
increasing desire (and quite literally right) to keep some privacy when it 
comes to their parents.

If these points are not oversights, then what is the exact relation of a 
"guardian" and "child" for which these protocols were designed? (E.g. is it 
assumed that parents control their children's wallets/phones?)

-- 

```
M.Sc. Thomas Bellebaum
Applied Privacy Technologies
Fraunhofer Institute for Applied and Integrated Security AISEC

Lichtenbergstraße 11, 85748 Garching near Munich (Germany)
Tel. +49 89 32299 86 1039
thomas.bellebaum@aisec.fraunhofer.de
https://www.aisec.fraunhofer.de

```

smime.p7s
Description: S/MIME cryptographic signature