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

[Jonathan Krebs]

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

Thank You for the fast reply!

The XORed hash-code has 256 bits, for a deletion attack we need few more 
than 256 random vectors to achieve a full rank, which is not an 
unreasonable amount:
Let's assume an exchange is running for 10 years, rotating keys every 
year, having 10 years of legal expiry, CS and RSA keys for the 15 Euro 
denominations (0.01 to 500).
This multiplies to 300 keys.

If the truncation attack would target a freshly installed wallet (which 
can not recognize missing known keys), the subset of old keys can be 
freely selected, i.e. linearly combined.

> The deletion attack requires an attacker to break 
> HTTPS/TLS *and* achieves very little, so I understand that Florian 
> didn't prioritize implementing it..

I Agree. Checking the signature alone does not gain much security, but 
maybe the wallet should record the signed hash value and the time range 
to the auditors to detect the attack.

But then - offline signing sorted lists of all possible /keys 
denominations results by the master key would be more direct and easier, 
as the number of time windows with different results is small.