Re: [Taler] A newbie's questions about TALER

[Christian Grothoff]

Hi Thomas,

Some answers inline...

On 3/18/24 16:40, Bellebaum, Thomas wrote:
> 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.

With signatures, you have two key advantages (maybe more, not sure):

1) You can delete the private key, and still verify the signatures. So 
we can keep the window of potential compromise smaller.

2) Other parties that do not hold the private key can verify the 
signature (universal verifiability). This in particular allows the 
merchant to already reject obviously invalid requests, and the auditor 
to check on the exchange operating correctly, and for an arbitrator to 
decide that the signature is valid without having to compel the exchange 
to disclose private key material (which it also could have 
(deliberately) lost!).

So yeah, we really don't trust the exchange ;-).

> ### 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:

Yes, that fix *is* actually already proposed and rejected in the thesis. 
The problem is that if this identity coin is ever compromised, an 
attacker will both get all of your remaining money AND be able to 
deanonymize all of your transactions. So it is simply way too risky to 
have such a thing exist. Just imagine police forcing you to disclose 
your identity coin. Very, very bad. So our choice was to pick strong 
privacy over a minor loop hole.

> ### 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?

Taler is not post-quantum safe, and yes, only has computational 
unlinkability between coins and their change. Addressing this is a "fun" 
challenge for TUE as part of the NGI PILOT ;-).

> 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?

It is implemented, but there is hardly a point in running it 'regularly' 
or 'automatically' as (usually) the wallet has the data already anyway.
However, it is also *useful* if you made a backup, then spent some 
money, and then lost your wallet -- as then you can use the link 
protocol to recover your change from the backup + link protocol. So we 
would indeed expect this to be used in production if after a backup a 
wallet detects that there is change it has forgotten about. That way, 
you can reduce the frequency of backups to primarily after withdrawals.

> 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.

Consumers frequently kind-of collaborate with tax evasion by merchants 
when paying at restaurants in cash without requesting or receiving 
receipts, so I'd think customer-merchant collaboration against taxation 
is a real threat. Similarly, customers do defraud merchants with 
payments given a chance (see Twint offline payments with insecure 
payment confirmations), so a customer taking back their payment would 
also be a real threat to a merchant. Plus, we really never want to 
provide security by UI-restrictions, UIs should be truly freely 
modifiable for all users.

> ### 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.

Not exactly true, albeit not fully implemented yet. Oec has a proposal 
for reserves inheriting KYC restrictions from parent reserves, and so 
the age restriction could be set by the parent on all P2P transfers to 
the child's 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

Again, you may limit the amount, you don't have to fully unrestrict all 
money in the wallet, if you do this during withdrawal. So if you just 
once want to send your kid to by you wine, just make sure the amount is 
only enough for wine *and* that you get a non-empty bottle ;-).

.
> - 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.

Right, and we had a discussion on this list about such abuse cases. Note 
that the fact that an age-restricted wallet is used for payments is NOT 
disclosed to the merchant, so unlike the refugee-card, the child-status 
would NOT be revealed to the merchant.

> - 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.

I think that is an orthogonal possibility that can theoretically always 
be added on top as an "override" mechanism. But, it'll be harder, 
because you'd have to prove that you're actually the parent. So now you 
need an eID for the entire population with parental relationships 
encoded in the PKI, and I hope I don't have to go into the risks of 
such a PKI even existing.

> 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.

That's always true, but not all children have good relationships with 
their parents, and the objective here is actually a different one: how 
to avoid age-verification in e-commerce to become the go-to reason for 
establishing a national/global eID PKI *while* addressing the use-case 
of age-verification in e-commerce.

> 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?)

Not necessarily, with the age-restricted withdrawal the children could 
even have their own bank account and then the age restriction would be 
based on the bank's KYC data, and the parent wouldn't even be in the 
picture. Which is actually not an unreasonable scenario for 16 year olds...

My 2 cents

Christian