Re: [Taler] Meaning of XORed hashes in the Exchange API

[Christian Grothoff]

On 9/19/23 13:39, Jonathan Krebs wrote:
> Hi again :)
>
> I do not understand the use of the fields denominations_sig and 
> denominations[i].hash in the /keys response:
>
> the wallet-core repo does not seem to use these at all, all denom 
> pubkeys are signed individually, and as the hashes are combined with 
> xor, this does not protect against tampering with the list. (once enough 
> denominations exist, they can be combined linearly to achieve arbitrary 
> hash values)
>
> Please give me a hint about intended use or history of those, or about 
> my misunderstanding :)

The objective of the signature over the XOR hash is to prevent 
truncation attacks where a man-in-the-middle attacker removes some 
denominations from the list. With this signature, entries cannot be
removed from the array without the client noticing.

The xor doesn't allow for linear combinations and/or arbitrary hash 
values, especially as each value still can only appear ones. The point 
of using XOR is that the denominations are a *set* and the order does 
not matter (and may indeed change due to the use of a hash map in 
exchange implementations). With XOR, the order does not matter, but each 
element must appear in the set and the XOR will change on deletion (we 
don't actually worry about addition, as each element is signed with the 
stronger offline master key).

Finally, wallet-core doesn't check quite a few things that it should 
eventually check. The deletion attack requires an attacker to break 
HTTPS/TLS *and* achieves very little, so I understand that Florian 
didn't prioritize implementing it...

Happy hacking!

Christian