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

[lorenzo]

On 2/9/06, Dave Korn <davek_throwaway at hotmail.com> 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 majordomo at metzdowd.com