1. You create .torrent file from original content. The .torrent file contains crypto strong hashes of the original content.
2. You distribute .torrent file through website, mail or some other mechanism.
3. User's download content as described by .torrent file.
4. BitTorrent checks hashes in .torrent file.
The weak link here is step #2. User's don't have a strong guarantee that the .torrent file is the one you generated.
Note that this weakness is identical to direct download. Users do not have a strong guarantee that downloaded file named X is identical to the original file X.
You can make a stronger guarantee in the direct download case by using https, but the same holds true for distributing the .torrent file.
Just to be clear, you create the .torrent file containing the hashes and you distribute the .torrent file containing the hashes. The weak link is in the distribution and that weak link is identical to direct download.
By singling out this issue with BitTorrent, you lead readers to believe that this is a weakness of BitTorrent compared to direct download. There's a lot of FUD about p2p. It's sad to see that you are adding to it.
Showing messages 1 through 1 of 1.
Yes, but the problem is not specific to BitTorrent
2003-05-31 15:58:35
eggboard
[Reply | View]
You're reading the context wrong, and it is, in fact, different with direct download.
In the article, I cite the general problem as: "In peer-to-peer systems, however, you can't necessarily be sure that a given file is the same an author meant to upload, that the file has been vetted for viruses, or that each version of the file throughout a network is the same as every other file." Then I mention BitTorrent's method of crypto as a specific example of trying to solve one part of the problem that doesn't actually verify or vet the file. So that's a general-to-specific example, not a condemnation of BitT above other P2P.
Second, many sites do employ a variety of methods including MD5 and public key signing to ensure that a direct download is as promised. MD5, of course, only ensures that a file matches what's said on a Web site or in an email or newsgroup posting. If you use the methods recommended to obtain the verification of public keys used to sign downloads out of band (that is, not via a Web site or through email directly), then when you download a file, you can verify that the person or organization that you think created the file did, in fact, sign the file and it's been untampered with. (The cases in which this is a problem involve a lack of out-of-band confirmation of the public key, and so were more like just checksumming not ensuring integrity.)
So you're definitely RIGHT in that the problems are P2P based, but they're exacerbated by a distributed mechanism in that the "author" doesn't define where the downloaded file is authoritative from.
Obviously, a way to make this work better would be to tie in Web sites or subsites on a Web site that managed the crypto: signed files, etc., and have a streamlined method of obtaining keys or keys signed by other keys, so that any file in BitTorrent had to have some identity confirmed at the end of a chain, not just crypto hashing confirmation of the individual file.
It's definitely a global problem, but it's "solved" in the sense that sites like apache.org or sendmail.org use mechanisms that allow verification. If those files are then distributed through BitTorrent those same methods of verification work.
In the article, I cite the general problem as: "In peer-to-peer systems, however, you can't necessarily be sure that a given file is the same an author meant to upload, that the file has been vetted for viruses, or that each version of the file throughout a network is the same as every other file." Then I mention BitTorrent's method of crypto as a specific example of trying to solve one part of the problem that doesn't actually verify or vet the file. So that's a general-to-specific example, not a condemnation of BitT above other P2P.
Second, many sites do employ a variety of methods including MD5 and public key signing to ensure that a direct download is as promised. MD5, of course, only ensures that a file matches what's said on a Web site or in an email or newsgroup posting. If you use the methods recommended to obtain the verification of public keys used to sign downloads out of band (that is, not via a Web site or through email directly), then when you download a file, you can verify that the person or organization that you think created the file did, in fact, sign the file and it's been untampered with. (The cases in which this is a problem involve a lack of out-of-band confirmation of the public key, and so were more like just checksumming not ensuring integrity.)
So you're definitely RIGHT in that the problems are P2P based, but they're exacerbated by a distributed mechanism in that the "author" doesn't define where the downloaded file is authoritative from.
Obviously, a way to make this work better would be to tie in Web sites or subsites on a Web site that managed the crypto: signed files, etc., and have a streamlined method of obtaining keys or keys signed by other keys, so that any file in BitTorrent had to have some identity confirmed at the end of a chain, not just crypto hashing confirmation of the individual file.
It's definitely a global problem, but it's "solved" in the sense that sites like apache.org or sendmail.org use mechanisms that allow verification. If those files are then distributed through BitTorrent those same methods of verification work.