> So in essence any hash that can be run faster in any way will make it weaker in terms of brut forcing
Hash functions have many, many uses beyond password storage. For most of those uses they become more, not less, useful with speed. Fast hash functions are good for everybody. If you explicitly want a slow expensive construct, then chose one properly designed to be slow and expensive. Don't just chose a crappy hash function.
> So in summary I believe NIST should let them all win and have SH3.n with n being the variation of finalist, let them all win, choice is good and that is what n bit encryption is after all, extra choices.
I completely disagree. An organization like NIST has a responsibility to have an opinion on what the 'best' hash function is. They then need to track the state of the art of research that might invalidate that decision, and clearly communicate changes in the decision. While there is a defense-in-depth argument to be made for multiple options, the pattern seems to have been that there are a lot more systems broken because they chose a poorly studied or known bad algorithm than by breaks being found in previously known-good algorithms. We have a lot to lose from everybody making it up as they go along.
If NIST pick just one and they later find a issue via research in that one solution then the whole standard is dust and if SH3 becomes no more. If they pick more than one as I said all of them for example then if one of those vatriations is found to be flawed later on then that subset can be dust and the SH3 standard and implementation can carry on moving on without have the issue of suddenly having nothing to fallback upon. Sure there are other standards that currently can be fallen back upon but if some kit supports SH3 only then with SH3 having variations as a standard can only be better thing than not. These finalists have been tested alot already, more so than previous so it is not a case of making it up appraoch at all, they would of had to pass alot of standard/hurdles to get this far. But what I'm saying is if they all pass all the tests then picking a winner gets down to other nuances and the abilty to have more than one winner add's more rubustness to the standard in that any single solution found later on to have a flaw would negate the whole standard as apposed to a subsection of it by having more than one option, hence the SH3.n.
That all said if everybody agreed on everything then life as we know it would be boring and we would all be fighting over the same women at some stage, which would not work out well.
"That all said if everybody agreed on everything then life as we know it would be boring and we would all be fighting over the same women at some stage, which would not work out well."
This would be especially awkward, since apparently she would also be fighting over herself and presumably would just elope with herself.
You do not want standards that have good parts and bad parts. If SHA3 blows up, then they pick something else and call it SHA4. And then everybody can look at the label on the box and know whether it's good or bad without having to read the entire list of ingredients.
Comments
> So in essence any hash that can be run faster in any way will make it weaker in terms of brut forcing
Hash functions have many, many uses beyond password storage. For most of those uses they become more, not less, useful with speed. Fast hash functions are good for everybody. If you explicitly want a slow expensive construct, then chose one properly designed to be slow and expensive. Don't just chose a crappy hash function.
> So in summary I believe NIST should let them all win and have SH3.n with n being the variation of finalist, let them all win, choice is good and that is what n bit encryption is after all, extra choices.
I completely disagree. An organization like NIST has a responsibility to have an opinion on what the 'best' hash function is. They then need to track the state of the art of research that might invalidate that decision, and clearly communicate changes in the decision. While there is a defense-in-depth argument to be made for multiple options, the pattern seems to have been that there are a lot more systems broken because they chose a poorly studied or known bad algorithm than by breaks being found in previously known-good algorithms. We have a lot to lose from everybody making it up as they go along.
If NIST pick just one and they later find a issue via research in that one solution then the whole standard is dust and if SH3 becomes no more. If they pick more than one as I said all of them for example then if one of those vatriations is found to be flawed later on then that subset can be dust and the SH3 standard and implementation can carry on moving on without have the issue of suddenly having nothing to fallback upon. Sure there are other standards that currently can be fallen back upon but if some kit supports SH3 only then with SH3 having variations as a standard can only be better thing than not. These finalists have been tested alot already, more so than previous so it is not a case of making it up appraoch at all, they would of had to pass alot of standard/hurdles to get this far. But what I'm saying is if they all pass all the tests then picking a winner gets down to other nuances and the abilty to have more than one winner add's more rubustness to the standard in that any single solution found later on to have a flaw would negate the whole standard as apposed to a subsection of it by having more than one option, hence the SH3.n.
That all said if everybody agreed on everything then life as we know it would be boring and we would all be fighting over the same women at some stage, which would not work out well.
"That all said if everybody agreed on everything then life as we know it would be boring and we would all be fighting over the same women at some stage, which would not work out well."
This would be especially awkward, since apparently she would also be fighting over herself and presumably would just elope with herself.
You do not want standards that have good parts and bad parts. If SHA3 blows up, then they pick something else and call it SHA4. And then everybody can look at the label on the box and know whether it's good or bad without having to read the entire list of ingredients.