Jump to content

Debate over Protocol Encryption


ev0|

Recommended Posts

  • Replies 105
  • Created
  • Last Reply

I've seen a few Az 2.4 users and have uploaded and downloaded with encryption to them. They seem to be the majority of encrypted peers right now, but I've also traded data a 141B user as well. The encryption thing is moving along nicely. I've also had quite a few peers with the X (peer exchange) but I've got it turned off, so that's a little bit of a mystery.

Link to comment
Share on other sites

I would like similar option for the encryption in µTorrent as it is in Azureus.

First a checkbox to activate PE, then another two checkboxes where you can choose

to allow incoming or outgoing non-encrypted connections.

Because it does the same thing as the current options and it's much simplier and easier to understand.

Link to comment
Share on other sites

IMO, RC4 is good enough. I'm not sure why one would really need higher encryption, unless you're ultra-paranoid. RC4 isn't easy to crack in real-time, and ISPs really don't have the time or resources to be trying to crack all the suspicious traffic.

As for the allowing or disallowing non-encrypted connections... "Allow incoming legacy connections" already disables incoming, and "Disabled" already disables outgoing. A checkbox just adds an extra widget and text onto the screen for no benefit =T

Link to comment
Share on other sites

Going way back to the original topic of this thread, Bram has been far behind the times for a long time now. His comments about encryption only highlight this fact. We have him to thank for the original specifications, but he has never really grasped the real world application of the protocol.

Link to comment
Share on other sites

lol, anyone who thinks this encryption method will last longer against packet shaping than bitcomets did is severly misguided

there are various methods to go about traffic analysis and shaping that dont require knowing the contents of the packet, its no use deluding yourselves into believing that because this method can encrypt the entire packet itll be unbreakable

possibly the worst part is the key itself, being generated from the info hash thats sent _unencrypted_ as a binary string to the tracker before you even recieve a list of peers. encryption only works when only they sending and recieving parties know the key, because azureus is open source and the main component of the key is required to be sent unencrypted across a normal http connection, this encryption method is anything but secure

Link to comment
Share on other sites

See my reply on P.1. We all know that there are countermeasures (even an idiot can consider the possibility of complete closure of all but 25, 80; 443), but the point is to make it harder for them and force them to either Follow or Reconsider their Stupid, arguably Fradulent move - I just don't see those govnos remembering to say in their contracts.

I'm aware some ISPs have eventually developed countermeasures against BC, yet some still say they use BC because it is the thing that got them through. Obviously, some ISPs didn't bother to follow, or maybe it wasn't cost-efficient for them to follow...

I doubt that Brian Cohen is trying to tell us to use that "reasonably secret piece of information", the hash, to ease encryption (and create the vulnerability you mentioned) if we are already using it.

In theory, a "Diffie-Hellman", as I understand it, is supposed to ensure the key itself can be distributed in a secure manner without being reliant on unencrypted info being sent around to generate the key, and I've been told a working encryption should provide security even if its programming was known (such as if you are the author, or if the program is open-source).

Link to comment
Share on other sites

azureus being open source is irrelevant, the protocol encrypton specification is open and freely available to anyone with a web browser. Much like most other encryption methods. :P Security through obscurity doesn't work.

Also, BitComet's PHE failed because there was still a lot of easily identifiable traffic, namely the BitTorrent initial handshake

Link to comment
Share on other sites

Just tried out the encryption. Downloaded at max speed @ ~2Mb/s. Encryption settings @ maximum (Forced) And "Enable legacy.. on" . However all clients doesn't seem to me E/e-flagged. And some clients are Azereus 2.3.0.6 which shouldn't be able to connect. Is it really fully encrypted because it seems that some clients are able to sneak in.

encryptedspeed9vg.th.jpg

Link to comment
Share on other sites

@juniorx: That's probably because you're only allowing encrypted users, and it seems only 4 people on that torrent (approximately) have the ability to use encryption. The "1000 seeds" are useless, unless they're all running encryption (provided you're forcing encryption).

Basically you're comparing the speed of an unthrottled connection on a torrent with "1000 seeds" to an encrypted connection with 4 seeds. No wonder it's going slower. The only fair comparison would be if those 1000 seeds had µTorrent or Azureus supporting encryption.

-Ares

Link to comment
Share on other sites

I've been able to put "forced" and unchecked legacy and still get awesome speeds for th e first time today. Mostly this is because of the fact than many people auto-updated to Azureus 2.4.0.0 which supports it, providing a hell of alot more encrypted peers ! I can't wait until utorrrent goes 1.5.0.0 as well, and all those annoying 1400 users start being able to encrypt !

Link to comment
Share on other sites

@juniorx: That's probably because you're only allowing encrypted users, and it seems only 4 people on that torrent (approximately) have the ability to use encryption. The "1000 seeds" are useless, unless they're all running encryption (provided you're forcing encryption).

Basically you're comparing the speed of an unthrottled connection on a torrent with "1000 seeds" to an encrypted connection with 4 seeds. No wonder it's going slower. The only fair comparison would be if those 1000 seeds had µTorrent or Azureus supporting encryption.

-Ares

What are the recommended settings then for a throttled user like myself?

Link to comment
Share on other sites

@juniorx: Right now I'm in the same boat as you. All we can do is wait for there to be more encrypted peers as ev0 mentioned above. Wait for the stable release of µTorrent, and that just might do the trick. Right now I can't download over 5KB/s, unless I get encrypted peers. Best thing you can do is tell *everyone* that bittorrents about the latest betas of µTorrent and get them to switch ;)

-Ares

Link to comment
Share on other sites

@juniorx: That's probably because you're only allowing encrypted users' date=' and it seems only 4 people on that torrent (approximately) have the ability to use encryption. The "1000 seeds" are useless, unless they're all running encryption (provided you're forcing encryption).

Basically you're comparing the speed of an unthrottled connection on a torrent with "1000 seeds" to an encrypted connection with 4 seeds. No wonder it's going slower. The only fair comparison would be if those 1000 seeds had µTorrent or Azureus supporting encryption.

-Ares[/quote']

What are the recommended settings then for a throttled user like myself?

Az recommends - this

http://azureus.aelitis.com/wiki/index.php/Avoid_traffic_shaping

If there were 1000 peers suppotring EP - I would say - forced w/o legacy. Right now - your best bet would be - enabled + legacy

Link to comment
Share on other sites

i'm on rogers and encryption seems to be working, its just that more utorrent users should use the beta.. hopefully a stable one with the encryption will be out soon. gettin pretty good speeds from az 2.4 users but the speed fluctuates a whole lot and i find my upload speed still kinda sucks.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.


×
×
  • Create New...