Re: FWD: [IP] Encrypting Bittorrent to take out traffic shapers

[Dave Korn]

Alexander Klimov wrote:
 On Tue, 7 Feb 2006, Adam Fields wrote:
 Over the past months more Bittorrent users noticed that their ISP is
 killing all Bittorrent traffic . ISP?s like Rogers are using bit-
 shaping applications to throttle the traffic that is generated by
 Bittorrent.

 A side note is that they're using known insecure encryption methods
 as a cpu tradeoff because it doesn't matter if the traffic is
 decrypted eventually, as long as it can't be revealed in realtime.
 That's possibly shortsighted, but still interesting.

 Since one can easily encrypt 60 Mb/s with AES on a modern computer it
 does not matter what algorithm to use (unless, of course, you have a
 wider than 60 MB/s connection).

  Ah, but you haven't allowed for the fact that the ISP has to do this for 
/all/ the traffic from /all/ of their customers if they want to know if it's 
BT or not.

 BTW, if ISP really wants to slow down bittorrent it can use some other
 methods: there is usually constant port (6881, IIRC), and quite
 specific communication patern.

  Indeed, they're likely to find a traffic-analysis method of doing this 
sooner or later, and then they won't have to bother about the encryption.

  cheers,
 DaveK
-- 
Can't think of a witty .sigline today 




-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]

Re: FWD: [IP] Encrypting Bittorrent to take out traffic shapers

[lorenzo]

On 2/9/06, Dave Korn [EMAIL PROTECTED] wrote:
 Alexander Klimov wrote:
  On Tue, 7 Feb 2006, Adam Fields wrote:
[...]
  A side note is that they're using known insecure encryption methods
  as a cpu tradeoff because it doesn't matter if the traffic is
  decrypted eventually, as long as it can't be revealed in realtime.
  That's possibly shortsighted, but still interesting.
  BTW, if ISP really wants to slow down bittorrent it can use some other
  methods: there is usually constant port (6881, IIRC), and quite
  specific communication patern.
   Indeed, they're likely to find a traffic-analysis method of doing this
 sooner or later, and then they won't have to bother about the encryption.

Maybe I've missed a point, but with encryption I thought you can
*simulate* every communication pattern. You can send a flow of
constant, random data when you're not getting bittorrent data and
there you have another kind of connection. A full-duplex flow of data
can be a VoIP encrypted stream, a VPN, X session over ssh, whatever.
Or am I mistaken?
Also, since encryption will be used only to obfuscate the real data, I
think that even a simple XOR could suffice.
From a provider point of view, a solution could be only allowing
http[s], ftp, maybe ssh based on the port number. But if a BT
application listens on port 22, you're pretty much screwed up. And
also if I subscribe to an ISP that gives me *internet* access via
TCP/IP they should specify on the EULA which ports I should use or
not.

my .2 euros.
--
:lorenzo grespan
GPG Key fingerprint = 5372 1B49 9E61 747C FB9A  4DAE 5D2A A9A0 74B4 8F1A

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]