6

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,

  1. Alice sends 100 IOTA from address A to Eve, signs and attaches the transaction.
  2. Alice receives another 1Gi onto address A

My questions:

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

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

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

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

  • Curl-P is still used for transaction hashing but not for input signing. – cmpn Jan 8 '18 at 15:00
  • edited to say signing - but doesn't the signature use the txn hash? or am I mistaken? am I mixing terms? – Matt Crouch Jan 8 '18 at 15:21
  • The input signatures are stored in the bundle of a transaction. The tx hash is the computed result hash of all this data together. – cmpn Jan 8 '18 at 20:07
  • 1
    As answer to a different question, I just explained the impact of Curl-P hash collisions and how it differs with and without coordinator. This pretty much answers your main question, too. – Lanu Moe Jan 8 '18 at 23:21
2

Curl-P is not use for signing transaction, therefore collisions in Curl-P is not relevant.

For question 1:

Eve can try to do it, but the probability to achieve this in reasonable time is extremely low.

For question 2:

Any bit change in signed data (the amount, the address,...) completely change the signature. It is not easier to brut-force an almost identical transaction than a completely different one.

For question 3:

Again, attacking an address with the knowledge of only one signature is practically impossible.

For question 4:

Eve knows 50% of the private and so can try to build a transaction with a hash very similar to the hash of the first transaction and brute-force the bits that are different. But once again, the probability to accomplish this in reasonable time is very low.


Note that as soon as Alice try to spend a second time from address A : the story is completely different because Eve knows more than 50% of the private key and it became drastically easier for her to generate a transaction hash matching the known portion of the private key. This leads to a race between Alice and Eve to be the first confirmed.


Why collisions in Curl-P aren't important ?

Curl-P remains in use just to do the POW (i.e. a useless computation challenge). In other words, today, Curl-P don't have any role regarding security of the funds.

  • 2
    I realise that Curl-P is no longer used for this, but my question relates to how collisions were not a problem when it was in use (since the devs have stated it was an intentional choice to allow collisions). The DCI report suggests that an 80 core box could generate collisions in a few minutes using differential cryptanalysis (whether this is verified or not I don't know) I think your answers are true for Kerl but are they also true if curl-p was used? – Matt Crouch Jan 8 '18 at 13:56
  • Ok... from my (poor) understanding, when Curl-P was in use for transaction signature, an additional-verification of the signature was done by the COO (or a trick was somehow included in milestone signature). And this trick/additional-verification should have detected and blocked fraud transactions. – ben75 Jan 8 '18 at 14:28

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.