Cryptographic vulnerabilities in IOTA
medium.com
Cryptographic vulnerabilities in IOTA
1–10 of 73 posts
Re: Cryptographic vulnerabilities in IOTA
#2> “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.
Indeed
Re: Cryptographic vulnerabilities in IOTA
#3> “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. Indeed
Moreover, rolling their own hash function (which is what they did) is a rookie mistake.
Re: Cryptographic vulnerabilities in IOTA
#4I even think that the issues with new cryptocurrencies is underestimated in the article. The problem goes beyond the cryptographic aspect to game theoretical challenges: the cryptographic protocols could be perfect and yet the cryptocurrency be insecure or offer a low security threshold.
For example, Bitcoin is perfect from the cryptographic perspective but its security threshold is around 33% [1]. Last year we also started a spreadsheet to benchmark different cryptocurrency metrics [2] but the blockchain/cryptocurrency/ICO space outpaced this initiative ;-).
[1] https://arxiv.org/abs/1311.0243
[2] https://docs.google.com/spreadsheets/d/1DQ770nGnHfJOoRSqTLmI...
Re: Cryptographic vulnerabilities in IOTA
#5> “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. Indeed
Moreover, rolling their own hash function (which is what they did) is a rookie mistake.
Note that IOTA is a system based on ternary rather than binary, which itself is a WTF.
Then on top of that, the hash function they replaced the broken one with is a wrapping of SHA3 (Keccak) with ternary. So again, they rolled their own crypto, although in a (hopefully!) more minor way.
Unfortunately, doing review is a lot of hard work - I know the people involved and they had to waste time and money talking to lawyers and the like - so it's quite possible we won't find out about the flaws in their "fix" until some hacker exploits them to steal money.
Even relatively small changes to hash functions and using them in non-standard ways often fails to give the security guarantees you expected. For instance, this idea from Russell O'Conner is a good example: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017...
His extremely professional handling of the situation is also a good example!
Re: Cryptographic vulnerabilities in IOTA
#6Doing Qora code analysis few years ago, I found that not all the fields of a block are signed (made an issue, still open https://github.com/razakal/Qora/issues/14), and also found some probable DoS vectors. I think many second- and third-tier cryptocurrencies are technically garbage.
Re: Cryptographic vulnerabilities in IOTA
#7Earlier quoted context omitted.
Moreover, rolling their own hash function (which is what they did) is a rookie mistake.
Note that IOTA is a system based on ternary rather than binary, which itself is a WTF. Then on top of that, the hash function they replaced the broken one with is a wrapping of SHA3 (Keccak) with ternary. So again, they rolled their own crypto, although in a (hopefully!) more minor way. Unfortunately, doing review is a lot of hard work - I know the people involved and they had to waste time and money talking to lawye…
Actually, SHA3 was not converted to ternary. The input is simply chunked into 243 trits that are converted to 48 bytes and are absorbed into KECCAK-384. Squeezing works the other way round, 48 bytes are squeezed and converted into 243 trits.
Re: Cryptographic vulnerabilities in IOTA
#8Hurts to read this. The author manages to repeat exact sentences more than two times in just a few paragraphs.
Re: Cryptographic vulnerabilities in IOTA
#9Does anyone know if the IOTA devs ever wrote down a justification for using a hand-rolled hash instead of, like, SHA-256? If so, can you link it in a comment?
EDIT: I feel compelled to explicitly say that this was a mind-bogglingly stupid thing to do, and there is almost no way to justify it. I'm just curious what they thought they were accomplishing.
Re: Cryptographic vulnerabilities in IOTA
#10Earlier quoted context omitted.
Note that IOTA is a system based on ternary rather than binary, which itself is a WTF. Then on top of that, the hash function they replaced the broken one with is a wrapping of SHA3 (Keccak) with ternary. So again, they rolled their own crypto, although in a (hopefully!) more minor way. Unfortunately, doing review is a lot of hard work - I know the people involved and they had to waste time and money talking to lawye…
Actually, SHA3 was not converted to ternary. The input is simply chunked into 243 trits that are converted to 48 bytes and are absorbed into KECCAK-384. Squeezing works the other way round, 48 bytes are squeezed and converted into 243 trits.
Ah, that's a good point - I was aware of that, but you made me realize that using the word "convert" to describe what they did could give the wrong impression. I've changed my description to say they "wrapped" SHA3.