[flaminghedge]

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

[ktta]

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

[flaminghedge]

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