Are SHA1 magnet links too weak for Bitcoin Core?

[harding]

The current magnet link on Bitcoin.org for 0.10.2 starts with,

magnet:?xt=urn:btih:746a616aa8de97856c207e7a899c7ee315e8c44d

The value of the BTIH parameter is a SHA1 hash according to Wikipedia. According to a 2012 analysis reposted by Bruce Schneier, the estimated maximum cost of breaking SHA1 using the Amazon EC2 cloud would be $700K by 2015.

I don't know the details of how BitTorrent clients handle magnet links and the BitTorrent DHT, but it seems plausible to me that someone could create an alternative torrent with malicious Bitcoin Core binaries and the same hash for that $700K maximum cost.

That's mildly worrisome. Mildly because I don't think there are currently enough high-value users of stock Bitcoin Core who both (1) use the magnet and (2) don't bother to verify the binaries. Presumably, economically-rational attackers won't fork out the $700K maximum.

Perhaps more importantly, I highly doubt Bitcoin.org is any safer against an attacker willing to spend $700K.

However, the number of people who match those criteria that may increase over time if we continue to promote the magnet links at the same time the cost of the attack is decreasing as computers get faster. The same linked analysis predicts costs of:

• ~ $173K by 2018
• ~ $43K by 2021

(And that doesn't count the SHA1 extensions being built into newer CPUs, or if someone decides to build a FPGA or ASIC dedicated to the task.)

Although I don't think we have to worry about an attack on the magnet URN at present, I'm uncomfortable depending on weak cryptography. Since I don't believe that many people currently use the magnet link to download Bitcoin Core, I think that we should discontinue publishing it at the next 0.10.x or 0.11.0 release.

What do ya'll think?

P.S.: in discussing this on #bitcoin-dev, @luke-jr brought up the fact that git depends on SHA1 hashes as well. Here's a link quoting Linus about why that's not a problem (for people with existing repositories, at least).

[gmaxwell]

It's important to not use or think in terms of "breaking $hashfunction". By itself "breaking" is meaningless because the hash function does multiple things.

I think as a result this is applying the costs of a collision to the consequence of finding a second pre-image. A collision would be that evil developers conspire to create a pair of releases A and A' which have the same hash. A second preimage would be that an attacker, Mallory, produces some compromised A' release which has the same has as given release A that we've put out. Collisions are fundamentally cheaper (half the bits of security, or less) owing to the fact that you can make many targets for each side and only need to find one pair-- but also far more limited in their effects.

I think we know objectively that almost no users verify the binaries. This is a much bigger problem then worrying that a particular scheme might be economically vulnerable to forgeries due to the use of SHA1.

[harding]

@gmaxwell oh, indeed. I was thinking of the cheap cost of the collision attack rather than the much higher cost of the preimage attack. Now I feel dumb. (But thanks for replying!)

Closing.