Comments on: BitTorrent peer list encryption http://rdist.root.org/2008/02/18/bittorrent-peer-list-encryption/ Embedded security, crypto, software protection Tue, 16 Mar 2010 03:16:39 +0000 http://wordpress.com/ hourly 1 By: Nate Lawson http://rdist.root.org/2008/02/18/bittorrent-peer-list-encryption/#comment-4458 Nate Lawson Tue, 26 Feb 2008 19:36:03 +0000 http://rdist.root.org/?p=109#comment-4458 ac, good idea. I was hoping that there would be more opportunistic encryption for legacy traffic, perhaps via growing VPN use, and thus all traffic would eventually be mixed and hard to differentiate. Your p2p game protocol could actually be unencrypted but transparently negotiate encryption for all TCP connections, including ones not part of the game itself. Having the game running would be all that was needed to start hiding a lot of unrelated traffic. There is one good point in all this. Despite protests by security people, naive ideas like IP-based authentication continue to be reintroduced since active MitM attacks don't commonly affect ordinary users. Now we all know you have to assume ever-present MitM and your ISP is just the first adopter. ac, good idea. I was hoping that there would be more opportunistic encryption for legacy traffic, perhaps via growing VPN use, and thus all traffic would eventually be mixed and hard to differentiate. Your p2p game protocol could actually be unencrypted but transparently negotiate encryption for all TCP connections, including ones not part of the game itself. Having the game running would be all that was needed to start hiding a lot of unrelated traffic.

There is one good point in all this. Despite protests by security people, naive ideas like IP-based authentication continue to be reintroduced since active MitM attacks don’t commonly affect ordinary users. Now we all know you have to assume ever-present MitM and your ISP is just the first adopter.

]]> By: ac http://rdist.root.org/2008/02/18/bittorrent-peer-list-encryption/#comment-4453 ac Sun, 24 Feb 2008 14:40:11 +0000 http://rdist.root.org/?p=109#comment-4453 Really the best way to combat this development is to go around it the other way: Develop "the new WoW" except that it's p2p based and requires symmetrical bandwidth. I've already theorized up this type of game from technical standpoint so that the cheating that might plague p2p game would not become an issue. Essentially a 3rd party peer would act as the 'server' for resolution of fight between two players (peer 1&2) and the 'server peer' would be decided on latency to peer 1&2 etc on the fly. Now if the encrypted game traffic gets dropped because it looks like torrent traffic then whoops ISP will get sued and go out of business due to word of mouth if they don't act. Really the best way to combat this development is to go around it the other way: Develop “the new WoW” except that it’s p2p based and requires symmetrical bandwidth. I’ve already theorized up this type of game from technical standpoint so that the cheating that might plague p2p game would not become an issue. Essentially a 3rd party peer would act as the ’server’ for resolution of fight between two players (peer 1&2) and the ’server peer’ would be decided on latency to peer 1&2 etc on the fly.

Now if the encrypted game traffic gets dropped because it looks like torrent traffic then whoops ISP will get sued and go out of business due to word of mouth if they don’t act.

]]> By: Nate Lawson http://rdist.root.org/2008/02/18/bittorrent-peer-list-encryption/#comment-4451 Nate Lawson Fri, 22 Feb 2008 17:38:16 +0000 http://rdist.root.org/?p=109#comment-4451 PaulM, MSE/PE are for encrypting data transfers between peers. This new addition was for encrypting the list of peers that is downloaded from the tracker (central server). It's kind of silly how encryption keeps getting added piecemeal instead of being designed in from the beginning. It can always be turned off if it's a performance problem for a particular client or tracker. I'm surprised that just MSE/PE works for you. I was advised by the Azureus developers on irc that it is no longer sufficient for Comcast. The wiki you point to also says this, giving the justification for peer list encryption as a necessary measure to circumvent Sandvine. http://en.wikipedia.org/wiki/BitTorrent_protocol_encryption#Remains_vulnerable_to_disrupted_peer_traffic PaulM, MSE/PE are for encrypting data transfers between peers. This new addition was for encrypting the list of peers that is downloaded from the tracker (central server). It’s kind of silly how encryption keeps getting added piecemeal instead of being designed in from the beginning. It can always be turned off if it’s a performance problem for a particular client or tracker.

I’m surprised that just MSE/PE works for you. I was advised by the Azureus developers on irc that it is no longer sufficient for Comcast. The wiki you point to also says this, giving the justification for peer list encryption as a necessary measure to circumvent Sandvine.
http://en.wikipedia.org/wiki/BitTorrent_protocol_encryption#Remains_vulnerable_to_disrupted_peer_traffic

]]> By: PaulM http://rdist.root.org/2008/02/18/bittorrent-peer-list-encryption/#comment-4450 PaulM Wed, 20 Feb 2008 21:47:39 +0000 http://rdist.root.org/?p=109#comment-4450 I don't know how new RC4 MSE/PE actually are among bittorrent clients. Encryption similar to this has been around for over 2 years. [1] And speaking as a Comcast customer, I can demonstrate that MSE works to defeat their QoS/DoS efforts specific to BitTorrent traffic. Trying to get the latest CentOS DVD ISO using rtorrent with "encryption=allow_incoming,prefer_plaintext" in my .rtorrent.rc will cause the download to be choked at 1Kbps, eventually timing out peers and never completing. By changing to "encryption=require,enable_retry" that same torrent file will reach download speeds upwards of 500Kbps per peer, and upload speeds of about 40-50Kbps per peer. That's in keeping with what I see from single SSH file transfers. [1] http://en.wikipedia.org/wiki/BitTorrent_protocol_encryption#MSE.2FPE_in_BitTorrent_client_versions I don’t know how new RC4 MSE/PE actually are among bittorrent clients. Encryption similar to this has been around for over 2 years. [1]

And speaking as a Comcast customer, I can demonstrate that MSE works to defeat their QoS/DoS efforts specific to BitTorrent traffic. Trying to get the latest CentOS DVD ISO using rtorrent with “encryption=allow_incoming,prefer_plaintext” in my .rtorrent.rc will cause the download to be choked at 1Kbps, eventually timing out peers and never completing. By changing to “encryption=require,enable_retry” that same torrent file will reach download speeds upwards of 500Kbps per peer, and upload speeds of about 40-50Kbps per peer. That’s in keeping with what I see from single SSH file transfers.

[1] http://en.wikipedia.org/wiki/BitTorrent_protocol_encryption#MSE.2FPE_in_BitTorrent_client_versions

]]> By: Nate Lawson http://rdist.root.org/2008/02/18/bittorrent-peer-list-encryption/#comment-4449 Nate Lawson Wed, 20 Feb 2008 18:52:55 +0000 http://rdist.root.org/?p=109#comment-4449 Another way to say it is that P2P takes advantage of a unique inefficiency in the pricing of asymmetric broadband connections. The downstream bandwidth is the most efficiently used while the upstream is overallocated for most apps. However, if they cut the upstream too much, sending email attachments or uploading pictures would be too slow. Another way to say it is that P2P takes advantage of a unique inefficiency in the pricing of asymmetric broadband connections. The downstream bandwidth is the most efficiently used while the upstream is overallocated for most apps. However, if they cut the upstream too much, sending email attachments or uploading pictures would be too slow.

]]> By: mmw http://rdist.root.org/2008/02/18/bittorrent-peer-list-encryption/#comment-4448 mmw Wed, 20 Feb 2008 01:39:36 +0000 http://rdist.root.org/?p=109#comment-4448 ISPs do ""peer to peer', two years ago, it was very funny to see newspaper titles like, the danger behind peer-to-peer howto stop it ecetera, I was involved against this http://en.wikipedia.org/wiki/DADVSI because as you show "this is without end" and the problem is rejected (on) the end-user, the real problem is still the same: why bittorrent exists? but nobody wants to start thinking about this, asking the right questions regarding Internet and may be we could find the good answers. Cheers! ISPs do “”peer to peer’, two years ago, it was very funny to see newspaper titles like, the danger behind peer-to-peer howto stop it ecetera, I was involved against this http://en.wikipedia.org/wiki/DADVSI because as you show “this is without end” and the problem is rejected (on) the end-user, the real problem is still the same: why bittorrent exists? but nobody wants to start thinking about this, asking the right questions regarding Internet and may be we could find the good answers.

Cheers!

]]>