SHA1 collisions proven possisble

Thu Mar 2 14:26:32 UTC 2017

On Wed, Mar 1, 2017 at 10:57 PM, James DeVincentis via NANOG
<nanog at nanog.org> wrote:
> Let me add some context to the discussion.

> With specific regard to SSL certificates: "Are TLS/SSL certificates at risk? Any Certification
> Authority abiding by the CA/Browser Forum regulations is not allowed to issue SHA-1 certificates
> anymore. Furthermore, it is required that certificate authorities insert at least 64 bits of randomness
> inside the serial number field. If properly implemented this helps preventing a practical exploitation.”

Yes, they are at risk, of course.  This latest technique does not
appear able to be used to attack certificates, however.  Subscribers
to a CA don't have sufficient control of the contents of the signed
certificates a CA will issue;   Even if they did,   the computational
requirement with the described attack is likely to be slightly out of
reach.

The attack is not such that certs can be directly spoiled, *YET*;
However, It is almost surely a high likely possibility in the
forseeable future, and the existence of this attack does serve as
valid evidence further solidifying that the risk is very High now for
crypto applications of the SHA1 digest,  of  further  collision
attacks against SHA1  being made practical in the forseeable future
with very little or no further warning.

If you are still using SHA1 and were expecting to use it forever....
This attack is what gives
you your fair warning,  that in 6 or 7 years,  brute-forcing your SHA1
will likely be
within reach of the average script kiddie.

This does not fundamentally change security expectations for SHA1,  such attack
now being feasible with Google's resources is well-within expectations;
However,  the "Hype"  should be a wake-up call to some developers who
continue to write new software relying upon SHA1 for security under a false
belief  that SHA1 digest is still almost certain to be fundamentally
sound crypto for
many years to come.

If you are writing a program expected to be in use  5 years from now,  and
believe SHA1 will continue to meet your existing security requirements.
time to rethink that,  and realize the risk is very high for SHA1
becoming insecure
within a decade.

If the "Hype"  behind this Google thing is the catalyst that makes
some developers
think about the future of their choice of crypto algorithms more carefully
before relying upon them,   then that is a good thing.

> - Hardened SHA1 exists to prevent this exact type of attack.

I suppose hardened SHA1 is a  non-standard kludge of questionable durability.
Sure,  implement as a work-around for the current attack.
But  the future-going risk of continuing to use SHA1 remains qualitatively high.

> - Every hash function will eventually have collisions. It’s literally impossible
>  to create a hashing function that will never have a collision.   [snip]

There may be hashing functions which are likely to never have a practical
collision discovered by humans,  because of their size and improbability.

It's mostly a matter of the computing power currently available VS  size and
qualities of the hash.

> - Google created a weak example. The difference in the document they generated was a background color. They didn’t even go a full RGBA difference. They went from Red to Blue. That’s a difference of 4 bytes (R and B values). It took them nine quintillion computations to generate the

With some applications;  you'd be surprised what evil things you can
do if you change 4 Bytes to a malicious value.....

For example;  If you're digitally signing a binary,  4 Bytes is maybe
enough to overwrite a machine language instruction,  introducing an
exploitable bug  into the  machine code.

That latest attack on SHA1  will not allow code signing following
typical code signing algorithms to be attacked.

--
-JH