Hacker News Reader

1. The vulnrability existed in their active codebase and network - only AFTER the research team contacted IOTA with the working exploit did they shut the entire (centralized) network down to patch the code.

  “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,” 
   

  Bruce Schneier, renowned security technologist, 
  about IOTA when we shared our attack.



  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. IOTA issued a patch that addresses the 
  vulnerabilities we found on August 7th. IOTA no longer has 
  the vulnerabilities we found, they have been fixed. To 
  learn more about the details of our attack, you can view 
  the full disclosure and review our attack examples.

https://github.com/mit-dci/tangled-curl/blob/master/vuln-iot...

https://github.com/mit-dci/tangled-curl

2. If every other cryptocurrency software team can impliment seed generation in their wallet software, why does IOTA refuse to?

3. Please read this comment from the CEO of IOTA, David Sønstebø on why he doesn't care if you lose money using IOTA: https://reddit.com/r/CryptoCurrency/comments/7gwl38/hello_gu...

1) In order for the attack to succeed, the attacker would have to have access to the seed at which point the entire thing becomes moot.

2) The android wallet has seed generation. So it's not a question of "refusal", more a question of priotities. Seedgen had not been a priority of the team. We can argue if its good or bad but at the end of the day, it is what it is. Creating a seed is not hard and if you can't put in the effort, well nobody is forcing you to jump into cutting edge experimental technology in search of lambo when!!!

3) Please click "parent" on that comment in order to realize that, yes, this is not a reply to the original post of the thread but to another person unlike it was made out to be and context does matter. Who knew?

1. The attack the MIT team developed on IOTA was a way to efficiently brute force wallet key combos to forge transactions of funds.

2. Every other cryptocurrency has implemented the seed generator as it's the most basic and fundamental feature necessary for this type of software. It's so trivial to implement, it really begs the question of why the IOTA team didn't just include it in all their software releases.

3. The comment CEO David Sønstebø was directly replying to was just commenting on how confusing the software is compared to other cryptocurrency wallets:

  I know it sounds simple newb mistake, but even me I 
  probably would have made that mistake and having been 
  using crypto for a while.

  So to sum it up don't use same receive address in IOTA. 
  I'll try to burn that in the back of my brain.

To add insult to injury regarding the OP who lost $30,000, it sure sounded like David was indirectly referencing that users loss with his response to the above comment

  "Price to pay for quantum security :) " - David Sønstebø, IOTA CEO

> 1. There have no vulnerabilities in the past.

I don't know man, the MIT Digital Currency Initiative found a pretty bad one last August:

https://medium.com/@neha/cryptographic-vulnerabilities-in-io...

> the IOTA developers had written their own hash function, Curl, and it produced collisions (when different inputs hash to the same output). Once we developed our attack, we could find collisions using commodity hardware within just a few minutes, and forge signatures on IOTA payments. We informed the IOTA developers, they patched their system, and we wrote a vulnerability report

DCI's report: https://github.com/mit-dci/tangled-curl/blob/master/vuln-iot...

What’s even worse is that they claimed the flaws were deliberate, and a method of ‘copy protection’, where the flaws were somehow avoided in their full codebase but would cause any competitor that copied their open source code to suffer the flaws.

Smells like a BS excuse to me, and if true, perhaps an even bigger red flag as it strikes me as a very unethical move that is antithetical to open source ideology.

Just to be clear, for the vulnerabilities DCI found to be exploited, the victim has to practically give away their private key at which point the descibed attack is moot.

IOTAs developer CFB has used this kind of copy protection for hen he developed NXT and his entire history is littered with arguing for putting a copy protection in place. His argument for putting that in place is any legitimate developer would review the code for vulnerabilities and kinks b fore implementation and only those trying to plagiarize the work would literally copy paste the code. That seems a rational argument to me and I am not entirely sure if the copy protection in IOTA’s case is deliberate or not but they say it is and his historical work seems to be in line with that

You should really read my first link and https://twitter.com/c___f___b/status/956445618381246464

The MIT-DCI are not credible..

I value the MIT Media Lab and its DCI group pretty highly. There is nothing about the Media Lab or the DCI in that first link of yours. [1]

So what were you trying to say?

What I did find in that first link of yours [1] is this gem though:

> The IOTA hash function, Curl-P, was designed to allow for practical collisions. The IOTA protocol’s security depends solely upon the one-wayness of the function, not its collision resistance. The rationale behind the design of Curl-P is a much more complicated question which we explain in detail.

This statement is alarming on so many levels.

[1] https://blog.iota.org/official-iota-foundation-response-to-t...

// edit: oops, I see now that it's a multipart post, so I'll have a look there.

// edit: yeah okay, nothing of substance in the other parts either.

Part 4 explains the Curl-P part in more detail, and it doesn't inspire any confidence. They are claiming that they intentionally inserted a known bad hash function in the open source part of the code, so that anyone "fraudulent" clones would be useless. The closed source coordinator is claimed to avoid this problem by some way, so they claim that the IOTA network is not affected.

I'm having a very hard time believing that explanation, but even if I do, it's still something that shows bad judgement in my opinion.

0. I upvoted this response because it provides a legitimate answer to the question of "what's the other side" / "how can people possibly find IOTA a good idea." I hope others do too: it's relevant to the conversation, even if we disagree with the merits of the post.

1. Parts 1 and 2 were all fluff. Part 3 responds to the actual technical claims, and several paragraphs of fluff later, confirms the MIT claim that funds were transferred out of user accounts to an account controlled by the IOTA Foundation without user consent. (They had consent from some other network participants / the "community", and supposedly they had very good reasons for it.) I gave up by part 4, sorry.

Where I come from—which happens to be MIT, in fact—security protocols have a threat model, either stated or unstated, and a confused threat model is a legitimate criticism. One of the common unstated parts of the threat model of cryptocurrencies is that, unlike with a government-issued currency, the organization behind the currency should not be implicitly trusted and certainly should not be able to take your money for your own good. Is this part of the IOTA threat model? What exactly is required technically for this sort of transfer?

If IOTA is supposed to be something that regular people will use (either directly or indirectly through interactions with IOT devices), point #2 doesn't seem relevant.

You can use a credit card without ever having to calculate your own Luhn checksum. You can send money to a bank account without having to untangle the rat's nest that is ACH.

It makes the IOTA team's priorities look skewed when they don't have basic wallet functionality, but they have time to implement ternary math and new cryptographic primitives that aren't useful with existing hardware.

Requiring users to choose a password as a seed for their keys is a catastrophically bad vulnerability. Is that really how IOTA works?

Sort of. You have to generate a seed(like a private key) and use that to log in. The seed has to be random. Some used a dice, others /dev/random.

I fully expect a wave of stolen IOTA to come from people who typed a 'random' code.

No they used a online seed generator..

I'm tempted to write a cracker for shitty seeds people come up with, but given what I've heard of the design of IOTA, I'm afraid of getting brain damage trying to understand and reimplement their algorithms.

I've thought about this too but determined that it's too black hat for me.

Also look at it yourself, don't listen to others. Everyone is trying to do price manipulation on anything remotely related to crypto.

I thought the white paper and code were really interesting and thought-provoking fwiw, regardless of the viability of the project itself.

Thank you for your reply (and I don't understand the downvotes), but I can't say it really changed my view on the currency.

>1. There have no vulnerabilities in the past. Please read: https://blog.iota.org/official-iota-foundation-response-to-t....

Let's have a look then. It's in 4 parts, the first two are not about the purported vulnerability but rather complaining that the people behind the discovery didn't disclose it properly and might have a hidden agenda. Fair enough I guess, but it's odd to start with that, it would make a much better point if it came after a strong rebuttal regarding the technical aspects of the vulnerability.

Then we get to the meat of the issue in the middle of page 3:

>2. IOTA Protocol Security and Tangle Reliability

So they start by addressing the "IOTA's coordinator is a single point of failure". Their reply is that... It's true but they never pretended that it was otherwise and that it's temporary:

>IOTA node operators, understanding the importance of the Coordinator’s role in securing the network while it is still young, voluntarily suspended operations during this time.

>The purpose of the Coordinator in the infancy stage of the IOTA network has been transparently communicated throughout the history of IOTA. As the team has explained at length, the Coordinator is a temporary measure to help bootstrap the network and protect it during its infancy. Once there are enough full nodes and transactions to secure and sustain the IOTA network, the Coordinator will be permanently removed from the network. The specific reasons for this are complicated; there is a more detailed explanation on page 19 of the white paper: “...this indicates the need for additional security measures, such as checkpoints, during the early days of a tangle-based system.”

So there's a solution in whitepaper form. As far as the current state of IOTA, they have not debunked any of DCI's claims. But that's still not really the main issue, the one about the broken hash function. They sure do take their time to get there.

Next they talk about whether or not IOTA devs can mess with IOTA accounts. Honestly I don't understand the issue well enough to pass a judgement but if I understand correctly they sort of forked IOTA "ethereum-style" in order to protect the users:

>Ultimately, in order to implement the preventative measures mentioned above, a special snapshot was scheduled wherein all funds vulnerable to theft were tagged with a key reuse marker.

They also say that "Importantly, these protective measures were only possible with the direct and active support of the IOTA community". Except that since they control the coordinator, what would happen if the community hadn't agreed? Can they go their own way without coordinator? Would they have to elect a new one?

Let's skip ahead and get to the vulnerability with the hash function, the last point of the last page in this document. This line stuck out to me:

>The answer is that the Coordinator was specifically designed, in addition to other purposes, to prevent precisely such an attack.

Ah, the coordinator again. Beyond that I don't understand the issue deeply enough to judge whether or not the vulnerability is as bad as DCI said so I can't decide who's right. I do find the justification behind the weakness rather... strange though:

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

So... there's nothing wrong with the function, it's just some kind of protection against people cloning the protocol (why is that a problem?) but even though everything is absolutely fine they decided to replace it anyway? It seems like such a weird decision, and also a bad precedent (you shouldn't have hidden functionality in your open source peer-to-peer cryptocurrency). It reminds me of Intel's "Spectre and Meltdown are the CPU operating exactly as designed" PR stunt.