Google have announced the discovery of a SHA-1 collision between two PDF files with distinct content.

While SHA-1 hashes are no longer permitted for SSL/TLS certificate fingerprints, and other measures would prevent certificate fingerprints from being manipulated in this way, what other uses of SHA-1 would be affected?

The attack authors mention GIT hashes as one possibility, but are there other common uses which do not have mitigation other than upgrading to another hash family or later SHA method?

For answers relating to how this collision was found, see this other question on Crypto.se

  • Researchers used an MD5 collision to generate a fake CA.
    – paj28
    Commented Feb 23, 2017 at 13:48
  • 1
    @paj28 I think that was the trigger for the "random data in serial number field" mitigation, which should help in the same way with making SHA-1 collisions of certificates harder.
    – Matthew
    Commented Feb 23, 2017 at 14:12
  • Indeed it was. Do we know whether all CAs actually randomize the serial number? MD5 was long deprecated by the time of the attack I linked, so there's clear precedent of CAs not following best practice.
    – paj28
    Commented Feb 23, 2017 at 15:31
  • @paj28 The CA/B forum requires it, but that doesn't mean that it always happens correctly, hence the desire to deprecate SHA-1. If we were confident that it was always implemented as required, there would be no need.
    – Xander
    Commented Feb 23, 2017 at 15:33
  • 2
    For git, see also: security.stackexchange.com/q/67920/29865
    – Ajedi32
    Commented Feb 23, 2017 at 20:41

1 Answer 1


Currently, given the specific collision method used, the impact is quite limited. In particular, this method does not allow for an attacker to generate a collision with an existing file, where a SHA-1 hash has been provided. It wouldn't be possible, for example, to use this method to generate a malicious executable file which matched the signature provided on the legitimate distribution website.

It would be possible, in theory, for an attacker to generate two executable files which have the same SHA-1 hash, but perform different things when run. Similarly, it would be possible to generate multiple ISO images which have the same SHA-1 hash. However, in each case, other hash values would not match, and it's common for download sites to provide multiple types of hash (for example, Ubuntu provide MD5, SHA-1 and SHA256 hashes for all downloads). This can be seen with the shattered-1.pdf and shattered-2.pdf files:

# sha1sum shattered-1.pdf
38762cf7f55934b34d179ae6a4c80cadccbb7f0a  shattered-1.pdf

# md5sum shattered-1.pdf
ee4aa52b139d925f8d8884402b0a750c  shattered-1.pdf

# sha1sum shattered-2.pdf
38762cf7f55934b34d179ae6a4c80cadccbb7f0a  shattered-2.pdf

# md5sum shattered-2.pdf
5bd9d8cabc46041579a311230539b8d1  shattered-2.pdf

It may be possible to create a kind of polyglot file which produces the same hash values in both SHA-1 and MD5, but this has not been demonstrated, and would still fail, given, for example, a SHA-512 hash.

Similarly, for any system where a SHA-1 hash is used as a file identifier, it may be possible to get one half of a colliding pair of files into the system, then to swap it out for the other. An example of this would be a backup system which used SHA-1 on a file level for determining whether files had been copied correctly. However, it would be difficult to make a hash of the entire backup contents remain the same in this case, since the malicious file is unlikely to form the prefix for the whole backup file (it's more likely to be something identifying the whole file as a backup).

Overall, therefore, the Google announcement mostly just confirms what had been suspected for a while - SHA-1 is vulnerable to collisions, just as MD5 was, but finding them requires a lot of effort, and most of the really high profile targets (such as generating CA certificates) have mitigation in place from the very similar MD5 collisions found previously. Experts have been advising moving from SHA-1 for a while now, and this advice still stands.

Just as with MD5, however, this doesn't particularly impact the use of HMAC-SHA1, since the specific combination method used in the construction of HMAC values makes this type of collision irrelevant.

  • 4
    Using both hashes is like using the concatenation, see Is using the concatenation of multiple hash algorithms more secure? for a result on this. Commented Feb 23, 2017 at 19:40
  • 12
    No, that's about combining hashes. I'm pointing out that other hash methods can still distinguish between colliding Sha-1 files. The answer you've referenced doesn't touch on this at all.
    – Matthew
    Commented Feb 23, 2017 at 20:01
  • 10
    If a combined hash made of MD5 and SHA-1 (by concatenation) has a collision on a message, then both SHA-1 and MD5 have a collision for this message – or did I understand this wrong? Commented Feb 23, 2017 at 22:39
  • 1
    @PaŭloEbermann, I interpreted your first comment as being about running one hash algorithm on the output of another (which is a bad idea) but looking more closely that's not what you meant, and you're correct.
    – Wildcard
    Commented Feb 24, 2017 at 4:50
  • 1
    The TLS/SSL handshake combines both hashes like this in its PRF. Interesting to see a tried and tested protocol that works without "all its eggs in one basket". Commented Feb 24, 2017 at 8:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .