Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

BitTorrent v2

blog.libtorrent.org

Post reply on HN
Print view View original

211–220 of 576 posts

Re: BitTorrent v2

#211

Post by sedatk »

smabie wrote: post #3

I've written a torrent client, and I'm skeptical than v2 will ever catch on. While it does solve some minor problems, it's not a large enough leap forward to justify the costs.

Minor problems? Isn't this a security issue? Somebody can modify a binary and still have it return the same hash and distribute it to people who think that they are receiving an authentic file. Is it even an option to keep going with SHA1? Even Git, which this is less of an issue, has a plan for migrating to SHA2. https://git-scm.com/docs/hash-function-transition/

Re: BitTorrent v2

#212

Post by Red_Leaves_Flyy »

k__ wrote: post #201
joenathanone wrote: post #147

Earlier quoted context omitted.

It should, but in practice it doesn't. I've had torrents that I left sitting for weeks not being able to complete, until I added a list of trackers to them and found some seeders with 100% of the torrent.

Same here. BT only worked for new popular stuff.

I've yet to find something that's truly unavailable. Sometimes it takes a few different searches on different sites but I've always found the obscure Linux distros I've been looking for.

Re: BitTorrent v2

#213

Post by throwaway2048 »

kardos wrote: post #58
proverbialbunny wrote: post #25

It feels like this isn't a large enough leap forward. It would be nice if BitTorrent v2 made it harder for ISPs to identify what is bit torrent traffic. AT&T artificially slows down upload speeds.

> It feels like this isn't a large enough leap forward. The hash it relies on is broken, so their hand has been forced.

sha1 is not meaningfully broken for BitTorrent, It would require a second pre-image attack to meaningfully hurt it, you can not take an existing hash you don't control and synthesize a matching set of incorrect/malicious data.

Second preimage attacks are MUCH harder to pull off, even md5 is still safe from them, many years after they were found to be broken in other contexts.

The only thing that sha1's weakness would let you do in a bittorrent context is create a torrent, then let you send fake data for a chunk, which really does not seem very useful, because you could just make the data malicious when you created the torrent.

Re: BitTorrent v2

#214

Post by Red_Leaves_Flyy »

bserge wrote: post #143
wmf wrote: post #138

Earlier quoted context omitted.

Wait until you hear how much CPU time and RAM is being wasted...

It's actually the reverse that bothers me in that case! I have more RAM and CPU time than I can possibly use :D Unless that's what you meant...

I think what they're getting is how bloated software has become. Some websites download several megabytes of data to display a kilobyte or less of actual content.

Re: BitTorrent v2

#215

Post by tomxor »

> not only uses a hash tree, but it forms a hash tree for every file in the torrent [...]

> Files that are identical can also more easily be identified across different swarms, since their root hash only depends on the content of the file.

Wait, content addressed blobs across swarms... does that mean torrents made by completely different people at different times that happen to contain one or more identical files can benefit from each other's peers? If so this feels like a significant feature that would boost the long term health of a lot of torrents and connect more peers that could be helping each other.

Re: BitTorrent v2

#216

Post by throwaway2048 »

sedatk wrote: post #211
smabie wrote: post #3

I've written a torrent client, and I'm skeptical than v2 will ever catch on. While it does solve some minor problems, it's not a large enough leap forward to justify the costs.

Minor problems? Isn't this a security issue? Somebody can modify a binary and still have it return the same hash and distribute it to people who think that they are receiving an authentic file. Is it even an option to keep going with SHA1? Even Git, which this is less of an issue, has a plan for migrating to SHA2. https://git-scm.com/docs/hash-function-transition/

This isn't really true, sha1's weakness would require you to be the creator of the torrent, which if you are, you can just make the binary malicious to begin with.

Re: BitTorrent v2

#217

Post by ficklepickle »

wmf wrote: post #100
p1mrx wrote: post #70

Earlier quoted context omitted.

You could have a protocol where every block of the file is actually two "random" blocks XOR'd together, but this doesn't really work. If you create a new 1GB torrent, you'll need 1GB of new (never seen before) blocks with ~100% probability, so it will be obvious who's seeding the data. Or you could make the block size smaller (e.g. 1 bit) and tell the lawyers to piss off because 0 and 1 are public domain.

See https://www.scs.stanford.edu/~dm/home/papers/waldman:tangler... and https://ansuz.sooke.bc.ca/entry/23

Off-topic meta discussion about that second link you posted. It is an example of a fourth-level municipal domain[0], which are a relic of the past internet. Sooke is a municipality on Vancouver Island.

Sadly, new domains of this sort were discontinued in 2010. A cool relic of the internet past and massive geek cred. I remember these URLs from my childhood and they make me very nostalgic.

[0] - https://en.wikipedia.org/wiki/.ca#Third-level_(provincial)_a...

Re: BitTorrent v2

#218

Post by StavrosK »

bawolff wrote: post #187
martinald wrote: post #175

Earlier quoted context omitted.

Really? It's a just an iteration from how eDonkey2000/eMule worked, which actually also had a DHT based 'trackeless' mode, many years before BT came around.

The tit-for-tat algorithm is what makes bit torrent special and solved a real problem with the previous gnutella-esque generation of p2p file sharing programs. As far as i know emule did not have that at the time.

How does tit-for-tat work? Is it still enabled? I don't think I've seen it much lately.

Re: BitTorrent v2

#219

Post by userbinator »

loeg wrote: post #179
frenchman99 wrote: post #80

Earlier quoted context omitted.

It isn't? Is it not possible to be tricked into downloading a malicious binary that you then execute on your computer?

I don't think so. 1. The user trusts the source of the .torrent file. 2. A malicious peer makes a preimage attack in some block in an executable file with contents containing some malicious executable payload. 3. The executable wasn't signed, or the targeted block must include executable headers. 4. Some peers get the malicious exe, some don't. The (2) step is still hard — preimage attacks on SHA1 are still expensive…

Remember that for cryptographers, "practical" or "broken" doesn't really mean "everyone can do it", and AFAIK there has only been one publicly released collision pair for SHA1, which also took an enormous amount of time and money to find.

Even MD5, for which you can generate colliding blocks in seconds on an average PC, is still quite resistant to preimage attacks.

In other words, even after spending the resources to find a colliding block, you'd also need to create both files with the same hash, and can't simply collide existing torrents' files and replace them with malicious ones.

Re: BitTorrent v2

#220

Post by bsder »

mac01021 wrote: post #33
proverbialbunny wrote: post #25

It feels like this isn't a large enough leap forward. It would be nice if BitTorrent v2 made it harder for ISPs to identify what is bit torrent traffic. AT&T artificially slows down upload speeds.

Why don't ISPs bill by the gigabyte and be done with it?

Because then people will get REALLY grouchy about ads.

In addition, it gives people a solid measure over which to sue you. If you aren't delivering, you're headed to court.

The ISPs like all the vagueness.

Post reply on HN