Create a gist now

Instantly share code, notes, and snippets.

What would you like to do?
10th of September
My response to and
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
> 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 (
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 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 (
> 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 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 (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
> 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^25.5-ry numeral system in 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 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 ( and asked about the incentive structure ( - 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 ( 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 ( of the IOTA signature scheme.
The used definition cannot be applied to IOTA and some other DLTs (e.g.,, 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
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.
Sergey Ivancheglo aka Come-from-Beyond
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment