The IOTA devs have stated that Curl-p is not a cryptographic hashing function and one way collisions are not an issue for the usage in IOTA. (and of course, Curl-p is not even used for signing now so it is not currently relevant)
I understand that the attack vectors suggested by DCI are extremely far-fetched. They involve the attacker (Eve) generating two bundles with the same hash but different amounts, and then rely on Alice for some reason signing one of those bundles.
However I am trying to understand what prevents a similar attack where someone has re-used an address - although addresses 'shouldn't' be re-used, they obviously have been in many cases.
So for example,
- Alice sends 100 IOTA from address A to Eve, signs and attaches the transaction.
- Alice receives another 1Gi onto address A
Eve knows the signature and the hash for the first transaction. What prevents Eve from generating another transaction to send 1Gi from address A to herself, twiddling the bits (trits?) until the transaction hash collides, then attaching that transaction?
What about if the first transaction was not sent to Eve but another random party, could an attacker easily generate a hash collision with a different output address, or does it rely on the transaction being very similar?
If a transaction was pending for a long time, would it be feasible for Eve to generate a collision and have a transaction confirmed before the original transaction is confirmed, without Alice ever receiving onto address A again?
Does an attacker even need to generate a full collision? It seems that with the one-time signature, they already know half of the private key, so, say it's only a little different, it would only need a 'small' amount of brute forcing to generate the rest of the private key.
I don't have any real background in cryptography, so I suspect there is something I'm missing which means that it's not as simple as this for an attacker. I would just like to understand better why a collision doesn't matter.