Re:The first chosen-prefix collision for SHA-1
by staticassertion on Tuesday January 07, 2020 @01:40PM
(#21983079)
Is SHA1 not still faster than 256/512? And Blake2 barely faster? I suspect with some hardware SHA1 is still going to beat all of those out - am I wrong? I would love to learn more.
Re:The first chosen-prefix collision for SHA-1
by tptacek on Tuesday January 07, 2020 @04:11PM
(#21984905)
https://bench.cr.yp.to/results-hash.html
Regardless, no competent designer is going to use SHA1.
Re:The first chosen-prefix collision for SHA-1
by staticassertion on Tuesday January 07, 2020 @04:31PM
(#21985115)
Thank you, that's an excellent chart.
Re:The first chosen-prefix collision for SHA-1
by __s on Tuesday January 07, 2020 @04:55PM
(#21985400)
CRC is faster than SHA1
Re:The first chosen-prefix collision for SHA-1
by mzs on Tuesday January 07, 2020 @06:06PM
(#21986216)
It's not about the speed, it's about the 'is it secure.'
Re:The first chosen-prefix collision for SHA-1
by sicariusnoctis on Tuesday January 07, 2020 @07:38PM
(#21986989)
If my amazing hash function takes 10^10^10 years to compute, it's possibly more secure than anything else listed there, but it's also quite useless.
In particular, a primitive makes a number of useful promises. Any achievement that describes a way in which a promise is not kept makes that primitive broken, regardless of whether that achievement is theoretical or practical.
(They often talk about “theoretically broken” or “practically broken” to distinguish whether it was actually done.)
> it's not like SHA-1 is broken for every single possible usage
True, but it is extremely easy to believe your usage is unbroken and be wrong. Besides, often, primitives that are broken for one usage eventually break for others.
> why the nonsense with "no good reason"? Obviously performance is one significant consideration for the unbroken use cases
There are many much more robust primitives with better performance nowadays, such as BLAKE2, SHA-512/256, or Kangaroo12.