
Announcing the first SHA-1 collision - pfg
https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html
======
nneonneo
The visual description of the colliding files, at
[http://shattered.io/static/pdf_format.png](http://shattered.io/static/pdf_format.png),
is not very helpful in understanding how they produced the PDFs, so I took
apart the PDFs and worked it out.

Basically, each PDF contains a single large (421,385-byte) JPG image, followed
by a few PDF commands to display the JPG. The collision lives entirely in the
JPG data - the PDF format is merely incidental here. Extracting out the two
images shows two JPG files with different contents (but different SHA-1 hashes
since the necessary prefix is missing). Each PDF consists of a common prefix
(which contains the PDF header, JPG stream descriptor and some JPG headers),
and a common suffix (containing image data and PDF display commands).

The header of each JPG contains a comment field, aligned such that the 16-bit
length value of the field lies in the collision zone. Thus, when the collision
is generated, one of the PDFs will have a longer comment field than the other.
After that, they concatenate two complete JPG image streams with different
image content - File 1 sees the first image stream and File 2 sees the second
image stream. This is achieved by using misalignment of the comment fields to
cause the first image stream to appear as a comment in File 2 (more
specifically, as a sequence of comments, in order to avoid overflowing the
16-bit comment length field). Since JPGs terminate at the end-of-file (FFD9)
marker, the second image stream isn't even examined in File 1 (whereas that
marker is just inside a comment in File 2).

tl;dr: the two "PDFs" are just wrappers around JPGs, which each contain two
independent image streams, switched by way of a variable-length comment field.

~~~
CGamesPlay
Great analysis. So why did Google choose to use PDFs instead of JPGs directly?

~~~
nneonneo
The notion of "document security" is a common desire in business and legal
contexts. PDFs are a standard representation of documents, whereas JPGs are
less common (TIFF might count since it's a somewhat common scanned document
format, but I digress).

Subverting the most popular document format, one which even provides built-in
support for digital signatures is probably much more interesting than
subverting the JPG format.

Open challenge: build two signed PDFs with identical signatures and different
contents - it's not necessarily hard, and it would definitely drive the point
home.

~~~
spiznnx
I wonder if this is the 'standard' thing to do when you have a broken hash
function. I took a introductory course in computer security a year ago and we
had to create MD5 hash-colliding documents for homework[0].

[0]
[https://courses.engr.illinois.edu/cs461/sp2015/static/proj1....](https://courses.engr.illinois.edu/cs461/sp2015/static/proj1.pdf)
(see part 4)

~~~
ritmatter
I'm interested in taking a look at this assignment for my own learning, but it
looks like there are a bunch of files you need. It would be cool if you put
them in a git repo!

------
m3ta
To put things into perspective, let the Bitcoin network hashrate (double
SHA256 per second) = B and the number of SHA1 hashes calculated in shattered =
G.

B = 3,116,899,000,000,000,000

G = 9,223,372,036,854,775,808

Every three seconds the Bitcoin mining network brute-forces the same amount of
hashes as Google did to perform this attack. Of course, the brute-force
approach will always take longer than a strategic approach; this comment is
only meant to put into perspective the sheer number of hashes calculated.

~~~
problems
A few considerations though:

\- Google used GPUs, much of the Bitcoin network relies on fully custom ASICs
now and mining without them isn't really profitable anymore

\- SHA1 hashes can also be computed over twice as fast as SHA256 even on GPUs,
so if someone were to go out and build SHA1 ASICs, you could probably do this
very, very fast. It's almost certain that intelligence agencies could invest
this effort to say, break SHA1 SSL certs.

~~~
btilly
_It 's almost certain that intelligence agencies could invest this effort to
say, break SHA1 SSL certs._

To the contrary, it is unlikely that they can do so.

There is a world of difference between "come up with two things that hash to
the same value" and "come up with something that hashes to a particular known
value". It gets harder still if you're trying to add constraints about the
format of your text (such as making them look like a potentially valid SSL
cert).

To illustrate the difference, suppose that you can constrain the algorithm to
produce one of a trillion values. If you generate a million possibilities,
odds are good that 2 of them will have the same hash value. You've generated a
collision! But you need to do a million times as much work to have good odds
of generating any particular value.

That said, attacks only improve over time. While it is highly unlikely that
intelligence agencies can break SHA1 certs today, it is extremely likely that
they will eventually. Where eventually is 5-20 years.

~~~
problems
> There is a world of difference between "come up with two things that hash to
> the same value" and "come up with something that hashes to a particular
> known value".

Doesn't the PDF on their site pretty much prove they can do both of these - at
least, in a way? They were able to change the color without impacting the
contents of the PDF and get the same SHA1.

They probably have a fair bit of garbage data to work with in the PDF format,
but it seems likely that you might be able to do similar in certificate
formats.

Remember, you only need a very small modification to change a valid web cert
into a CA cert or a global wildcard.

~~~
jsolson
No. I don't know the details of the attack, but a third possibility (as I read
it) is that _both_ PDF documents are modified in the process until they arrive
at a collision.

PDF has the convenient property that you can inject arbitrary bogus data into
the middle of it with a constant head and tail and it will still be valid. The
tail of the file contains a trailer that points to the dictionary that
describes where all of the resources in the file are located. The entire file
need not be covered by the dictionary (and typically won't be for PDFs that
have gone through several rounds of annotation/modification). This leaves the
opportunity "dead chunks" that can be modified arbitrarily without changing
the rendered result.

~~~
makomk
Or, if you're really clever - and Ange Albertini is quite good at this kind of
trick - you can design the PDF so that the different garbage in the middle
causes the other, unchanged content to be interpreted differently in the two
PDF files, possibly even designing it so that the intended contents of each
PDF is treated as garbage and ignored entirely in the other PDF.

~~~
stcredzero
With many image formats, you can just concatenate whatever you want at the end
of the file, and the OS and programs will obliviously read and copy the whole
file, while the image libraries will happily ignore the extra data.

~~~
cestith
And then you put PHP tags in that content at the end, and change the .htaccess
file to process *.jpeg as PHP scripts, and your webshell looks benign until
someone has that in mind looking through the account.

~~~
dogma1138
You don't need to find a collision to do that :)

------
mabbo
One practical attack using this: create a torrent of some highly desirable
content- the latest hot TV show in high def or whatever. Make two copies, one
that is malware free, another that isn't.

Release the clean one and let it spread for a day or two. Then join the
torrent, but spread the malware-hosting version. Checksums would all check
out, other users would be reporting that it's the real thing, but now you've
got 1000 people purposely downloading ransomware from you- and sharing it with
others.

Apparently it costs around $100,000 to compute the collisions, but so what? If
I've got 10,000 installing my 1BTC-to-unlock ransomware, I'll get a return on
investment.

This will mess up torrent sharing websites in a hurry.

Edit: some people have pointed out some totally legitimate potential flaws in
this idea. And they're probably right, those may sink the entire scheme. But
keep in mind that this is one idea off the top of my head, and I'm not any
security expert. There's plenty of actors out there who have more reasons and
time to think up scarier ideas.

The reality is, we need to very quickly stop trusting SHA1 for anything. And a
lot of software is not ready to make that change overnight.

~~~
babyrainbow
Malware in a video? Is that possible? How does it work?

~~~
ktta
You could have a buffer overflow attack talking advantage of a specific
popular video player out there.

Since video players are usually not very security focused, someone determined
could do it.

And since video torrents are unzipped, a single chunk can be replaced with the
malicious chunk with the attack code. It can look like a tiny jitter depending
on the chunk size/total video size.

~~~
throwaway2048
You could just do this with a video you release anyways, and skip the century
of GPU runtime.

This break requires you control/generate both the original and the evil file.

~~~
svantana
My thought exactly, although you would need your malware to incubate for some
time to allow it to spread properly first.

~~~
mlonkibjuyhv
I wonder if you could model this similarly to populations. As in will the
malware ever go extinct? Obviously an attacker probably won't stop seeding,
but let's say shim does stop seeding. At this point x% of seeders have the
payload. Seeders on average share the file y times. Will x tend to zero below
a threshold of 50%?

And if the attacker does not stop seeding, will the infected quota stabilize?

------
cesarb
On a quick scroll of the comments, I haven't seen this posted so far:
[http://valerieaurora.org/hash.html](http://valerieaurora.org/hash.html)

We're at the "First collision found" stage, where the programmer reaction is
"Gather around a co-worker's computer, comparing the colliding inputs and
running the hash function on them", and the non-expert reaction is "Explain
why a simple collision attack is still useless, it's really the second pre-
image attack that counts".

~~~
kuschkufan
Love this page. Someone should remind her to update the table for sha1 now.

~~~
rocqua
It seems to have been updated already.

------
lisper
This point seems to be getting re-hashed (no pun intended) a lot, so here's a
quick summary: there are three kinds of attacks on cryptographic hashes:
collision attacks, second-preimage attacks, and first-preimage attacks.

Collision attack: find two documents with the same hash. That's what was done
here.

Second-preimage attack: given a document, find a second document with the same
hash.

First-preimage attack: given an arbitrary hash, find a document with that
hash.

These are in order of increasing severity. A collision attack is the least
severe, but it's still very serious. You can't use a collision to compromise
existing certificates, but you can use them to compromise future certificates
because you can get a signature on one document that is also valid for a
different document. Collision attacks are also stepping stones to pre-image
attacks.

UPDATE: some people are raising the possibility of hashes where some values
have 1 or 0 preimages, which makes second and first preimage attacks formally
impossible. Yes, such hashes are possible (in fact trivial) to construct, but
they are not cryptographically secure. One of the requirements for a
cryptographically secure hash is that all possible hash values are (more or
less) equally likely.

~~~
mikegerwitz
The severity between the preimage attacks depends on context.

For Git, for example, a first-preimage attack won't buy you anything, but a
second-preimage could be potentially devastating depending on how lucky you
get.

If Mallory wanted to make it look like you signed a document you didn't,
second-preimage would be devestating. And with the demonstration of two PDFs
sharing the same hash, this is a pretty severe one: many PGP signatures, for
example, still use SHA-1. But even so, you could take some signature from any
point in the past.

~~~
gliptic
If you can do a first-preimage attack, you can do a second-preimage attack.
Just hash the document you have. Therefore a first-preimage attack is strictly
more severe.

~~~
xamuel
mikegerwitz is technically right. As an illuminating example, consider a hash-
algorithm in which there's at least one hash that occurs precisely once. Then
a 2nd-preimage attack is formally impossible no matter how much computational
power you have (assuming by "second" you meant "distinct second"). But a 1st-
preimage attack is formally possible.

~~~
lisper
One of the requirements for a hash to be cryptographically secure is that all
possible values are equally likely. So yes, it is possible (in fact trivial)
to construct a hash of the sort you describe, but such a hash would not be
cryptographically secure to begin with.

~~~
Dylan16807
It's easier to use and to reason about a uniform hash, but you can design a
secure system with a non-uniform hash.

I'd be willing to bet that an altered version of SHA3-256 that replaces four
bits in the middle with length%16 is better for most purposes than SHA256,
despite being non-uniform.

------
mate_soos
I am a bit saddened that Vegard Nossum's work, which they used for encoding
SHA-1 to SAT, is only mentioned as a footnote. The github code is at

[https://github.com/vegard/sha1-sat](https://github.com/vegard/sha1-sat)

and his Master Thesis, whose quality is approaching a PhD thesis is here:

[https://www.duo.uio.no/bitstream/handle/10852/34912/thesis-o...](https://www.duo.uio.no/bitstream/handle/10852/34912/thesis-
output.pdf)

Note that they also only mention MiniSat as a footnote, which is pretty bad.
The relevant paper is at

[http://minisat.se/downloads/MiniSat.pdf](http://minisat.se/downloads/MiniSat.pdf)

All of these are great reads. Highly recommended.

------
amichal
Linked [http://shattered.io/](http://shattered.io/) has two PDFs that render
differently as examples. They indeed have same SHA-1 and are even the same
size.

    
    
      $ls -l sha*.pdf 
      -rw-r--r--@ 1 amichal  staff  422435 Feb 23 10:01 shattered-1.pdf
      -rw-r--r--@ 1 amichal  staff  422435 Feb 23 10:14 shattered-2.pdf
      $shasum -a 1 sha*.pdf
      38762cf7f55934b34d179ae6a4c80cadccbb7f0a  shattered-1.pdf
      38762cf7f55934b34d179ae6a4c80cadccbb7f0a  shattered-2.pdf
    

Of course other hashes are different:

    
    
      $shasum -a 256 sha*.pdf
    
      2bb787a73e37352f92383abe7e2902936d1059ad9f1ba6daaa9c1e58ee6970d0  shattered-1.pdf
      d4488775d29bdef7993367d541064dbdda50d383f89f0aa13a6ff2e0894ba5ff  shattered-2.pdf 
    
      $md5 sha*.pdf
      
      MD5 (shattered-1.pdf) = ee4aa52b139d925f8d8884402b0a750c
      MD5 (shattered-2.pdf) = 5bd9d8cabc46041579a311230539b8d1

~~~
Twirrim
The PDF example given is somewhat ridiculous.

"For example, by crafting the two colliding PDF files as two rental agreements
with different rent, it is possible to trick someone to create a valid
signature for a high-rent contract by having him or her sign a low-rent
contract. "

Talk about ridiculous scenarios only people living in a tech bubble could come
up with.

How many landlords do you imagine know what sha-1 checksums even are, let
alone would try and use it as proof the evil version of the rental agreement
is incorrect?

"I would have gotten away with it, if it wasn't for you meddling kids and your
fancy SHA-256 checksums!"

~~~
udev
This is not as far fetched as you think.

In UK, rental contracts are often digitally signed by the renter and landlord.

I am sure in finance world many other types of contracts are signed digitally,
also under the assumption that both parties sign the same thing.

~~~
pornel
The "signing" usually doesn't involve any cryptography. You just express your
agreement, which can be as trivial as typing your initials in a box.

It's purely a legal, not technical thing, so if you cleverly forge the
document using collisions, you'll be shouting "but the SHA-1 matched!" from
behind the bars.

~~~
pfg
The legal thing does make reference to the technical thing in Europe[1] (and
probably elsewhere too), by making digital signatures (which use crypto)
legally binding. The question is more how courts would rule in a case where a
colliding document is signed. That would probably depend on whether you can
prove which of the two parties authored the colliding document (since that's a
requirement for this particular attack).

(Note: I don't know whether this attack is practical for qualified electronic
signatures as used by EU countries.)

[1]:
[https://en.wikipedia.org/wiki/Qualified_electronic_signature](https://en.wikipedia.org/wiki/Qualified_electronic_signature)

------
anilgulecha
Big things affected:

* DHT/torrent hashes - A group of malicious peers could serve malware for a given hash.

* Git - A commit may be replaced by another without affecting the following commits.

* PGP/GPG -- Any old keys still in use. (New keys do not use SHA1.)

* Distribution software checksum. SHA1 is the most common digest provided (even MD5 for many).

Edit: Yes, I understand this is a collision attack. But yes, it's still a
attack vector as 2 same blocks can be generated now, with one published,
widely deployed (torrent/git), and then replaced at a later date.

~~~
fivesigma
None of what you mentioned is affected since this is a collision attack. They
purposely created 2 files with the same hash.

Creating a file with the same hash as legit file is a preimage attack and is
much more difficult to perform (many orders of magnitude more difficult).

This still doesn't mean that SHA-1 isn't dogshit however. It should have been
phased out years ago.

~~~
anilgulecha
Create 2 torrents with the same hash.

Release one into the wild.

Wait.

Infect.

~~~
koolba
Torrents have a tree of hashes for the parts. That allows validating pieces
without the entire file (which is also validated at the end).

Probabilistically, the hashes of the parts would _not_ match even if the top
level hash matched.

~~~
pgeorgi
You could (try to) collide one of the blocks at the end of the tree. The tree
of hashes will still be the same since the hash of the block didn't change.

Then join the torrent with a client that doesn't download but only upload that
block (there will be some that will pick it from you). Many legit copies,
except for those that were so unlucky to fetch the block from you.

If you manage to build such a block based on one in recurring content (eg. a
distributor's logo at the beginning of the file), it could be reused, too.

~~~
koolba
> You could (try to) collide one of the blocks at the end of the tree. The
> tree of hashes will still be the same since the hash of the block didn't
> change.

Except you can't do that as this isn't a preimage attack. You can't create an
arbitrary bad file matching an existing SHA-1 with this.

~~~
jakeogh
On the other hand it's useful for denial of service. If you want to disrupt a
swarm feeding it bad data is 'good enough'.

~~~
koolba
> On the other hand it's useful for denial of service. If you want to disrupt
> a swarm feeding it bad data is 'good enough'.

No you can't do that either. Again, this is _not_ a preimage attack:
[https://en.wikipedia.org/wiki/Preimage_attack](https://en.wikipedia.org/wiki/Preimage_attack)

That means you can't use this to match an arbitrary SHA-1. That means you
can't use it to generate bad parts of a larger file.

What you're describing is already possible by having clients connect to a
swarm, pretend they have parts of a file, and send gibberish. The receiver
won't know until they finished downloading the part and hence waste the part-
size in download capacity (i.e. DOS). I bet with IPv6 it'd be really easy to
have a single malicious client pretend to be a world of swarm members.

~~~
jakeogh
Thanks, so it can gen 2 same size colliding chunks, but it can not take an arb
chunk and generate a collision for it. Right?

~~~
koolba
Yes that's my understanding of it. In the PDF example on the site, the file
format allows enough tweaking to the raw data without impacting the content to
make it feasible.

------
ikeboy
Someone just made about $2500

See [https://lists.linuxfoundation.org/pipermail/bitcoin-
dev/2013...](https://lists.linuxfoundation.org/pipermail/bitcoin-
dev/2013-September/003253.html) and
[https://bitcoinchain.com/block_explorer/address/37k7toV1Nv4D...](https://bitcoinchain.com/block_explorer/address/37k7toV1Nv4DfmQbmZ8KuZDQCYK9x5KpzP)

~~~
JshWright
That would offset a very, very tiny fraction of the cost of 56,940,000 CPU
hours and 963,600 GPU hours.

~~~
robjan
The person who collected it was most likely not a Google employee; just the
first person to download those files who knew about the bounty.

------
Aissen
I love the fact that there is a tool for detecting any collision using this
algorithm: [https://github.com/cr-
marcstevens/sha1collisiondetection](https://github.com/cr-
marcstevens/sha1collisiondetection)

and it's super effective: _The possibility of false positives can be neglected
as the probability is smaller than 2^-90._

It's also interesting that this attack is from the same author that detected
that Flame (the nation-state virus) was signed using an unknown collision
algorithm on MD5 (cited in the shattered paper introduction).

------
korm
[2012] Schneier - When Will We See Collisions for SHA-1?

[https://www.schneier.com/blog/archives/2012/10/when_will_we_...](https://www.schneier.com/blog/archives/2012/10/when_will_we_se.html)

Pretty close in his estimation.

~~~
qznc
Schneier predicted "between 2018--2021 depending on resources". He explicitly
says "Since this argument only takes into account commodity hardware and not
[...] GPUs". Since Google used GPUs that very well explains the speedup to
2017.

------
0x0
I'm trying to play with this in git. Added the first file, committed, and then
overwrote the file with the second file and committed again. But even when
cloning this repository into another directory, I'm still getting different
files between commit 1 and 2. What does it take to trick git into thinking the
files are the same? I half expected "git status" to say "no changes" after
overwriting the first (committed) pdf with the second pdf?

~~~
js2
This is because git adds a header and zlib compresses the PDFs such that they
no longer collide when stored in git. But of course, they still collide when
extracted from git:

    
    
        $ ls -l; for i in 1 2; do sha1sum < shattered-$i.pdf; \
        git cat-file -p $(git hash-object -w shattered-$i.pdf) |
        sha1sum; done; find .git/objects -type f -print0 | xargs -0 ls -l
        total 1664
        -rw-r--r--@ 1 jay  staff  422435 Feb 23 10:32 shattered-1.pdf
        -rw-r--r--@ 1 jay  staff  422435 Feb 23 10:32 shattered-2.pdf
        38762cf7f55934b34d179ae6a4c80cadccbb7f0a
        38762cf7f55934b34d179ae6a4c80cadccbb7f0a
        38762cf7f55934b34d179ae6a4c80cadccbb7f0a
        38762cf7f55934b34d179ae6a4c80cadccbb7f0a
        -r--r--r--  1 jay  staff  381104 Feb 23 10:41 .git/objects/b6/21eeccd5c7edac9b7dcba35a8d5afd075e24f2
        -r--r--r--  1 jay  staff  381102 Feb 23 10:41 .git/objects/ba/9aaa145ccd24ef760cf31c74d8f7ca1a2e47b0
    

See "Object Storage" for details at [https://git-scm.com/book/en/v2/Git-
Internals-Git-Objects](https://git-scm.com/book/en/v2/Git-Internals-Git-
Objects)

It's worth noting that either of the changes, adding a header or deflating the
content, would remove the collision. The former because this is a chosen-
prefix collision attack, the latter because the compression alters the content
entirely.

I'm not a cryptographer, so I wonder: do the git header and zlib compression
add significant complexity to manufacturing two files that collide inside git?

~~~
cesarb
The compression is applied after the hashing, so it doesn't make any
difference. Only the "blob <size>" header matters.

------
SamBam
I'm confused by the "File Tester" at
[https://shattered.it/](https://shattered.it/)

It says "Upload any file to test if they are part of a collision attack."

When I upload either of their two sample collision documents, it says they are
"Safe."

~~~
cavanasm
I get "Collision found". Couldn't even begin to guess what's causing it to say
it's safe on your end, unless you modified the files.

------
mikeash
For those of us who are totally clueless about the construction of these hash
functions, what is the fundamental flaw in SHA-1 that allows this attack? How
do newer hash functions avoid it?

~~~
an_d_rew
The newest SHA members are based on sponge functions.
[http://keccak.noekeon.org/](http://keccak.noekeon.org/) gives a good
overview.

~~~
mikeash
Thank you, great link.

------
mckoss
Computing a collision today costs about $100K from my reading of the paper. So
most uses of SHA1 are protecting documents of far lower value, and would not
be likely attack targets (today).

~~~
danielweber
There are many areas of security where you can genuinely get by with
obfuscation, hoping the attacker looks elsewhere, or general security-through-
obscurity.

You can't in crypto. When the entire system relies on an axiom being true, you
need to make sure it's true. The attacks are only going to get better. The
attacks are going to come from the future. The embedded systems will not be
replaced in time.

------
jasode
_> Nine quintillion computations; 6,500 years of CPU; 110 years of GPU_

Is there a rough calculation in terms of today's $$$ cost to implement the
attack?

~~~
raphaelj
They provide an estimate in their paper:

> The monetary cost of computing the second block of the

> attack by renting Amazon instances can be estimated from

> these various data. Using a p2.16xlarge instance,

> featuring 16 K80 GPUs and nominally costing

> US$ 14.4 per hour would cost US$ 560 K for the

> necessary 71 device years. It would be more economical

> for a patient attacker to wait for low “spot prices” of

> the smaller g2.8xlarge instances, which feature four K520

> GPUs, roughly equivalent to a K40 or a GTX 970. Assuming

> thusly an effort of 100 device years, and a typical spot

> price of US$ 0.5 per hour, the overall cost would be of

> US$ 110 K.

~~~
alfalfasprout
Eh, at that point you may as well buy the servers yourself and let them run
on-premises. Even with power, etc. that cost could easily come down 50% or
more. Once you own the servers, additional tasks just cost power.

~~~
Strom
In addition, as any bitcoin miner knows, AMD GPUs are actually far more
efficient at calculating hashes.

------
jeffdavis
Does git have any path away from SHA1?

I know the attack isn't practical today, but the writing is on the wall.

~~~
paulddraper
The writing has been on the wall for a long time, but Linus has been dead
against it.

> And we should all digitally sign every single object too, and we should use
> 4096-bit PGP keys and unguessable passphrases that are at least 20 words in
> length. And we should then build a bunker 5 miles underground, encased in
> lead, so that somebody cannot flip a few bits with a ray-gun, and make us
> believe that the sha1's match when they don't. Oh, and we need to all wear
> aluminum propeller beanies to make sure that they don't use that ray-gun to
> make us do the modification _ourselves_.

He says it's not a security issue, so there are no "attacks" to protect
against.

> the point is the SHA-1, as far as Git is concerned, isn't even a security
> feature. It's purely a consistency check. The security parts are elsewhere,
> so a lot of people assume that since Git uses SHA-1 and SHA-1 is used for
> cryptographically secure stuff, they think that, OK, it's a huge security
> feature. It has nothing at all to do with security, it's just the best hash
> you can get.

I don't know how correct that is.

~~~
philipn
At least in the current discussion, Linus says that eventually moving away
from SHA1 in Git is a "no brainer," but that this announcement isn't a "sky is
falling" moment. (e.g. [https://public-
inbox.org/git/CA+55aFz98r7NC_3BW_1HU9-0C-HcrF...](https://public-
inbox.org/git/CA+55aFz98r7NC_3BW_1HU9-0C-HcrFou3=0gmRcS38=-x8dmVw@mail.gmail.com/))

~~~
paulddraper
Huh. And I've already got this 4-mile deep bunker hole...

------
jgrahamc
How am I going to explain this to my wife?

Actually a serious question. How do we communicate something like this to the
general public?

~~~
ktta
You don't really need to talk to anybody about this except people who torrent
both illegal and legal torrents.

Torrent poisoning is the most ripe for exploitation and the one with the
highest return for a malicious attacker.

So when you talk to someone who torrents, just tell them that the way the
torrents verify a file is the correct one is no longer secure, and they have
to keep an eye out for the next software update. And if anyone is paranoid,
then stop downloading new torrent files, although there is no problem with
seeding.

Now that I think about it, I think it is crucial for everyone to keep seeding
as much as they can, because it reduces the probability of a bad torrent chunk
from spreading as much across the network.

EDIT: Here's a good article that isn't very technical

[https://www.wired.com/2017/02/common-cryptographic-tool-
turn...](https://www.wired.com/2017/02/common-cryptographic-tool-turns-
majorly-insecure/)

~~~
digler999
wont an easy fix be to just hash it again with sha256? Sure that will take
time to bake it into software, but wont they just be able to put a text label
next to the description and say "sha256: abc...123" ?

~~~
ktta
Yes, but I doubt most would follow through.

------
matt_wulfeck
> _We then leveraged Google’s technical expertise and cloud infrastructure to
> compute the collision which is one of the largest computations ever
> completed._

And this, my friends, is why the big players (google, Amazon, etc) will win at
the cloud offering game. When the instances are not purchased they can be used
extensively internally.

------
koolba
What's the impact to something like git that makes extensive use of SHA-1?

In their example they've created two PDFs with the same SHA-1. Could I replace
the blob in a git repo with the "bad" version of a file if it matches the
SHA-1?

~~~
giovannibajo1
This is not a pre-image attack, so you can't create a file that matches an
existing SHA1. It's a collision attack, so you can create two files whose SHA1
is the same.

So what I could potentially do (given a multi-million dollar budget) is create
from scratch two git repositories with different content, whose HEAD is the
same. This would allow me to serve different repositories to different users.

What is currently still not feasible is to create a custom git repository
whose HEAD matches that of the Linux kernel.

See also: [http://crypto.stackexchange.com/questions/1173/what-are-
prei...](http://crypto.stackexchange.com/questions/1173/what-are-preimage-
resistance-and-collision-resistance-and-how-can-the-lack-ther)

~~~
OJFord
> _What is currently still not feasible is to create a custom git repository
> whose HEAD matches that of the Linux kernel._

Hang on, that doesn't matter though, does it?

I was under the impression that git's SHAs were to be treated as repo-wise
unique; not universally. There must non-adversarial 'collisions' across
repositories already, surely?

I thought this attack potentially allows creating two commits in the same repo
with the same hash - although it may only be possible for these to be root
commits.

~~~
rlanday
I don't think there's ever been an example of two different pieces of content
hashing to the same SHA-1 before. An infinite number of such examples
obviously must exist but they're incredibly improbably to encounter by
accident.

~~~
OJFord
Yep, sorry, it was far too early in the day for me to appreciate the magnitude
of 2^{160}.

If I could downvote myself...

------
Phithagoras
The paper is available at [https://marc-
stevens.nl/research/papers/SBKAM17-SHAttered.pd...](https://marc-
stevens.nl/research/papers/SBKAM17-SHAttered.pdf)

------
korethr
So, since Git uses SHA-1, does this mean we're going to see a new major
version number of Git that uses SHA-2 or SHA-3 in a few years?

I don't expect one overnight. For one, as noted, this is a collision attack,
one which took a large scale of power to achieve. In light of that, I don't
think the integrity of git repos is in immediate danger. So I don't think it'd
be an immediate concern of the the Git devs.

Secondly, wouldn't moving to SHA-2 or SHA-3 be a compatibility-breaking
change? I'd think that would be painful to deal with, especially the larger
the code base, or the more activity it sees. Linux itself would be a worst-
case scenario in that regard. But, it can be pulled off for Linux, then I'd
think any other code base should be achievable.

~~~
philipn
You can check out the git developer mailing list discussion here:
[https://public-
inbox.org/git/20170223164306.spg2avxzukkggrpb...](https://public-
inbox.org/git/20170223164306.spg2avxzukkggrpb@kitenet.net/)

My rough summary: given there is no known second-preimage attack on SHA1, this
is not an immediate danger to Git security because of the way Git works. The
Git developers do want to move to a non-SHA1 hash at some point in the future.

Linus, from thread:

"I think that's a no-brainer, and we do want to have a path to eventually move
towards SHA3-256 or whatever.

But I'm very definitely arguing that the current attack doesn't actually sound
like it really even _matters_, because it should be so easy to mitigate
against."

------
rnhmjoj
About tor: if an attacker produces a public key that collides with the SHA-1
hash of someone else's hidden service, then he would still need to generate
the corresponding RSA-1024 private key, which is infeasible as of today.

Is this correct?

~~~
nabla9
The method presented works only with data formats where you can add section of
'calculated junk' into the data.

Public key can't contain junk and work, so I don't see how this method would
work.

------
orasis
" Today, 10 years after of SHA-1 was first introduced, we are announcing the
first practical technique for generating a collision."

Huh? It's been around a lot longer than 10 years.

~~~
alephnil
SSL 3.0 uses it, and that was released in 1996, and sha-1 was released in 1995
as an improvment over md5 and sha-0. This means it is 22 years old.

------
userbinator
It's interesting to note that when the first MD5 collisions were discovered a
bit over a decade ago, they were computed _by hand calculation_. Next came the
collision generators like HashClash/fastcoll (remember these?) which could
generate colliding MD5 blocks within a few _seconds_ on hardware of the time.
I wonder how long it will be before the same can be done for SHA-1, because it
seems here that they "simply" spent a large amount of computing power to
generate the collision, but I'm hopeful that will be reduced very soon.

As for what I think in general about it: I'm not concerned, worried, or even
scared about the effects. If anything, inelegance of brute-force aside, I
think there's something very _beautiful_ and awe-inspiring in this discovery,
like solving a puzzle or maths conjecture that has remained unsolved for many
years.

I remember when I first heard about MD5 and hash functions in general, and
thinking "it's completely deterministic. The operations don't look like they
would be irreversible. There's just so many of them. It's only a matter of
time before someone figures it out." Then, years later, it happened. It's an
interesting feeling, especially since I used to crack softwares' registration
key schemes which often resembled hash functions, and "reversing" the
algorithms (basically a preimage attack) was simply a matter of time and
careful thought.

There's still no practical preimage for MD5, but given enough time and
interest... although I will vaguely guess that finding SHA-256 collisions
probably has a higher priority to those interested.

------
Asdfbla
Maybe just writing 2^63 would have been easier to interpret than that huge
number in the context of cryptography. (Unless you assume this targets a non-
technical audience, which I doubt.)

Pretty impressive, though. And worrying, because if Google can do it, you know
that state-level actors have been probably doing it for some time now (if only
by throwing even more computing power at the problem).

------
manwithaplan
Seeing how they ridicule MD5, I think they should have spent a bit more time
on the proof PDFs, and have their MD5 digests collide also.

~~~
danielweber
No, that's irrelevant. You don't hold off showing the first SHA-1 collision to
have it have MD5 collisions as well.

I don't think anyone in the field is surprised that the MD5 signatures are
different for this file.

------
sah2ed
> _" Today, 10 years after of SHA-1 was first introduced, ..."_

That part from the original article seems to be missing something?

~~~
stiaje
It must be supposed to say 10 years after first known collision of SHA-1 or
something.

------
jwilk
> How did you leverage the PDF format for this attack?

> A picture is worth a thousand words, so here it is.

>
> [http://shattered.io/static/pdf_format.png](http://shattered.io/static/pdf_format.png)

This picture is meaningless to me. Can someone explain what's going on?

~~~
refulgentis
One can insert arbitrary data into JPGs. Given that, the researchers embedded
a JPG in a PDF, and manipulated the arbitrary data until it resulted in a
collision.

~~~
jwilk
Sure, but you don't end up with two images that differ only in background of
top half by accident...

------
SadWebDeveloper
It's still quite impractical, m sure with some quantum computer or a custom
ASIC built by those "super nerds" at the NSA its possible but but for you
general adversary aka "hackers" (skiddies IMHO) it will be infeasible.

What this means is for all of you [developers], is to start new projects
without SHA1 and plan on migrating old ones (if it's totally necessary,
normally don't unless you use SHA1 for passwords).

A Great resource for those who still don't know how or what hash to use, is
paragonie: [https://paragonie.com/blog/2016/02/how-safely-store-
password...](https://paragonie.com/blog/2016/02/how-safely-store-password-
in-2016)

------
mrb
Related: someone claimed a 2.48 BTC (~2800 USD) bounty by using this SHA1
collision data:
[https://news.ycombinator.com/item?id=13714987](https://news.ycombinator.com/item?id=13714987)

------
ktta
Here's a good blog about how SHA-1 works:

[http://www.metamorphosite.com/one-way-hash-encryption-
sha1-d...](http://www.metamorphosite.com/one-way-hash-encryption-sha1-d..).

The biggest risk I see with this is how torrents are affected:

[https://en.wikipedia.org/wiki/Torrent_poisoning](https://en.wikipedia.org/wiki/Torrent_poisoning)

There's also a problem with git, but I don't see it being that as susceptible
as torrents:

[http://stackoverflow.com/a/34599081/6448137](http://stackoverflow.com/a/34599081/6448137)

~~~
rocqua
What about git?

This makes it technically possible to get a backdoored linux repo with the
same commit hash.

EDIT: this is wrong, it's not a second pre-image attack only a collision
attack. That is, you can create 2 git repositories with the same commit hash,
but not a git repo that matches an already existing repo. In other words, you
can create 2 things with the same hash, but can't control what that hash
actually is.

You might be able to fashion 2 commits to the linux repo with the same hash
but a different modification though.

~~~
rntz
EDIT: My original comment was wrong. Git commit signing apparently only signs
the commit hash itself, so it's only as trustworthy as the integrity of the
hash. However, see also other comments which point out that this isn't a pre-
image attack; you can't find a collision _for_ a given thing (in this case,
the linux kernel); rather, you can generate from scratch two pieces of data
which happen to collide. Still, this is worrying.

ORIGINALLY (INCORRECT): Git commit hashes were at least never intended as a
form of authentication. That's why git has commit signing. That said, they
list GPG signatures as one of the things affected by SHA1 brokenness, so maybe
even that's not enough? I don't know enough about how git commit signing or
GPG works to tell.

~~~
nabla9
>git has commit signing

What the commit actually signs? Is it the sha1 hash?

~~~
scrollaway
The commit object is signed; which contains a signature to both the tree _and_
the parent. I don't see it as feasible to do a collision on both at once with
the method outlined here, but maybe I'm missing something.

Tagging on the other hand is at risk, as it's just the hash that's signed.

Edit: You can check what is actually signed with `git cat-file -p $obj` where
$obj is a commit or tag id.

~~~
mikegerwitz
You could also find a preimage for any tree or blob object referenced by that
commit. And in large projects, you have a lot to choose from.

(As has been stated, I know this isn't a second preimage attack.)

Edit: See my answers in this thread: [https://lists.gnu.org/archive/html/bug-
guix/2016-06/msg00009...](https://lists.gnu.org/archive/html/bug-
guix/2016-06/msg00009.html)

------
zurn
Anyone have back of the envelope calculations for the cost of the CPU and GPU
time?

~~~
nickez
On the shattered webpage:

This attack required over 9,223,372,036,854,775,808 SHA1 computations. This
took the equivalent processing power as 6,500 years of single-CPU computations
and 110 years of single-GPU computations.

~~~
cphoover
So... you are saying I couldn't do this on my Macbook's Core i7?

~~~
adrianN
If you're very careful with your machine maybe you can make it last 6500
years, but I think that is way outside the expected lifetime of a mobile CPU
under full load.

------
divbit
So good timing to have just started working on a sha3 version of git I
guess...

~~~
VMG
Funny, just yesterday I thought about what would be necessary to change and
deploy this. Apparently the SHA1 hash wasn't designed as a security feature,
but I would not be surprised if it is being abused as one today.

~~~
daenney
It's not used as a security feature in Git (though SHA-1 is designed as a
cryptographically secure hash) but Git commit singing does use SHA-1 b/c GPG.

~~~
VMG
It's not supposed to be used as a security feature, but I think some tools use
it as such. Dependency management tools that reference by SHA-1 hash come to
mind. Of course they should have used other primitives all along, but we know
how it is..

------
yeukhon
How do you actually create a collision? The paper is beyond my level of
comprehensions. Are we going to see someone writing up an open source tool to
allow one to generate another file with the same hash?

------
tjbiddle
It should also be noted that their examples files also have the same file
size, in this case 422435 bits, after creating the collision - which I find
fascinating!

------
wfunction
It's kind of odd that over 9 months ago it was known that Microsoft would stop
honoring SHA-1 certificates starting from 1 week ago. Anyone know if this is
just a pure coincidence? See
[https://blogs.windows.com/msedgedev/2016/04/29/sha1-deprecat...](https://blogs.windows.com/msedgedev/2016/04/29/sha1-deprecation-
roadmap/)

~~~
johnsmith21006
Not following on MS?

------
polynomial
It appears they are using a 2^63 hash operation attack that has been well
known for nearly a decade. (Brute force of SHA-1 is 2^69.)

I wonder why they did not use the 2^52 operation attack that Schneier noted in
2009?

[https://www.schneier.com/blog/archives/2009/06/ever_better_c...](https://www.schneier.com/blog/archives/2009/06/ever_better_cry.html)

------
ratstew
I got a chuckle out of the binary diff. :)

[http://i.imgur.com/OmFHELl.png](http://i.imgur.com/OmFHELl.png)

~~~
jdormit
Why?

[Edit] Just saw it. This is why I shouldn't read HN on my phone.

~~~
cdelsolar
i don't get it

~~~
jdormit
If you look at the textual representation of the hex sequences, you can find
the string "SHA-1 is dead!!!!!".

------
mysterydip
Forgive my ignorance, but it seems a solution to collision worries is to just
use two hashing algorithms instead of one. We have two factor authentication
for logins, why not the equivalent for hashed things?

Give me the sha1 and md5, rather than one or the other. Am I wrong in thinking
even if one or both are broken individually, having both broken for the same
data is an order of magnitude more complex?

~~~
pornel
You're effectively creating a new hashing algorithm, which is twice as long
and twice as slow, and is built using constructs known to be weak.

~~~
mysterydip
Thanks, that makes sense.

------
Aissen
Anyone good enough in AWS pricing can reproduce the $100k pricing for one
collision ? Using EC2 g2.xlarge instances I'm more at $2.8M.

~~~
bbarn
This would still be just an average, right? Isn't it 0$ to $2.8M depending on
luck?

~~~
Aissen
I don't think that's how averages work. But it's true that relying on the
birthday paradox, you can reduce the average. I was just trying to compute the
"cloud" cost of 110 GPUs for 1 year (or the equivalent for a day, assuming
this is embarrassingly parallel).

------
bch
I wish there were sample documents, but if one had two computed hashes would
this mitigate this SHA1-shattered flaw ? e.g. good_doc.pdf
sha1=da39a3ee5e6b4b0d3255bfef95601890afd80709,
md5=d41d8cd98f00b204e9800998ecf8427e ? With the sample project I'm looking at
(GraphicsMagick) on Sourceforge for example, it provides both SHA-1 and MD5
hashes...

~~~
fletom
Why would you ever want to add a second broken hash like MD5 instead of just
using a single secure function like SHA2, SHA3, or BLAKE2?

~~~
bch
Only for the case like I mentioned (SourceForge example above) of verifying
payloads that only ship with those two broken hashes. Not advocating for
publishing new work like this.

------
jqueryin
What's funny is Google still promotes SHA-1 in some of their APIs:
[https://developers.google.com/admin-
sdk/directory/v1/guides/...](https://developers.google.com/admin-
sdk/directory/v1/guides/manage-users)

------
imron
I wonder if there are any 2 single commits on Github from different
repositories that have the same SHA1 hash.

~~~
bjornsing
If there was, then _that_ would have been the first SHA-1 collision, right? ;P

~~~
imron
Yes, but is anyone looking?

------
RyanZAG
Is a 30 day disclosure period really enough for something like this? It's
obviously not possible to 'fix' big systems that rely on SHA-1 such as git or
github in only 30 days. Hardware devices that use SHA-1 as a base for
authenticating firmware updates?

~~~
gcp
SHA1 was shown to be flawed in 2005. That's more than 30 days ago.

~~~
hvidgaard
Saying it was shown to be flawed is being nice. It was outright broken 12
years ago as it was shown that you could find collisions with far less
complexity that a bruteforce attack.

What has happened is that someone created the code to actually carry out an
attack, and showed that it will cost around $110K today.

------
bobbyyankou
Can someone help me understand what the major distinction is between this
accomplishment (SHAttered) and the same team's The SHAppening (2015)?

It looks like the did the same thing or something similar in 2^57.5 SHA1
calculations back then versus 2^63 SHA1 calculations this time.

~~~
detaro
SHAppening was a freestart collision, this is a "full" one. This stack
overflow answer looks like a good description of freestart collisions:
[https://crypto.stackexchange.com/questions/29695/what-is-
a-f...](https://crypto.stackexchange.com/questions/29695/what-is-a-freestart-
collision)

My attempt at TL;DR: SHA-1 works on blocks, and each block is processed and
it's data "mixed" with a previous intermediate result based on the previous
blocks (Merkle-Damgård construction). A freestart collision only shows blocks
and values for the intermediate results which lead to a collision. For a full
collision you still have to figure out what sequence of blocks gets the
intermediate results to the necessary values.

~~~
bobbyyankou
Ah, cool. I didn't notice the distinction between freestart and full. Thanks
for that link; it was very helpful.

------
mrybczyn
SHA-1 isn't broken until someone makes a multi step quine that hashes to the
same value at every stage!

BTW quine relay is impressive: [https://github.com/mame/quine-
relay](https://github.com/mame/quine-relay)

------
ianaphysicist
This is one of the reasons it is important to have multiple hash algorithms in
use. Even when a collision can be triggered in two systems, it becomes
markedly harder to trigger a simultaneous collision in other systems at that
same point (payload).

------
icedchai
> "10 years after of SHA-1 was first introduced"

wasn't SHA-1 introduced in the 90's?

~~~
kzrdude
Git was released in 2005, 12 years ago, and it's based around SHA-1. They've
done a massive miscalculation there.

~~~
bb88
OTOH, 12 years of reliability from a checksum in the age of Moore's law and
quantum computers is pretty good, frankly.

I don't think they ever expected sha-1 to survive forever.

~~~
kzrdude
Sure.

In fact I intended to refer to the 10 year figure as massive miscalculation
here.

Even the simplest messages have ambiguity.

------
wickedlogic
Would providing multiple SHA-1's from both the whole and N subsections (or
defined regions) of the byte stream make this impractical... or at this point
is the cost just going to drop and make this not relevant?

Like a NURBS based sudoku multi-hash...

------
goncalomb
[https://security.googleblog.com](https://security.googleblog.com) : "This
website uses a weak security configuration (SHA-1 signatures), so your
connection may not be private."

~~~
pfg
I get a SHA256 certificate for that site. What user agent are you using? Is
there some kind of middlebox on your network, or do you use AV software that
intercepts TLS connections?

~~~
goncalomb
Fair enough, I was using Chrome "Version 50.0.2661.102 (64-bit)" on Linux
Mint. I have updated it to 56.0.2924.87, now I'm getting a full error page
"Your connection is not private" NET::ERR_CERT_WEAK_SIGNATURE_ALGORITHM. I
need to search for this issue now.

No I'm not using anything that intercepts TLS connections.

EDIT: It's fixed now, `sudo apt-get install libnss3-1d`.

[http://askubuntu.com/questions/880695/neterr-cert-weak-
signa...](http://askubuntu.com/questions/880695/neterr-cert-weak-signature-
algorithm-error-for-google-chrome-stable-version)

------
kyleblarson
What's the over/under on how long ago the NSA accomplished this?

------
0xcde4c3db
If you trust a signer, does this attack do anything to invalidate their
SHA-1-based signatures? Or is the scenario strictly an attacker generating
both versions of the message?

~~~
Ajedi32
As I understand it the attacker would have to generate both versions of the
message. If an attacker could generate a second message with a hash that
matches that of an existing message from a third party, that would be a
second-preimage attack, not merely a collision attack.

Even MD5 is still considered to be second-preimage resistant:
[http://crypto.stackexchange.com/q/3441/21238](http://crypto.stackexchange.com/q/3441/21238)

------
rodionos
The changes will be massive:

[https://github.com/search?utf8=%E2%9C%93&q=sha-1](https://github.com/search?utf8=%E2%9C%93&q=sha-1)

------
e0m
10 million GPUs is not insane when you have a billion dollar security cracking
infrastructure budget. Especially when you compare it to the rest of the cyber
warfare budget.

------
jmartinpetersen
Is it coincidental that this GPUs on Compute Enginge were announced recently?
This seems like a nice burn-in test and it being completed should free up
ressources.

------
RealNeatoDude
> Google has advocated the deprecation of SHA-1 for many years, particularly
> when it comes to signing TLS certificates.

Why? Was it in anticipation of this attack specifically?

------
Siecje
Is Mercurial impacted?

~~~
tonfa
Yes, as it uses a similar hashing scheme as git. [https://www.mercurial-
scm.org/wiki/FAQ#FAQ.2FTechnicalDetail...](https://www.mercurial-
scm.org/wiki/FAQ#FAQ.2FTechnicalDetails.What_about_hash_collisions.3F_What_about_weaknesses_in_SHA1.3F)

That said the file format was switched pretty early on (2006 I think, less
than a year after initial release) to reserve space for 32 bytes instead of 20
for the hash, thus allowing hash migration more easily (sha1 is 20 bytes, sha2
which at the time was the obvious replacement was 32 bytes).
[https://www.mercurial-scm.org/wiki/RevlogNG](https://www.mercurial-
scm.org/wiki/RevlogNG)

~~~
glandium
Except all exchanges between mercurial client and server happen with
changegroups and changegroups are still limited to 20 bytes for the hash.

------
wapz
I don't know too much about hashing/encryption, but if you salt the sha-1 will
this still be able to find a collision?

------
macawfish
So is this why Google asked me to type in my password this afternoon? Cause I
was kinda cautious about that, but still did it...

------
donatj
So from a security standpoint if my hash was a sha-1 concatenated to an MD5,
how long would it be before they found a collision?

~~~
yuhong
I believe there is a way to do it so that the MD5 collision would only be
2^64. This is also how MD5 collisions can be created without any special
techniques, meaning that MD5 was always only barely more secure than 56-bit
DES for example.

------
pix64
Is there any merit to using two hashing algorithms simultaneously particularly
if the algorithms are very different in nature?

------
Lord_Yoda
As I consumer how do I identify sites which are vulnerable? What should I do
to protect my data?

~~~
pfg
Recent versions of Chrome will show a warning if you try to browse to a site
that uses a SHA-1 certificate. Mozilla is doing the same thing as of Firefox
51, but they're enabling this gradually to measure impact. Microsoft has an
update ready to disable SHA-1 support in their browsers - I think it was
delayed a few days ago due to some issues (not sure if they were related to
disabling SHA-1).

You can use [1] to test how your browser behaves.

Technically, the sites cannot be said to be vulnerable because of their SHA-1
usage. Rather, continuing issuance of SHA-1 certificates by publicly-trusted
CAs increases the risk that someone obtains a certificate that collides with a
certificate for a different domain or for a certificate that could be used to
sign other certificates for sites the attacker does not own. [2] does a good
job of explaining this. The mitigation for this is to use a browser that
disables (or warns about) SHA-1 certificates. Publicly-trusted CAs are also
not supposed to continue issuing these certificates, but there have been quite
a number of cases where they did so anyway - most notably WoSign.

Of course, a site might use SHA-1 for other things behind the scenes. There's
really no way to detect that in general.

[1]: [https://sha1-2017.badssl.com/](https://sha1-2017.badssl.com/)

[2]:
[https://news.ycombinator.com/item?id=13715717](https://news.ycombinator.com/item?id=13715717)

~~~
jwilk
> [https://sha1-2017.badssl.com/](https://sha1-2017.badssl.com/)

This certificate has expired, so it's not that useful for testing.

------
nurettin
"as google, we spent two years to research a way of generating sha-1
collisions and made quintillions of computations to generate an example" <\-
not very convincing or practical. It's like those japanese animes where the
nerdy kid boasts about having computed your every move.

------
madhorse
"But MD5 is still okay right?" -Laravel Developer

~~~
frankquist
This comment does not really add much of anything. Besides that, Laravel uses
Bcrypt for hashing. Not sure where Laravel developers use MD5.

------
kazinator
> _In practice, collisions should never occur for secure hash functions._

That is mathematically impossible when reducing an N bit string to an M bit
string, where N > M.

All hashes have collisions; it's just how hard are they to find.

~~~
jwilk
They said "in practice" for a reason.

------
Zhenya
It's telling/ironic that the google security blog will not display the text
without javascript enabled.

------
bekimdisha
but ... but .... half of the web is no longer secure? ... :D

------
necessity
> If you use Chrome, you will be automatically protected from insecure TLS/SSL
> certificates, and Firefox has this feature planned for early 2017.

No need to wait. The option to reject SHA-1 certificates on Firefox is
`security.pki.sha1_enforcement_level` with value `1`.

[https://blog.mozilla.org/security/2016/01/06/man-in-the-
midd...](https://blog.mozilla.org/security/2016/01/06/man-in-the-middle-
interfering-with-increased-security/)

Other configs worth doing:

`security.ssl.treat_unsafe_negotiation_as_broken` to `true` and
`security.ssl.require_safe_negotiation` to `true` also. Refusing insecure
algorithms (`security.ssl3.<alg>`) might also be smart.

~~~
gajjanag
Excellent.

More generally, there is this fantastic repo on github that lists a bunch of
such things that can be tweaked in about:config (mostly from a
security/privacy standpoint):
[https://github.com/pyllyukko/user.js](https://github.com/pyllyukko/user.js)

------
mtgx
Never forget: when Facebook, Twitter, and Cloudflare tried to slow-down SHA-1
deprecation:

[https://www.facebook.com/notes/alex-stamos/the-
sha-1-sunset/...](https://www.facebook.com/notes/alex-stamos/the-
sha-1-sunset/10153782990367929)

[https://blog.twitter.com/2015/sunsetting-
sha-1](https://blog.twitter.com/2015/sunsetting-sha-1)

[https://blog.cloudflare.com/sha-1-deprecation-no-browser-
lef...](https://blog.cloudflare.com/sha-1-deprecation-no-browser-left-behind/)

I think Microsoft tried to do it too early on, but eventually agreed to a more
aggressive timeline.

~~~
pfg
Worth noting that Facebook stopped offering SHA-1 back in November[1].
Cloudflare still offers SHA-1 for paying customers (via a root certificate
pulled from trust stores, i.e. which are only supported on outdated
devices/browsers). Not sure about Twitter.

[1]: [https://www.facebook.com/notes/protect-the-graph/retiring-
sh...](https://www.facebook.com/notes/protect-the-graph/retiring-
sha-1-certificates/1814716098768533)

------
dingo_bat
> Hash functions compress large amounts of data into a small message digest.

My understanding of crypto concepts is very limited, but isn't this
inaccurate? Hash functions do not compress anything.

They have an image too which says "<big number> SHA-1 compressions performed".

Seems weird to see basic mistakes in a research disclosure.

~~~
kevinnk
[https://en.m.wikipedia.org/wiki/One-
way_compression_function](https://en.m.wikipedia.org/wiki/One-
way_compression_function)

Cryptographic compression is not related to data compression.

------
pavfarb
Now I really wonder what will happen to Git we all know and love.

~~~
bbcbasic
Nothing: the risk of a fucked up rebase is still much higher than a hash
collision.

~~~
pavfarb
If we think that intentional collision is not a threat vector, while, as life
shows, it is:
[https://bugs.webkit.org/show_bug.cgi?id=168774#c23](https://bugs.webkit.org/show_bug.cgi?id=168774#c23)

------
yuhong
identical prefix, not chosen prefix. I was more interested in an SHA-1
collision ASIC.

