[bittorrent] Why are blocks smaller than pieces?
ryanwalklin at gmail.com
Tue Sep 11 01:50:30 EDT 2007
I hadn't realised it was down that low. Hrm, I agree that eventually
computer power will make what you describe feasible.
However an effective defence against this is to force getting a piece from
multiple peers. This means even if malicious peers are supplying bad data
which would pass a hash, the combination of partial good and bad data would
still fail hashing. You can then ban peers based on this knowledge as I've
already described, and include the IP in a blocklist, eg by submitting it to
Certainly though, it is a weakness in the protocol. How practically
exploitable this is, I'm not sure, as you would both need to generate bad
data based on a collision, then get enough IPs seeding so that there was a
reasonable change of getting the peer being attacked to complete a piece
entirely composed of requests from bad peers.
The other point is that colliding data would have to be the same length as
the original block, ie for a torrent with 512 kb chunks, a 512kb length of
data with the same hash as one of the torrent pieces. I don't know a lot
about cryptography, but I can't find any reference to a collision
necessarily being the same length, which it would have to be to successfully
attack bittorrent using this code.
Another potential workaround is to include a comment containing the MD5 of
the entire download, or larger chunks in the torrent (outside the info
section so the infohash stays constant) so that paranoid clients can rehash
the file when the download is complete. The failed large chunks could then
be identified for redownload.
Interesting points though, and will probably need to be formally addressed
sooner or later. I'd really like to see any fixes being introduced in a
backwards-compatible way though.
On 9/11/07, Thad Ward <coderjoe at grnet.com> wrote:
> It appears that, as of August 17, 2005, we're down to a
> collision-finding complexity of 2^63. Yes, this is still rather high for
> the time being, but it will continue to go down with time.
> I think there are parties that would be interested in disrupting
> transfers by injecting incorrect data that couldn't be detected by the
> bittorrent protocol itself. Over time, doing so may get easier. They
> wouldn't have to generate collisions in realtime, just fast enough that
> they could bring seeds onto the swarm during the life of the swarm and
> send the incorrect data. Getting the blocks of a piece from different
> peers makes it harder for these malicious attacks to work, as you would
> need to have multiple peers with the same incorrect data and hope to get
> lucky enough to have peers download all the blocks from corrupt clients.
> Each time you do get lucky, though, you increase the group of corrupt
> clients, at least for that piece.
> For a good while, though, it probably is easier, in the case of illegal
> content anyway, to just get IPs and start suing. And really, this is the
> only case I see anyone willing to put in all the time and effort to
> corrupt a torrent, anyway...
> On Mon, Sep 10, 2007 at 06:53:27PM +1200, Ryan Walklin wrote:
> > I don't think that finding SHA1 collisions in 2^69 invalidate its use as
> > simple data verification system, and as long as the only attack remains
> > brute-force, surely it's computationally infeasible to generate bad data
> > that passes hash checking, regardless of whether the piece comes from a
> > single peer or multiple peers.
> > On 9/10/07, Olaf van der Spek <olafvdspek at gmail.com> wrote:
> > >
> > > On 9/10/07, Thad Ward <coderjoe at grnet.com> wrote:
> > > > The problem I see with this is that collisions on SHA1 are not that
> > > > off,
> BitTorrent mailing list
> BitTorrent at lists.ibiblio.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the BitTorrent