[Cryptography] SHA1 collisions make Git vulnerable to attakcs by third-parties, not just repo maintainers
Peter Gutmann
pgut001 at cs.auckland.ac.nz
Fri Feb 24 00:42:36 EST 2017
After sitting through an endless flood of headless-chicken messages on
multiple media about SHA-1 being fatally broken, I thought I'd do a quick
writeup about what this actually means. In short:
Reports of SHA-1's demise are considerably exaggerated.
What CWI/Google have done is confirmed what we've known for a long time, that
SHA-1 is shaky. Using a nation-state's worth of resources and a year of time
(https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html),
they've shown that, with a very carefully-crafted document, you can create a
collision. Their presentation of the results is detailed and accurate, it's
the panicked misinterpretation of those results that are the problem.
Overall, this is a neat piece of work. However, before everyone joins the
headless-chicken rally, let's look at its effect on real-world protocols
that use SHA-1. Which ones are affected by this?
SSL: Nope.
SSH: Nope.
PGP: Nope (when used for email).
S/MIME: Nope (see above).
OCSP: Nope.
IPsec: Nope.
OpenVPN: Nope.
SCEP/CMP/CMC/EST: Nope.
<lots of others>: Nope.
So what is actually affected?
Situations where you're creating signatures that need to be valid for a long
time, and where the enormous latency between legitimate signature creation
and forgery isn't an issue (this is why email won't be affected, having to
wait a year between email being sent and the forgery being received will
probably raise at least some suspicions of foul play).
What's left is long-term document signing and certificates, as pointed out
by the shattered.io FAQ. With certificates the chances of it being
exploitable in practice are fairly low, through a combination of CAs having
moved away from SHA-1, the fact that certificates are only valid for a year
which means you have to race to forge before it expires, and the fact that
any CAs that weren't already randomising serial numbers before the earlier
MD5 forged-cert attack will be doing it now.
Even for long-term document signing, these are frequently countersigned by
a TSA to deal with the fact that the original signing certificate will
expire after a year, in which case they're safe as well.
Finally, with other stuff (software updates, ISOs, and others), (a) why were
you still using SHA-1, and (b) you now have about 6-12 months to finally
move to SHA-256, and this time we mean it.
For everything else, you really do need to plan the move to SHA-256. Think
of this as a practical application of Wright's Principle, "Security won't
get better until tools for practical exploration of the attack surface are
made available".
Peter (who's at the tail end of a conference and only half awake, so I'll
need to go through the paper in more detail tomorrow in case there's
something I missed).
More information about the cryptography
mailing list