Profile picture
Matthew Green @matthew_d_green
, 21 tweets, 5 min read Read on Twitter
So I read those emails. That’s some toxic stuff to have to put in my brain. “Curl is not a hash function”.
Here’s the main claim that the researchers made, in email 12. It’s also what they wrote up in their report. It appears to be 100% technical correct.
The Iota teams seems to acknowledge this, but then says that the standard definition doesn’t matter because... Satoshi Nakamoto. Or something. Whatever. Under the standard definition it’s correct, so enough said.
The Iota team also implies that if there are checks outside the signature scheme then the signature scheme is not EU-CMA insecure. The researchers correctly rebut this.
Then there is a long stretch where the Iota team claims they have their own cryptographer saying things are fine. The researchers ask to be introduced but the Iota teams refuses based on “paperwork”.
This is so transparently ridiculous that at this point I would not have continued to work with the team in good faith.
But the researchers go farther, and (even though they’ve now demonstrated the insecurity of the scheme) they put together transactions that pass checks using the isValid() function in the Go implementation.
But. And I know you’re not going to believe this, given the high quality of Iota’s code. But it turns out the Go implementation might be broken. So this work is not valid.
However, the Iota devs admit the problems, if anything, are in high-level protocol elements and NOT the signature scheme. Moreover they seem easily fixable.
And now there’s a long back and forth where Neha sends transactions and they appear to require minor tweaks in the high-level protocol (not the signature scheme) to be accepted. There are several rounds that end with Neha sending bundles, and CFB responding with this.
I don’t know how to read this, but I read it as “the bundles seem valid”. I presume that’s how the researchers read it too.
Then there’s this long bizarre comment by CFB about second preimage resistance (not collision resistance, which is the issue the researchers are dealing with). It does not mention the bundles. So the researchers have to explicitly ask.
After some prodding CFB says there was some problem, but it’s not meaningful. Easy to fix, he says. And Neha does that. This appears to end the thread about bundles.
Finally, the researchers send over a complete draft of their disclosure. Regarding the bundles, CFB says that it “was valid syntaxically [sic]”. For non-computer scientists, this means it satisfied the signature verification checks.
CFB also notes that this payment *might* not be valid on the real network (they don’t say it IS invalid, notice!). I’m assuming that they’re referring to their closed source COO. Iota could check but for some reason they didn’t.
Notice that the COO isn’t part of the researchers’ claims. The researchers explicitly say that it’s closed source and (for very good reasons!) they didn’t run their attacks against the network.
So let’s recap. I think we might as well.

1. The researchers demonstrated a break in the formal EU-CMA security of the scheme (unless you make up your own definition.)
2. The Iota devs confirm that they provided syntactically valid bundles (at significant time investment!)
To summarize. This looks not only like a successful vulnerability disclosure, but an extremely meticulous and responsible one. And one that continued despite some very unprofessional behavior on Iota’s part.
I realize that I’m talking to two Iota shill accounts. But hopefully this thread will stand for anyone else who hears these claims and wants to know the truth.

So I am genuinely grateful you made me invest the time!
But enough time spent. Real work to do!
Missing some Tweet in this thread?
You can try to force a refresh.

Like this thread? Get email updates or save it to PDF!

Subscribe to Matthew Green
Profile picture

Get real-time email alerts when new unrolls are available from this author!

This content may be removed anytime!

Twitter may remove this content at anytime, convert it as a PDF, save and print for later use!

Try unrolling a thread yourself!

how to unroll video

1) Follow Thread Reader App on Twitter so you can easily mention us!

2) Go to a Twitter thread (series of Tweets by the same owner) and mention us with a keyword "unroll" @threadreaderapp unroll

You can practice here first or read more on our help page!

Did Thread Reader help you today?

Support us! We are indie developers!

This site is made by just three indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member and get exclusive features!

Premium member ($3.00/month or $30.00/year)

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!