This is a ticket for discussion about the https://biterrant.io/ attack on bittorrent and possible eventual changes in the way we deliver files to our users.
The problem here being is that, once somebody comes up with an SHA1 collision for files in .torrent or our metadata, it could be used to deliver an .iso that doesn’t work and that counts as an attack in the current threat model. Currently, we don’t sign the .torrent file because it gets delivered over HTTPS, providing the “same security” as our website.
Things we consider:
- The merkle tree extension (BEP-30) isn’t widely implemented, so let’s not assume it’s used.
- An attacker that can deliver incorrent iso’s that don’t boot count as an attack. User might use something insecure instead.
- There doesn’t seem to be any good safeguards that are not defaults in most clients or in software like `mktorrent`. Like the merkle tree extension.
Playing devils advocate, Modifying files in the compression sounds complicated, but what about the metadata of the sha1 hashes of the files. If you find a collision in that will replace it with malicious metadata of malicious files, could that be pulled off?
To sum it up: There doesn’t seem to be any safe guards at the moment for a user to receive these iso’s in a secure and/or working manner. Meaning users could potentially end up with an malicious iso or an iso that doesn’t actually boots.
In January 2017, there were 101209 downloads of the .torrent file, in comparison, the amount of downloads of the OpenPGP signature is 14782.