Home > Specs > BitTorrent
SHA-1 Problems In BitTorrent
Written by Kevin Hearn (kh@tixati.com)
Last update October 6, 2025
The original BitTorrent protocol uses the
SHA-1 hash algorithm for two important purposes. It ensures that the
info map is consistent among all the participants in a torrent. It also allows peers to check any piece for tampering or error.
The number of bits in an SHA-1 hash is 160 (20 bytes), and therefore it has 2^160 (2 to the power of 160) output possibilities.
A perfect hash function with 2^160 output possibilities would require hashing approximately 2^80 different strings to find any two that have the same result. Even with modern computing resources, this is not practical.
New Attacks Discovered
Recently, in the case of SHA-1, methods have been discovered to reduce the effort needed to find a random collision. Using these new methods would require less than 2^64 hash operations to find any two outputs that match. Using a very large number of GPUs, doing this many hash operations is possible in a matter of months or less. It has already been done twice, both times using the equivalent of approximately 110 GPU-years.
The first time was a
project by CWI and Google in 2017 that produced two different PDFs with the same SHA-1 hash. The second was a
project by Gaetan Leurent and Thomas Peyrin in 2019 that produced two different 640 byte sequences with the same SHA-1 hash.
It should be noted that this does not mean that it is possible to find a string that will produce a specifically chosen target hash. That would be vastly more difficult (near 2^160 hash operations) and will very likely never happen. It is only possible to find two random matches, due to the so-called
birthday paradox. This is a very important distinction.
BitTorrent Dangers
A torrent that was created by someone honest is still quite secure. It would be practically impossible to create an alternate piece with a hash that is identical to a chosen preexisting piece.
However, it is possible to create a torrent with two different versions of a piece that have the same hash, and then seed only the first one, and later seed the other. Both pieces would pass the hash-check. The data for both pieces would have to contain a small amount of random data that was continuously incremented in the process of searching for a collision.
In fact, it is already trivial to create torrents like this, simply by using data from already-discovered random collisions. Due to the nature of
SHA-1's construction, it is possible to append arbitrary data simultaneously to a pair of preexisting collision blocks (which are currently as short as 640 bytes) and still keep an identical hash between them. The two different collision blocks could be hidden in an unused data area of two otherwise identical copies of a program, image, document, or video file, as long as they line up at the beginning of a piece when creating the new torrent.
It is possible to take advantage of this to create a pair of files that would have identical piece hashes, but have different overall hashes or checksums, and in only one of the two cases fail an integrity or signature check. This could apply to signed software, where only one version passes as authentic, and the one poisoned by an alternate piece introduced after the torrent is well established does not pass. A more hostile scenario would be where the software checks itself to see if it is the poisoned version, and if so, does something malicious.
We have created an
example pair of shell scripts to demonstrate this. When made into a torrent, the two versions of the script are interchangeable. When one is run, we see a friendly message, when the other version is run, we see a more ominous message.
A solution to this problem is clearly needed. And it must be fully backward compatible and easy to implement in existing BitTorrent clients to be widely adopted.
A Way Forward
We have designed two very simple improvements to the BitTorrent protocol that solve these problems. It is very easy to incorporate these improvements into any BitTorrent implementation and they are fully backward compatible with older clients.
Protocol version 3 torrents have an extra key in the torrent info map that contains partial
SHA-2 or
SHA-3 piece hashes that compliment the standard SHA-1 piece hashes. This increases the difficulty of finding a piece hash collision to 2^80 or higher in exchange for only a very small increase in info map size. It also provides cryptographic agility. If the current algorithms are no longer adequate, other algorithms can be specified in the key.
Protocol version 3 also adds a very mild proof of work key to the info map, locked to the final info hash, to make it practically impossible to produce two info maps that have both the same identifying info hash and a valid proof of work. It is currently SHA-2 or SHA-3 based, but just like the new complimentary piece hashes, any algorithm can be specified.
These changes are fully backward compatible. An older client will ignore these extra keys in the info map and carry on as normal. A new client will understand the extra piece hashes key if it is present, and reject pieces that do not pass all hash checks. It can also check for the proof of work in the info map and reject it if it doesn't match the outer info hash. It could also indicate to the user if a torrent is missing these extra info keys and is a legacy v1.0 torrent.
Further Reading
https://tixati.com/specs/bittorrent/v3
https://tixati.com/specs/bittorrent/collision_demo
https://en.wikipedia.org/wiki/SHA-1
https://en.wikipedia.org/wiki/Birthday_attack
https://sha-mbles.github.io/
https://shattered.io/
https://en.wikipedia.org/wiki/Merkle%E2%80%93Damg%C3%A5rd_construction
https://en.wikipedia.org/wiki/SHA-2
https://en.wikipedia.org/wiki/SHA-3
