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

2006-02-09 Thread 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]


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

2006-02-09 Thread 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

2006-02-08 Thread Alexander Klimov
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 better solution is to stop paying to ISP which does not provide you
with what you have paid for.

> This item was posted to the IP list today about some efforts to add
> encryption to bittorrent for the sole purpose of disguising the
> traffic.
>
> 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).

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.

-- 
Regards,
ASK

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


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

2006-02-08 Thread Adam Fields
This item was posted to the IP list today about some efforts to add
encryption to bittorrent for the sole purpose of disguising the
traffic.

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.



- Forwarded message from Dave Farber <[EMAIL PROTECTED]> -
 Original Message 
Subject:[Dewayne-Net] Encrypting Bittorrent to take out traffic 
shapers
Date:   Mon, 06 Feb 2006 17:22:21 -0800
From:   Dewayne Hendricks <[EMAIL PROTECTED]>
Reply-To:   [EMAIL PROTECTED]
To: Dewayne-Net Technology List <[EMAIL PROTECTED]>

[Note:  The comments posted to this blog entry are worth reading.  DLH]

Encrypting Bittorrent to take out traffic shapers

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.

But, at the same time two of the most popular Bittorrent clients are  
working together to implement header and message stream encryption in  
order to take out these traffic shapers.

Currently both Azureus and µTorrent included this new form of  
encryption (specs) in their latest Beta?s. The fact that these two  
clients are actively working together to implement this new feature  
is promising and will make this form of encryption the new standard  
since the users of these two clients cover the majority of all  
Bittorrent users.

There are two ?encryption modes? available.

The 2 different payload encryption methods plaintext transmission and  
RC4 provide a different degree of protocol obfuscation, security and  
speed. Where the plaintext mode only provides basic anti-shaping  
obscurity, no security and low CPU usage the RC4 encryption  
obfuscates the entire stream and not only the header and adds some  
cryptographic security at the price of spent CPU cycles.

[snip]
Weblog at: 


-

Archives at: http://www.interesting-people.org/archives/interesting-people/


- End forwarded message -

-- 
- Adam

** Expert Technical Project and Business Management
 System Performance Analysis and Architecture
** [ http://www.everylastounce.com ]

[ http://www.aquick.org/blog ]  Blog
[ http://www.adamfields.com/resume.html ].. Experience
[ http://www.flickr.com/photos/fields ] ... Photos
[ http://www.aquicki.com/wiki ].Wiki
[ http://del.icio.us/fields ] . Links




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