Embedding SHA256 inside SHA1 for BitTorrent

Question

BitTorrent uses SHA1 for its hashes, but SHA1 is unsafe and people can tamper the preimage and still obtain the same hash, right?

So imagine I want to be very sure the file I'm sharing on BitTorrent will be correctly downloaded by who is downloading it. Does it work to include 2 files, being:

1. The file I'm actually sharing;
2. A file containing the SHA256 of the file I'm sharing.

Then the receiver must just check if the SHA256 matches (plus check if the SHA1 matches, which will be done automatically by the BitTorrent client).

Answer 1

The problem with SHA-1 is the collision attack that way before the actual attack shattered.io NIST dropped it in 2011 from digital signatures since finding collision has catastrophic result in Digital Signatures. The generic collision of SHA-1 requires 280$2^{80}$-time and that was considered low for 2011 and beyond. The Rabin was the one first to use the hash ( it was then called compression) to prove the security of their signature scheme that we call now the Rabin Signature Scheme. SHA-1 is still allowed by NIST for for using non-digital-signature applications as Acceptable status in 2019, NIST.SP.800-131Ar2

BitTorrent uses SHA1 for its hashes, but SHA1 is unsafe and people can tamper the preimage and still obtain the same hash, right?

That is not the pre-image attack that is given a hash value h=H(m)$h=H(m)$ for some message m$m$ find a pre-image x$x$ of the hash function H$H$ so that h=H(x)$h=H(x)$. We can have m=x$m=x$ or not. Equality is not required from the pre-image attack by definition. As one can see, this is very helpful for password cracking, it doesn't matter you have found the same password or not since both are working. There is no pre-image attack on SHA-1 better than the generic pre-image attack and that still requires 2180$2^{180}$-time.

What you have tried is the second-preimage attack that is given a message m$m$ and its hash values h=H(m)$h=H(m)$ find another m′$m^{\prime }$ such that h=H(m′)$h=H(m^{\prime })$. SHA-1 has no second-preimage attack that faster than the generic pre-image attack and the cost of the generic second-preimage attack is 2160$2^{160}$-time for SHA-1.

Tampering one-bit arbitrary you will get 1/2180$1/2^{180}$ probability that has the tampered files same hash if we consider the output of the SHA-1 as uniform random.

Finding second pre-images is very dangerous. For example; one can design a new malicious IOS for the existing ISO and replace it. There is a problem here on the BitTorrent network that is many people share the same file and this will create conflict on the IOS that people downloaded. Therefore for an active download, it may not possible. For a new download, if the attackers are fast on finding the second-preimage attack, then they may replace the original copy before distribution, too IFs, right?

So imagine I want to be very sure the file I'm sharing on BitTorrent will be correctly downloaded by who is downloading it. Does it work to include 2 files, being:

The file I'm actually sharing; A file containing the SHA256 of the file I'm sharing. Then the receiver must just check if the SHA256 matches (plus check if the SHA1 matches, which will be done automatically by the BitTorrent client).

SHA256 calculation is free since it has no key. The IF attacker can still calculate the malicious ISO and their SHA256 hash and store as you did.

Risk Management

The usage of the SHA-1 really depends on risk management. For example, Git still uses SHA-1 and Linus has a clear reason for this;

Git does not require the second preimage resistance of SHA-1 as a security feature, since it will always prefer to keep the earliest version of an object in case of collision, preventing an attacker from surreptitiously overwriting files.

Now what about BitTorrent

BitTorrent divided files into 64 KB – 2 MB chunks. The torrent's metadata file (.torrent file) stores each piece's size and hash value. Together with the info_hash that store makes BitTorrent quite resistant to intentional tampering (poisoning). To verify the chunks SHA-1 is used the value in the info_hash.

There is research on this;

Adaptive Content Poisoning To Prevent Illegal File Distribution in P2P Networks*

We discover that BitTorrent is most resistant to content poisoning.
....
Because the index file is distributed outside of the P2P file-sharing system, each chunk can be verified with a reliable hash contained in the metadata. This verification provides BitTorrent protocol with high resistance to content poisoning.

There is also a long talk about this problem on the GitHub of the Bittorent; In short, if you trust the host that shares the .torrent file, you are safe.

Answer 2

No, they can only tamper the pre-image if they previously inserted a known week message. It is possible to pre-calculate two (or more) messages so that they have the same hash, i.e. a collision. It is also possible to simply use two known files with the same SHA-1, such as the PDF documents from the SHAttered attack. Then they could execute specific actions depending on the document that was used.

Sharing a hash only makes sense if that shared hash can be trusted with the receiver. Hosting it next to the data makes no sense. If you see such a hash on sites then the hash has two functions: making sure that the file was fully & correctly downloaded and making sure that the file is correct when downloaded from a less trusted mirror. To solve this using cryptography you'd use a signature, verified by the public key in a certificate that is trusted in advance (e.g. by verifying / validating a certificate chain).

It seems bittorrent distributes the hash outside of the torrents itself. This makes it invulnerable to changes during distribution by torrent nodes, but it won't completely avoid distributing two different / precalculated files with the same hash it seems to me. In that sense a separate hash over the entire file may indeed be helpful, as the attack certainly won't work against SHA-256.