[Discuss] Yesterday's Cloudflare News and Online Password Managers...

[kentborg at borg.org (Kent Borg)]

On 02/24/2017 10:51 AM, Richard Pieri wrote:
> Also, Google announced the first deliberate SHA-1 hash collision along
> with a practical technique for generating SHA-1 collisions:
>
> https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html
>

Fun:

   kentborg at thinpan:~/Downloads$ sha1sum shattered-1.pdf
   38762cf7f55934b34d179ae6a4c80cadccbb7f0a  shattered-1.pdf
   kentborg at thinpan:~/Downloads$ sha1sum shattered-2.pdf
   38762cf7f55934b34d179ae6a4c80cadccbb7f0a  shattered-2.pdf
   kentborg at thinpan:~/Downloads$ diff shattered-1.pdf shattered-2.pdf
   Binary files shattered-1.pdf and shattered-2.pdf differ
   kentborg at thinpan:~/Downloads$

Note there is a casual meaning of "practical" that might confuse here.

It is a stretch to say this technique is "practical" in the sense of 
being easy, routine, and day-to-day. But it is a sobering "practical" 
example in the sense of "has been demonstrated in practice". A 
significant difference there. This example took a lot of computer power 
circa-today to accomplish. However, expect it to get easier.

So there is very little reason to panic now, but schedule some panic for 
down the road maybe. And even then it seems an attacker would need to 
have a fair chunk of binary data space to work in to match an arbitrary 
hash. Your source code in git isn't going to be spoofed because someone 
dinked with a little whitespace to cover a "==" for "<=" substitution. I 
guess with unicode would make easier to hide the changes necessary for 
such a collision.

But yes, if you are making any hashes today of binary files, that you 
want to be good for years to come, use SHA-256 or better.

-kb, the Kent who recently decided he needed to use a hash in something 
he's programming at work, and there is no way he would have chosen SHA-1 
for that, even before yesterday's news.