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]
