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.