Everything in that blog post is very much what the rest of the industry is agreeing with. Sources backing this up is even cited in the damn blog post man.
What industry? You mean the one that is less than 5yrs old?
IOTA itself, with all its 'smarts' made a stupid mistake designing their own cryptographic hash function! This might seem like I'm hanging on a single point, but I guarantee, any sane security person on this site will tell you to stay far away from this coin if they see this.
People design hash functions. Repeating that ‘creating a hash function is stupid’ doesn’t make it true. There is a need for an efficient, lightweight cryptographic standard for low resource devices. Curl-P attempts to be this solution utilizing ternary logic. They aren’t making it just because they can. There is a real need for it.
Recently, with the Foundation being established (therefore giving them access to sufficient funds), they hired CYBERCRYPT to vet and improve upon their prototype.
>Repeating that ‘creating a hash function is stupid’ doesn’t make it true.
There's a process for everything. Cryptographic functions are supposed to undergo atleast half a decade of peer testing before they can be used with any reasonable sense of security. Creating them isn't stupid. Creating them and using them in your application without proper security testing is.
If 'ternary' logic based hash didn't exist, then sure, create one. But don't tout it as being anywhere close to ready when it is important to the overall security of the system.
The project justifies their decision to do so about 'spearheading technology for a new paradigm', which further solidifies the fact they value short-term risky benefits over long term research which is what science is supposed to be.
There is no arbitrary time length requirement for security. There are standard tests (like avalanche) all of which Curl-P passed. They passed all the standard security requirements before deploying the prototype, and had a backup plan of deploying keccak should a hint of any possible exploit arise.
Curl-P is based on a well-studied sponge construction, so it’s not an especially risky move to deploy it in their system after it passed all initial security requirements.
Curl-P also has the advantage of being extremely simple. This makes it easier to vet as the analysis can be done more thoroughly, as it’s not obscured through complex internal mechanisms.
It does require new tools to study (as it’s ternary) so there is bound to be some delay to extremely thorough production readiness. However, saying it is not close to being ready is false (unless we must put an arbitrary year requirement on it as you seem to be keen on).
>There is no arbitrary time length requirement for security.
No there isn't, but it is about letting more researchers take a crack at it. With well-known competitions, you can expect cryptographers to take a look at it.
The thing is, I've heard of lots of new hashes in the past couple years but only heard about curl when the vulnerability was found. I'm not saying I was on the lookout for new hashes but didn't find any, but how do you except people to check it out when no one really knows about it? Even decades of time is worthless when you have no one looking at it.
>There are standard tests (like avalanche) all of which Curl-P passed.
That's basic homework, not the real test, which is analysis done by people. Give me some tets, a couple months and I can come up with a hash function which passes those too.
>Curl-P is based on a well-studied sponge construction, so it’s not an especially risky move
Sure, sponge construction, while new has been studied due to Keccak. But you should've used keccak, instead of creating a new one(As they're doing now)
> Curl-P also has the advantage of being extremely simple. This makes it easier to vet as the analysis can be done more thoroughly, as it’s not obscured through complex internal mechanisms.
You know what, I'm not a cryptographer, so I'll quote what a real cryptographer - Bruce Schneier has to say about that.
“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,”
What do you have to say to this?
>However, saying it is not close to being ready is false (unless we must put an arbitrary year requirement on it as you seem to be keen on).
Arbitrary year requirement seems frivolous, because you don't see the cryptographers who work hard quietly till they have an attack ready. It is to give time for them.
Take a look at previous competitions, where attacks surface many years after first publication.
> The thing is, I've heard of lots of new hashes in the past couple years but only heard about curl when the vulnerability was found. I'm not saying I was on the lookout for new hashes but didn't find any, but how do you except people to check it out when no one really knows about it? Even decades of time is worthless when you have no one looking at it.
Cryptographers have been looking at it. Initially the team reached out directly to a number of cryptographers, and they have an internal team as well. As a side note, it seems like a weird argument that since you haven't heard of it, no one really knows about it (especially given that you aren't a cryptographer). Additionally, as I said above, it's now being vetted by CYBERCRYPT: https://cybercrypt.dk/company/
Also, the article you cited is incorrect in it's assessment that a vulnerability was found. They assumed the ability to generate collisions was a vulnerability instead of a design choice. The security of Iota's current signature scheme relies on one-wayness of the hash function, which was not broken by the MIT team. In addition, the collisions would not result in compromised funds as they state, since forging a signature would require malicious software be downloaded by a user.
> Sure, sponge construction, while new has been studied due to Keccak. But you should've used keccak, instead of creating a new one(As they're doing now)
Keccak is not lightweight and therefore not a viable end solution. The network works much better with Curl-P. I will agree that it probably would've been better to just use Keccak initially till their hash function was vetted by a group like CYBERCRYPT if only to avoid the backlash from implementing a custom function. Hindsight is 20/20 though, and I imagine they were probably just keen on testing the tangle (which is much more unknown tech) in a state closer to it's end implementation.
You know what, I'm not a cryptographer, so I'll quote what a real cryptographer - Bruce Schneier has to say about that.
“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,”
What do you have to say to this?
This is not a valid argument. It is an appeal to authority. Besides, Bruce is commenting based on the original incorrect analysis by MIT.
> Arbitrary year requirement seems frivolous, because you don't see the cryptographers who work hard quietly till they have an attack ready. It is to give time for them.
Take a look at previous competitions, where attacks surface many years after first publication.
This is true. But it is also true for all hash functions including current well vetted ones. Better mathematical models are produced all the time. This kind of researched coupled with AI will likely make a lot of current hash functions vulnerable. What is the fix then? Most likely in the short term it will be quickly swapping to alternative hash functions, which the Iota team did quite easily (since they were prepared for the scenario). This seems like much better prep for the future to me than assuming Keccak or another hash function is forever golden.
So much misinformation, where to begin. IOTA is using Keccak/SHA-3, then they are developing a new kind of LIGHTWEIGHT cryptographic primitive together with the world leaders of this field
Kerl is Keccak I.E. SHA-3, the international NSA standard. They called it Kerl for fun in homage of Curl, which is still under active development with the absolute world-leading cryptographers of lightweight cryptography. Curl had to be invented to push LIGHTWEIGHT cryptography which is necessary for the Internet of Things. It's quite astonishing how much misinformation is spread around.
SHA-3 is not an NSA standard. It was invented by Guido Bertoni, Joan Daemen, Michaël Peeters and Gilles Van Assche who are researchers at various companies/universities and are from Italy and Belgium.
I am very curious about what 'LIGHTWEIGHT' cryptography is
defined as. I am also dubious about anyone that claims to have 'absolute world-leading cryptographers' since many strong cryptographers are quietly employed by intelligence agencies and most others are academics.
Also, since we are being pedantic, SHA-3/Keccak is an NIST standard, which is a federal agency of the United States.
I'm not an expert in the field, but there certainly have been efforts here and there to make "lightweight" crypto that needs little computational resources (and therefore battery power). One example would be KASUMI[0].
This is a common misunderstanding. IOTA never deployed a vulnerable hashfunction. They had precautionary measures in place and thus had Curl there to test it out, which worked out brilliantly. Keep in mind that IOTA asked the team to attack Curl, not the other way around. This was planned.
Curl is meant to be a lightweight crypto for IOT, a field of very active research. None of this is controversial to anyone that isn't looking for things to latch negativity onto.
> Keep in mind that IOTA asked the team to attack Curl, not the other way around. This was planned.
This seems to contradict the researcher's own post [1]:
> 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.
Finally, even if Curl is meant as a new, lightweight hash function, it was broken by differential cryptanalysis, not some novel, exotic attack vector. Sounds like it needs a lot of work before it's fit for purpose.
Can you provide a link please? All I see in the comments to the researcher's piece is an IOTA advisor threatening a libel suit - a really good sign that they "really care" about their technical issues.
Ok. I've read it. Nowhere does it mention IOTA contacting the researchers in question in May.
This article also answers the wrong question. If the crytocurrency is not cryptographically secure all that stands between an attacker and a victim is a piece of malware or social engineering. The fact that the researchers didn't go all the way and document a specific attack that could be performed tomorrow does not mean that Curl was secure in practice.
Finally this continues to fail to address many salient points. Like why use trits? Why wasn't kekkac used from day one?
