Official IOTA Foundation Response to the Digital Currency Initiative at the MIT Media Lab — Part 4…
The full article was originally published by IOTA Foundation on Medium. Read the full article here.
4. Vulnerabilities Found in the IOTA Hash Function
“Once the Digital Currency Initiative published the break in IOTA’s curl hash function, its author, Sergey Ivancheglo, offered two conflicting explanations for the vulnerability. The first explanation was that the flaw was intentional — that it was meant to serve as a form of “copy protection.” If anyone used this code in their own work, he said, the IOTA developers would be able to exploit the flaw and damage other systems that were using the hash function. However, later, he offered a conflicting explanation that he didn’t write the curl at all, but that an AI wrote it.
We do not find either of these explanations convincing, even in isolation. That they contradict each other makes them even less so.”
The original cryptographic vulnerability report was authored by (as presented on the report) Ethan Heilman (Boston University, Paragon Foundation, Commonwealth Crypto), Neha Narula (MIT Media Lab), Thaddeus Dryja (MIT Media Lab, Lightning Network Dev), and Madars Virza (MIT Media Lab, Zcash). There was an accompanying blog post posted by Neha on Medium entitled, “Cryptographic Vulnerabilities in IOTA.” In the report, DCI revealed practical collisions in the Curl-P hashing function. However, what their team failed to either understand, or deliberately did not disclose, even after being informed of this fact many times, is that the Curl-P function is not a cryptographic function nor was it intended to be. The Curl-P hashing function distributed in the open-source IOTA protocol intentionally included practical collisions where two different inputs result in the same hash outputs, which by cryptography standards would indeed be a very serious flaw.
For many months leading up to the publication of the report, Ethan and Neha were in direct contact with Sergey Ivancheglo (a.k.a., Come-from-beyond), IOTA co-founder, core developer and chief architect of the Curl-P function. These emails were released with the DCI side of the conversation redacted (we again invite Ethan and Neha to publicize the unredacted email exchange). As can be inferred from Sergey’s side of the exchange, he was allowed the opportunity to make corrections to the report prior to release. As is shown by the email below, Sergey requests that the function he designed be referred to as ‘Curl-P’, and requests that it not be referred to as ‘cryptographic’ because it was intentionally designed to allow practical collisions:
From: Sergey Ivancheglo, September 6th, 2017
“Curl” should be replaced with “Curl-P”. “Cryptographic” should be removed because Curl-P was designed to allow practical collisions.
DCI decided to ignore both of these corrections in the report they published, and of course the accompanying blog post published by Neha, was entitled, “Cryptographic Vulnerabilities in IOTA.” The report published by DCI does at least correctly note what the supposed attacks were not (emphasis added):
One can posit a stronger goal for the attacker: produce signatures on msg2, without seeing Alice’s signature on msg1. Our attacks do not achieve this much stronger goal.
As we said in Section 3, we did not test any of these attacks on the IOTA network. We therefore cannot predict what kind of role the IOTA coordinator would have in impacting this attack.
What this means is that, as we explained in our initial response, these attacks were both in fact extremely unrealistic to occur in practice. To be successful, an attacker would need to simultaneously:
- Find a user proficient enough in programming to sign bundles manually, but naive enough to sign a bundle created by somebody else;
- Know which addresses belonged to the user which, due to the way addresses are generated in IOTA, are unknowable unless the user shares them intentionally;
- Prevent the user from connecting to the network (eclipse attack), or connect to the network significantly faster than the user — both exceedingly difficult due to the mesh-net characteristics of the IOTA network.
But regardless of the feasibility of such an attack, we would like to take this opportunity to more thoroughly address the reasons behind the decision to introduce the Curl-P hashing function with practical collisions. We take full responsibility for the poor state of current documentation, and the fact that this explanation has (until now) been scattered rather haphazardly across various posts and platforms.
As the report correctly concedes, because the Coordinator is closed source, the DCI team could not predict what kind of role the IOTA Coordinator would have in impacting a collision attack. The answer is that the Coordinator was specifically designed, in addition to other purposes, to prevent precisely such an attack. Sergey explained his rationale for this design decision on Reddit here. The most relevant portion is copied below:
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’s lives and Tangle’s reputation. This is why a copy-protection mechanism [in the form of the Curl-P hashing function with practical collisions] 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.
In summary, Curl-P was indeed deployed in the open-source IOTA protocol code as a copy-protection mechanism to prevent bad actors cloning the protocol and using it for nefarious purposes. Once the practical collisions were uncovered, its purpose as a copy-protection mechanism was of course rendered obsolete (it only works for as long as it remains unknown) and IOTA reverted to the industry standard KECCAK-384 cryptographic function. It is not clear why DCI finds this explanation unconvincing. It is even less clear why DCI finds the two explanations Sergey provided on the genesis of Curl-P to be contradictory. Curl-P was in fact created through a particular AI technique called an ‘Evolutionary Algorithm’, and its purpose was to allow practical collisions as a copy-protection mechanism. We do not understand what is contradictory about these two statements or why neither is convincing, even in isolation.
Putting aside technical debates about cryptography, hashing functions, AI, and practical collisions, there is a much more important question here. Interestingly, Ethan, in a presentation he gave on their report which can be seen here, touched on this more important question in his conclusion. In it, he asks the following:
- Did we discover a copy-protection backdoor in IOTA?
- Is it ethical to design backdoors/vulnerabilities in a free and open source code as a copy protection mechanism? IOTA is GPL’d
The answer to the first question is of course, yes, as we have explained above. The latter of these two questions, by contrast, is indeed an important one to ask and is much more complicated to answer. One might pose that if Ethan appreciated the importance of this question, it is curious why it was never mentioned in the sensationally headlined blog post: “Cryptographic Vulnerabilities in IOTA”. Regardless of his intent, however, the discussion around the ethics of open-source software in the DLT context is an extremely important one for the community to have.
As Sergey mentions in his post on reddit, the open-source GNU Public License (GPL) does not mean that code can be copied and used for any purpose or in any way. Those using code for purposes outside of the GNU Public License can be held liable in court. However, in the DLT arena, where code is decentralized and distributed by potentially impossible to identify, anonymous online actors, these legal protections are mostly ineffective. So how, under these circumstances, can honest open-source software contributors ensure that their work is not re-purposed to nefarious aims?
Sergey, before co-founding IOTA, was the Founder of Nxt under the pseudonymous online identity BCNext, and had experienced exactly the type of scenario mentioned above. Nxt was the world’s first full Proof-of-Stake DLT protocol and integrated asset exchange. During this time, various scams using Nxt’s open-source software defrauded countless innocent people. Sergey and the other IOTA co-founders were determined to not let this happen again with IOTA.
The IOTA team made a design decision early on to prevent this possibility by purposefully introducing the Curl-P hashing function with known practical collisions. This had the express purpose of rendering fraudulent clones of the protocol useless in their application as a DLT protocol, while at the same time guaranteeing the security of the IOTA protocol and network as a whole. Any legitimate open-source software (OSS) developer who would consider using the IOTA code in a business critical application would undoubtedly review and test the code extensively prior to deploying it to production. And because the mechanism by which transactions are signed is so critical to the functioning of any DLT protocol, an unfamiliar Curl-P function would get extra scrutiny in particular. It is absolutely inconceivable that any legitimate OSS developer would have either failed to fully investigate the properties of the Curl-P function as it relates to digital signatures, or failed to simply replace it with an industry standard cryptographic function with which they are already very comfortable. In a fraudulent clone of the code, in contrast, the exact opposite is true. It is very likely that the code would not undergo any review at all. The Curl-P hashing function was in fact a very cleverly designed mechanism to allow legitimate OSS developers, and consequently the world, to benefit from the IOTA code while protecting it against misuse (at least until the practical collisions were revealed by DCI’s report). This can be thought of like a smart gun — it only works in the hands of an authorized user. Unlike a smart gun though, for the safety mechanism to be effective it is important that it is not publicly announced or made readily apparent.
We would ask if Neha, Ethan and their team are unhappy with the number of frauds and scams being perpetrated in this space. Given the absence of viable remedies to regulate these digital assets, and given that there is no clear way to reliably identify the people behind these crimes, what can honest contributors in the space do to protect innocent people from being defrauded by malicious software? We believe that honest contributors should take special precautions when possible, and this necessarily sometimes means that complete transparency and measures to protect innocent people are at odds with one another. Scientists also face this dilemma between transparency and secrecy (for example, related to the discovery of a dangerous new chemical compound). The IOTA team values transparency and the ideals of the open-source software movement tremendously, but we also do not want to see innocent people hurt as a result of our work. These are difficult questions with no easy answers, but in the end we know it is the integrity, sincerity and character of our actions which matter most, not how they may be perceived by others.
It is a shame that rather than discussing these very real and very serious issues facing the DLT community with Neha, Ethan and their colleagues, the IOTA team had to work overtime to calm the fear, uncertainty and doubt in the IOTA community generated by their sensationalist blog post about a “vulnerability” and a number of other non-issues that had no impact on the security of the IOTA protocol, user funds, or the Tangle whatsoever. If and when the DCI team release their vulnerability code, we would be happy to formally review its impact.
Hopefully, now that we have clearly laid out the reasons behind our decision, the entire DLT community can instead have the much more important discussion surrounding ethics and open-source software, and the potential for DLTs to be used for both noble and nefarious purposes. We welcome and look forward to this discussion.