IOTA Cofounder Sergey Ivancheglo aka Come-from-Beyond’s Responses to the ongoing FUD about so called ‘vulnerabilities’ in IOTA Code which never really existed

IOTA is a distributed ledger technology. “Distributed” means that the ledger data are spread across numerous computers connected into a network. You, probably, know such phrase as “A system is more than the sum of its parts”. A system emerging from computers connected together possesses properties not seen in a single computer. IOTA as a system has such useful property: several computers may fail, but the others will keep working without problems. IOTA behaves as a single self-healing organism here. Unfortunately, self-healing stops at some point, for IOTA this happens after more than 1/3 of the computers fail. This is not unique to IOTA, other distributed ledger technologies (e.g. Bitcoin) have their threshold of collapse too.

These days IOTA is still small and this opens it to the following attack: an adversary joins IOTA with his computers which take more than 1/3 of IOTA’s body and then makes the computers fail thus triggering IOTA’s collapse. To counteract this attack we are running a set of computers called Coordinator which issues milestones published on IOTA’s tangle. Computers not belonging to an adversary rely on these milestones to detect faulty computers. In this setup IOTA can survive even if 99% of the computers fail.

IOTA is open-source software. In the world controlled by the state open-source software is protected with licenses, someone doing things not allowed by the license can be sued. Cryptocoin industry demonstrated to be very resistant to state regulations, this led to majority of the projects run in this industry to be oriented on scamming ordinary people. IOTA team welcomes attempts to use technology IOTA is based on. This helps IOTA because increases awareness and shows that Tangle is indeed a viable technology. Unfortunately, odds that copies of IOTA codebase will be used for good are very low. We can’t just watch an IOTA clone scamming people and ruining people lives and Tangle’s reputation. This is why a copy-protection mechanism was added from the very beginning.

To explain how the copy-protection works we should recall about existence of Coordinator. Coordinator acts as an ultimate oracle if any uncertainty about the current state of things in IOTA arise. Digital signatures are verified by every computer in IOTA network, if a signature passes the verification routine then it’s, PROBABLY, valid. To make sure that the signature is indeed valid the computer waits for the transaction containing the signature to be referenced by a milestone. This is a perfect place for placing the copy-protection mechanism. While everyone looks at signature verification routine the real verification happens in the routine updating milestones. This trick resembles a focus trick done by magicians on TV. It worked so perfectly, that Neha Narula’s team was fooled despite of me explaining the essence of the trick numerous times.

Now, when we know that all signatures must be endorsed by Coordinator before being accepted as valid, we can move to that part about Curl-P hashing function. Necessity to develop the function was justified. Trinary numeral system is getting off the ground now, today it’s mainly Artificial Neural Networks which already have specialized processing units in development. No doubt, that later we’ll see CPUs doing trinary computations. To avoid derailing my response I won’t be expanding this topic, IOTA blogposts contain all relevant information. Being the creator of Curl-P I knew its properties very well. I changed the number of rounds to allow practical collisions. With Coordinator IOTA’s security depends on one-wayness of Curl-P, without Coordinator the security depends on collision resistance. This is a very important part, it means that your phrase “the Iota development team deliberately introduced faults into the Iota codebase” is WRONG. IOTA is unaffected by collisions in Curl-P, scam-driven clones are.

To provide an answer to your “Are there any other deliberate defects in the Iota source code that have not been disclosed?” is not easy. I disagree with your choice of words (“defects”). If you put the same meaning as I do then my answer is: IOTA doesn’t nor didn’t have known defects. If you mean the copy-protection then my answer is: It’s not smart to answer this question, because in the case of the copy-protection being completely removed my honest answer won’t allow us to exploit uncertainty which may prevent scammers from cloning IOTA.

I think that you misunderstood the situation around Curl-P collisions, a lot of people did too and this is not surprising taking into account sensational tone of Neha Narula’s team blogpost where such boring issue as an intentionally added feature inflated to “The end is near” problem.


10th of September

Sergey Ivancheglo aka Come-from-Beyond’s Response to this medium article by Neha Narula and this vulnerability report on github

The original response is here

“I will be blunt to save everyone’s time. I apologize in advance if this style insults anyone, but I assure that any offence is unintentional.

>In its repositories on GitHub, we found a serious vulnerability — the IOTA developers had written their own hash function, Curl, and it produced collisions (when different inputs hash to the same output).

The ability to generate collisions was a design choice. Quantitative analysis of that is presented in my letter from the 12th of August published at https://goo.gl/YALM4B

> Once we developed our attack, we could find collisions using commodity hardware within just a few minutes, and forge signatures on IOTA payments.

The presented forgery happens in a scenario impossible in practice because requires to run code written not by IOTA developers, if a user can be tricked into running arbitrary code then stealing the seed is much easier and more profitable.

> We informed the IOTA developers, they patched their system, and we wrote a vulnerability report.

“Patched” is a wrong word here. IOTA developers removed a part of the copy-protection mechanism which became useless once details of its work had become known to others.

> The current version of IOTA does not have the vulnerabilities we found…

No practically possible vulnerability was ever found according to the vulnerability report attached to the blogpost.

> “In 2017, leaving your crypto algorithm vulnerable to differential cryptanalysis is a rookie mistake. It says that no one of any calibre analyzed their system, and that the odds that their fix makes the system secure is low,” states Bruce Schneier, renowned security technologist, about IOTA when we shared our attack.

Appeal to authority is a well-known logical fallacy and is usually used when one runs out of arguments proving their claim (https://en.wikipedia.org/wiki/Argument_from_authority ).

To prove my point I use exactly the same trick:

“One of the great commandments of science is, “Mistrust arguments from authority.” … Too many such arguments have proved too painfully wrong. Authorities must prove their contentions like everybody else.” — Carl Sagan.

> We discovered a vulnerability in IOTA after reviewing their code on GitHub in July. We disclosed what we found to the IOTA team on July 14th, and have been in contact with them since then as we discovered new issues and exploits.

All these “issues” and “exploits” can be seen in my letters published on https://goo.gl/YALM4B . What were perceived as issues and exploits were actually incorrect usage of Curl-P caused by the lack of the documentation. It should be noted that we informed Neha Narula’s team of this fact in the linked correspondence, but they chose to disregard this, instead choosing to publish this as a vulnerability, which is concerning.

> IOTA issued a patch that addresses the vulnerabilities we found on August 7th.

“Patch” is a wrong word here. IOTA developers removed a part of the copy-protection mechanism which became useless once details of its work had become known to others.

> IOTA no longer has the vulnerabilities we found, they have been fixed.

No real vulnerabilities were found, hence nothing was to fix. The changes in the code were related to removal of some parts of the copy-protection mechanism and were deployed together with scheduled improvements to the protocol.

> To learn more about the details of our attack…

No practical attack besides perhaps a Public Relations attack was demonstrated by Neha Narula’s team.

> So when we noticed that the IOTA developers had written their own hash function, it was a huge red flag. It should probably have been a huge red flag for anyone involved with IOTA.

Usage of a new hash function was justified ( https://blog.iota.org/upgrades-updates-d12145e381eb ).

> We found that IOTA’s custom hash function Curl is vulnerable to a well-known technique for breaking hash functions called differential cryptanalysis, which we then used to generate practical collisions.

Even without cryptography it is not hard to see that Curl-P allows the generation of collisions. (For the details, please, refer to my letter from the 12th of August at https://goo.gl/YALM4B). Here the differential cryptanalysis looks like overkill or as an attempt to give more significance to something that is not significant.

> Using our techniques, a bad actor could have destroyed users’ funds, or possibly, stolen user funds.

Only if users violated basic security practices which would be equivalent to giving away the private keys.

> We show the details of our proposed attacks, one which destroys user funds and one which steals IOTA from a user, in this repository.

At the time of this writing the provided link did not contain code allowing an attacker to do that to an arbitrary user. Neha Narula’s team did not provide information about the percentage of the users which could be affected. A quantitative analysis published on https://goo.gl/YALM4B (see the letter from the 12th of August) makes us think that their attack is applicable only to negligible percentage of the users and as an adversary cannot predict in advance if a user being attacked belongs to the set of the potential victims, this further limits applicability of the attack.

> Tadge Dryja first noticed that that the Curl hash function looked suspicious…

The signs allowing Tadge Dryja to distinguish a suspicious hash function from a non-suspicious should be made public.

> …and brought in Ethan Heilman, who did the bulk of the cryptanalysis to figure out how to create collisions.

Most of that cryptanalysis was based on such Curl-P feature as an easy-to-find fixed point, which was a design choice mistakenly perceived by Ethan Heilman as a vulnerability. More information on this matter is available in my first letters to Neha Narula’s team at https://goo.gl/YALM4B

> I implemented a practical attack…

Which worked in an improbable scenario for one particular user only.

> …and Madars Virza did an independent analysis to try to directly invert the hash function using algebraic techniques (which has not yet been successful, and is not included in the report).

Unclear how hard he was trying and if he has enough expertise for such kind of task. Some background except the name would be helpful because affiliation with Zcash tells nothing about his skills.

> There are other red flags?-?unlike every other program running on your laptop or phone, IOTA uses ternary instead of binary. Since all computer hardware today uses binary, IOTA converts to ternary in software, which is less efficient and more complex.

Daniel J. Bernstein used 2²⁵.5-ry numeral system in http://cr.yp.to/ecdh/curve25519-20060209.pdf . This is an example of how losing on conversion one can win on computations.

> This complexity prevents IOTA from benefiting from existing security analysis tools that are designed to work with binary, and makes the code harder to read and understand.

No explanation why 2-bit representation of a trit cannot be done was provided. “Harder to read and understand” part is an exaggeration, programmers adapt to such things very fast, all IOTA developers demonstrated that. Personal experience of the blogpost author should not be taken as a typical case.

> Another inefficiency is that transactions in IOTA are 10KB (in contrast, Bitcoin transactions are on average 600B), meaning that this is not well-suited to devices with limited storage, like those used for IoT, one of the developers’ primary use cases.

A typical transfer takes 6.4 KiB if the technique explained in my letter from the 15th of July at https://goo.gl/YALM4B is not used, otherwise it is 3.7 KiB. Bitcoin transactions used for IoT would take much more space because of a lot of small inputs/outputs.

> Others have written about IOTA’s use of a trusted coordinator ( https://medium.com/@ercwl/iota-is-centralized-6289246e7b4d ) and asked about the incentive structure ( http://www.tangleblog.com/wp-content/uploads/2017/06/unfiltered_convo_tangle_security_june_17.pdf ) — whether users of their system have an incentive to converge the tangle if each acted selfishly.

The first link is authored by someone who appears to be perpetrating a blatant lie ( https://medium.com/@DavidSonstebo/co-founder-sergeys-response-2bd9284e523e ). When confronted about his real identity, he refused, raising suspicions that he had a hidden agenda. The second link contains 85 unfiltered pages of conversations, which is either disrespectful to the readers or aversion to allowing the readers to efficiently verify her words.

> But the fact that none of IOTA’s partners raised these concerns about a glaring vulnerability in a ~$2B cryptocurrency, or spoke about the other red flags, is worrisome.

IOTA’s partners are aware of the current state of IOTA and that Coordinator works as a protection. PoCs are being done on testnets and the used hash function is irrelevant. Colleges and universities are doing research in areas which cannot be affected by potential cryptographic issues, therefore they would not necessarily be expected to audit that aspect — this would be like asking all computer science departments to audit the computer chip circuitry on which they are building software. “Glaring vulnerability” is incorrect here because it exists only in that improbable scenario imagined by Neha Narula.

This is the end of the response to the blogpost. Not much can be said about the vulnerability report:

> [T]he IOTA developers asked us to refer to it has “Curl-P”, but we declined since it is referred to as “Curl” publicly.

A similar situation is observed with Keccak family, but researchers use Keccak instance names (e.g. Keccak-f[1600]) in their papers. However admittedly minor this may be, it does reveal how much Neha Narula’s team values the scientific aspect and consistency of their own report.

> Exploiting these weaknesses in Curl, we break the EU-CMA security ( http://www.cs.tau.ac.il/~canetti/f08-materials/scribe8.pdf ) of the IOTA signature scheme.

The used definition cannot be applied to IOTA and some other DLTs (e.g. https://bitslog.files.wordpress.com/2012/04/mave1.pdf http://www.jbonneau.com/doc/BM14-SPW-fawkescoin.pdf), so it is not surprising Neha Narula’s team got invalid results.

> We emphasize that to produce a signature on a msg2, our attacks require Alice to sign an innocent-looking related message, msg1, of our choosing. This is a chosen message attack. We have not developed a known message attack.

This attack would require users to download malicious software not approved by the IOTA foundation. If users could be persuaded to do this, then their seeds would be compromised without the need for any attack.

> This report provides example demonstrations of these vulnerabilities but does not detail the exact cryptanalytic process to generate the collisions. A later publication will provide an in-depth study of our cryptanalysis of Curl.

I am looking forward to seeing that publication. I would like to see if Neha Narula’s team is able to improve their method and attack an arbitrary user, in this report only an attack on a single hand-picked user was demonstrated.

I do not address the claim of Curl-P not being pseudo-random, they used Curl-P incorrectly (forgot to seed the RNG).

Neha Narula’s team provided the following interest disclosure:

> Ethan Heilman is involved in cryptocurrency work with the Paragon Foundation and Commonwealth Crypto Inc. Madars Virza is a Science Advisor at the Zcash company. On May 8th, Dominik Schiener reached out to Ethan over Twitter to talk about IOTA. Nothing happened from that initial outreach.

Relevant information about these organisations:

Paragon Foundation works on a technology which aims to compete with IOTA in the future. Zcash’s main feature is anonymity which is threatened by Repudiation and Mixing features of IOTA. Neha Narula and Thaddeus Dryja did not disclose their interest, I leave it to the readers to find out if they work on projects attempting to compete with IOTA.

The very last bit from their vulnerability report:

> Responsible Disclosure statement: This report is the product of a responsible disclosure process.

The disclosure was arguably not responsible. More information is available in my very last letters published at https://goo.gl/YALM4B

TLDR version:

Neha Narula’s team provided no new information to the IOTA team besides the fact that they used differential cryptanalysis to speed-up the search for collisions. Practical collisions in Curl-P is a design choice as an integral part of the copy-protection mechanism. Security of the IOTA signature scheme relies on one-wayness of the hash function which was not broken, despite of the attempts to do so. The presented attacks, while called “practical”, were conducted under improbable scenarios.

It is important for readers to understand that members of Neha Narula’s team have a vested interest in multiple projects that are in direct competition with IOTA, many of which may stand to benefit from IOTA’s demise. Additionally, it appears that multiple people unrelated to the research team became aware of this disclosure both before it was publicly made and before the IOTA software was updated. This raises concerns about the process of responsible disclosure in this case.”

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.