On Wed, Mar 1, 2017 at 10:57 PM, James DeVincentis via NANOG <nanog@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