Jump to content

Encryption Enabled by default?


LaMa

Recommended Posts

Hi,

I am one of the unlucky few who has an ISP (chello.nl) that uses traffic shaping techniques to (heavily) cap bittorrent packets in both directions.

So for me, the new encryption feature is, in one word, fantastic!

I've been waiting for this feature for several months.

Ofcourse, the problem now is.. there's a very small userbase that uses the new µTorrent Beta and has encryption enabled.

My question is, when the next "stable" build gets released, are there plans for having Encryption enabled by default?

I can only hope that will be the case.

If this question has been asked many times before and the developer's are already aware of this.

I apologize for asking and would rather have this thread removed.

Thank you for your time and ofcourse this great piece of software!

(Please excuse any incorrect grammar, my English writing skills are not so good)

-LaMa

Link to comment
Share on other sites

Only for incoming connections, µT will always accept and encrypt an incoming encrypted connection (even for me, in the US, not shaped). I don't really need encryption enabled, so that functionality works great.

Those who are shaped can turn encryption On, and almost all of their connections will be encrypted. If you want added security, turn off legacy incoming connections as well.

Hope this helps! ;)

Link to comment
Share on other sites

Yeah, but then if you have it disabled and I have it enabled. You can download off me, and I can't download off you. This would kinda make those who don't have it enabled leechers from those who have it enabled. So I hope the enabled is the default ... a small bit of overhead is understandable, but lets make this PE more usable.

Link to comment
Share on other sites

No.

That means you can connect to me and I'd encrypt my connection automatically because yours is enabled.

Keep this in mind: Who connects to who has NOTHING to do with who's uploading and who's downloading. You can connect to me and I'll upload to you just the same as I'd connect to you and upload to you.

(that's a well-misunderstood part of BitTorrent I'm trying to clarify there)

It is a 2-way connection as soon as it's established. If you connect to me it'll be encrypted. If I connect to you, though, it may not be encrypted... I don't know how µT handles incoming connections with encryption...

Link to comment
Share on other sites

Hi Falcon4,

Thank you for such a swift response and the information.

However, I'm a little confused.

How I understand it now is... if one does not have encryption set to "Enabled", one is still able to receive encrypted packets but not able to send encrypted packets.

And that's exactly my problem/question.

Since my (and many others) ISP shapes torrent traffic. Only encrypted traffic will go full-speed.

So if only a very small amount of peers have Encryption enabled, which currently is the case, only a very small amount of peers will send me encrypted (read: full-speed).

If this were to change to default in the upcoming stable build, everyone who upgrades or downloads the build would have Encryption Enabled by default. Meaning they would not only receive, but also send encrypted, correct?

This would result in a much larger "encryption enabled" userbase (basicly anyone who uses the new build would have it enabled by default, unless ofcourse it was disabled manually) and therefore in much faster download (and also upload) speeds for people like me.

edit:

@1c3d0g: You are absolutely correct. Azureus' developers should also be informed and asked to (atleast consider) make Encryption Enabled by default.

Link to comment
Share on other sites

This means ironically you can force more encrypted connections if you're on a throttled ISP...by being firewalled in µTorrent.

Then you never need to worry about incoming connections being unencrypted...because there won't be any!

It might even be possible to turn off the firewalled condition (by re-enabling port-forwarding in your router) once connected to a sufficient number of peers+seeds. Then you'd get the best of both worlds (unfirewalled+encrpyted). But what a pain to do!

Link to comment
Share on other sites

Falcon4 . .you are definitely not right . . I am also one of the unlucky few who has an ISP (chello.nl) that uses traffic shaping techniques to cap bittorrent packets in both directions.

I've been testing this new beta a lot and other users really have to set it to ENABLED. When you set utorrent to "Disabled", and we as capped users upload to you, the transfer rate will be pretty weak, mostly from about 5-20KB/s, though generally nearer 5KB/s, with the transfer never indicating an "E" flag to suggest the connections are not encrypted. But, when you set utorrent to "Enabled", and start the transfer again, our same user rate will shoot right up to 50-200KB/s with utorrent showing "E" to indicate encryption now is being used.

I did this test about 5 times I guess, flicking between "Disabled" and "Enabled", and the result showed the same thing everytime. Strange coincidence? Possibly...

Link to comment
Share on other sites

Disabled means you can receive encrypted connections, but you don't make any outgoing ones yourself.

Enabled means you receive encrypted connections AND make encrypted connections yourself. Obviously, shaped users have to set it to Enabled, or Force. But the rest of us don't need to, because we can receive your encrypted connections and the connection will be encrypted.

Link to comment
Share on other sites

This is true, but if one of the clients has disabled encryption and other - enabled, there is a question : who will connect whom first. So there is ca. 50% chance the unencrypted connection will be set... and this is definitely not what shaped users wanted.

Merged Post(s):

This means ironically you can force more encrypted connections if you're on a throttled ISP...by being firewalled in µTorrent.

Then you never need to worry about incoming connections being unencrypted...because there won't be any!

You can achieve the same effect by enabling encryption forced and disabling legacy incoming connections.

Point is, the ISP usually/often/sometimes shape BT by throttling its speeds, not disabling them completely. So, from the shaped user point of view an optimal configuration would be: to connect encrypted with everyone is possible, decrypted only if it's not (because the remote peer client doesn't support encryption)

Unfortunatelly, he can't force such configuration being partially dependant of the remote clients configuration - which support encryption but still can have it disabled. That's why I think encryption should be enabled by default.

Link to comment
Share on other sites

Yes, if I connect to a shaped user who has it enabled, it will be unencrypted (can we discuss changing this behavior? Perhaps ask the client if they prefer encrypting?).

If we all have encrypted connections enabled by default, we'll have a lot more timing-out requests as we try to connect to other peers that don't support it. Also, my LAN torrents will slow to a crawl as my 400MHz Celeron, who barely keeps up with the down/up rate of BT as it is, needs to now encrypt its data.

I'd just like to see the behavior of incoming connections changed for people that have it enabled. It'll always start off as an unencrypted connection, but how about asking if the client prefers encrypting?

Link to comment
Share on other sites

That's all well and good I think, Firon, but only so long as the affected user actually enables encryption in the first place. If they don't then isn't it true that a remote party attempting to transfer from that user will instead need to take it upon themselves to enable encryption on their end?

What are the arguments against a non-shaped user running their client as "Enabled" by default? I don't really understand the push towards "Disabled" being the default setting to be honest...

@Fredman: That text looks familiar... ;)

Link to comment
Share on other sites

Here's what I don't understand but want to--if I'm on a shaped connection, my requests for a download will be encrypted. If I'm uploading, then, and peers don't request encryption the packet won't go out? Let's say for example that I would upload a file with legacy off and forced encryption. If the encryption on the peers is disabled, will they still be able to receive the upload? This is what I'm most concerned with.

Link to comment
Share on other sites

Yes, if I connect to a shaped user who has it enabled, it will be unencrypted (can we discuss changing this behavior? Perhaps ask the client if they prefer encrypting?).

That could be the best solution, but have no idea if it is possible to do.

If we all have encrypted connections enabled by default, we'll have a lot more timing-out requests as we try to connect to other peers that don't support it. Also, my LAN torrents will slow to a crawl as my 400MHz Celeron, who barely keeps up with the down/up rate of BT as it is, needs to now encrypt its data.

Ok, I admit - I really don't know how big impact on the CPU has data encryption.

But - if you notice your CPU load is too high, you can always set encryption to be disabled, right?

Now the question is who will be most likely to change the default properties:

a) statistic user, from default enabled to disabled, because his downloads crawls (because of the too high CPU load)

B) statistic user, from default disabled to enabled, only because someone else, living somewhere on the other end of the world is being shaped by his ISP

I have the strange feeling this question is purely rhetorical :)

BTW: if we are talking about low-end CPU's, shouldn't we consider "total encryption disable" option? Because right now, even disabling outgoing encryptions there is still possibility we will be chocked by incoming encrypted connetions. Without that, alternative would be downgrading to the last stable version of uTorrent without encryption.

Merged Post(s):

Here's what I don't understand but want to--if I'm on a shaped connection, my requests for a download will be encrypted. If I'm uploading, then, and peers don't request encryption the packet won't go out?

All the connection you initiate will be encrypted.

What kind of activity will be carried on during this connection (download, upload or both) doesn't matter.

Let's say for example that I would upload a file with legacy off and forced encryption. If the encryption on the peers is disabled, will they still be able to receive the upload?

Assuming of course, remote client supports encryption at all:

If you initiate connection to him, you should be able to upload.

If he initiate connetcion, he will be refused. This doesn't neccesary mean he won't be able to download from you at all, but he will have to wait untill your client finally initiates connection. Don't ask me here how long it could be, I think it is defined in bittorrent specs.

Disclaimer: I'm not a developer here, so please somebody correct me if I'm wrong

Link to comment
Share on other sites

Thanks for all the feedback, I see we are getting to a nice discussion.

Unfortunately I have only very little to add.

(trying not to cause further confusion or add more speculation)

@Firon

Disabled means you can receive encrypted connections, but you don't make any outgoing ones yourself.

Enabled means you receive encrypted connections AND make encrypted connections yourself. Obviously, shaped users have to set it to Enabled, or Force. But the rest of us don't need to, because we can receive your encrypted connections and the connection will be encrypted.

Taking that for granted.. is this statement correct? (as it seems to be)

I am being traffic shaped.

When my 1.4.1b client (Encryption Enabled) requests a piece from a fellow 1.4.1b peer who has Encryption Disabled... That fellow peer will not send me the requested piece encrypted.

Result: My ISP detects it as BT packets and I get shaped download speed from that fellow peer.

That looks identical to my current situation.

Solution: ..Getting back to my original post... Have everyone work encrypted and make it default with client install. If one really insists not to use encryption, one could could Disable it.

I currently fail to see why we shouldn't?

It would benefit all the shaped peers and improves security in general.

The only downside is the overhead/extra processing power it takes to do the encrypting?

How much is this exactly?

edit:

Just read the article over at Slyck.

"BitTorrent End to End Encryption and Bandwidth Throttling - Part I"

Here's a quote:

Slyck.com: What has been the feedback from end users? For example, are people complaining the decryption of Diffie-Hellman is resource hungry?

µTorrent: We have not had any feedback yet. The amount of resources for Diffie-Hellman is quite small, we're talking much less than a percent of CPU time for normal users. The data stream is encrypted with RC4.

My Pentium 4 can encrypt at 300MB/s (with optimized assembly code), so even if you download at a very fast speed, the RC4 encryption would just use a percent or two of CPU time, which is much less than the time required to compute SHA hashes of all downloaded pieces.

After I read that... to me the whole "Encryption takes up too much resources, I want it disabled" argument kinda makes a moot point.

Link to comment
Share on other sites

Keep in mind the scale that BT and µTorrent is running at here... if encryption is enabled by default, and encryption is strictly a way to get around ISP tr--...

Yeah, continuing my thought tree, I realize that ISPs shouldn't even be throttling in the first place.

Woot, go encryption. :lol:

edit: I just enabled encryption on mine... the thought being that if peers I connect to are in different countries with traffic shaping, it could be affecting my speeds as well... both down and up! :P

Link to comment
Share on other sites

I am being traffic shaped.

When my 1.4.1b client (Encryption Enabled) requests a piece from a fellow 1.4.1b peer who has Encryption Disabled... That fellow peer will not send me the requested piece encrypted.

I'm only learning all this myself at the moment but I think that in this case the data from that remote user to you will be encrypted because your client initiated the outbound link into that user to download from them. It would be your client pulling data from them rather than their client pushing data to you. You initiated the link out to the user and by having your client set to "Enabled" means the client will first try to establish an encrypted connection to the remote user and upon success that link will be used for encrypted data transfer.

As an aside from this, and something I'm trying to weigh up myself here, I think that in this case of you having uTorrent set to "Enabled" and a remote client set to "Disabled", that although your transfers from them will be encrypted, the remote user's transfers from you will not be encrypted and therefore your upload to them may fall foul to ISP traffic shaping, so it'll be the remote user who has their client set to "Disabled" that loses out on the deal. I'm thinking that in order for the remote party to get unrestricted data from you they will have to have their client set to encryption "Enabled", otherwise I think they'll only initiate a non-encrypted link into you.

Solution: ..Getting back to my original post... Have everyone work encrypted and make it default with client install. If one really insists not to use encryption, one could could Disable it.

I currently fail to see why we shouldn't?

It would benefit all the shaped peers and improves security in general.

The only downside is the overhead/extra processing power it takes to do the encrypting?

I've been thinking about this myself a bit as to whether it might be best to have it enabled or disabled by default, though I'm tending to think it could be safer to see how things progress with it set to Disabled by default on initial release, at least for a while in order to see how things work out. I know BitTorrent is highly popular around the world, and many people use uTorrent and Azureus, so it could be too big a move for so many people to go straight to encryption enabled at first given that it's quite a big change of protocol... :)

Anyway nuff respect to the devs for this great move. I'm sure they'll do what's best for the users. :)

Link to comment
Share on other sites

Not just encryption, but data flow as well.

Myth: If I initiated the connection, I'm [uploading/downloading] [to/from] them. If I'm unconnectable I can't seed. If they're unconnectable they are leechers because they can't seed either.

Fact: It doesn't fucking matter. When you're connected it flows both ways. If you're unconnectable, people can't connect to you but you will still upload and download to/from other people. If they are, they have to connect to you. If you both are, neither of you can connect to each other. That's it.

^ That's just a general BT myth "buster" there, nothing really to do with this topic of encryption, but it does need to be said because it might clarify a few people's understandings of encryption "connectability".

Link to comment
Share on other sites

I've been thinking about this myself a bit as to whether it might be best to have it enabled or disabled by default, though I'm tending to think it could be safer to see how things progress with it set to Disabled by default on initial release, at least for a while in order to see how things work out. I know BitTorrent is highly popular around the world, and many people use uTorrent and Azureus, so it could be too big a move for so many people to go straight to encryption enabled at first given that it's quite a big change of protocol... :)

Maybe you're right here...maybe it would be too hasty too make stable official release with encryption enabled as default. But all new betas - why not? :)

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...