Encryption Capable DC++ ?

Use this forum to flesh out your feature request before you enter it in <a href="http://dcpp.net/bugzilla/">Bugzilla</a>.

Moderator: Moderators

Locked
edro1
Posts: 1
Joined: 2005-12-03 09:22
Location: Ohio
Contact:

Encryption Capable DC++ ?

Post by edro1 » 2005-12-03 09:39

Hello everyone, I would like to make a proposal. Due to the recent crakdown by the RIAA and MPAA, I think it would be a great idea to implement encryption into DC++.
(My internet connection was temporarily suspended due to my downloading activity)

I found an Open Source P2P program called Waste that utilizes encryption.

It would be great if we could incorporate encryption into DC++, Hub Hosting Software (ie, PtokaX) and to create a hublist for those hubs that require a passphrase to start the encryption (and have the option to remember passphrase in DC++)

My programming skills are minimal, hence the reason I am making this post.

Adding this encryption would make it next to impossible for ISPs to see what you are downloading (currently, data transfered from DC++ is in Plain Text)

Well, let me know what you think.

Thanks,
Ed :D

Todi
Forum Moderator
Posts: 699
Joined: 2003-03-04 12:16
Contact:

Post by Todi » 2005-12-03 09:52

I think you're missing something here. Your ISP is not spying on you. RIAA/MPAA agents are using DC clients to download your userlist and are reporting you. They could do this just as easy if the traffic was encrypted. The only thing gained by encryption is to avoid trafficshaping, you can not escape users downloading your filelist or recieving searchresults from you by encrypting things.

cologic
Programmer
Posts: 337
Joined: 2003-01-06 13:32
Contact:

Post by cologic » 2005-12-03 09:55

See these three threads, as well as
http://cvs.sourceforge.net/viewcvs.py/dcplusplus/dcplusplus/changelog.txt?view=markup/ wrote:* Added basic SSL encryption support (ADC only)
in the changelog of the DC++ version currently under development.

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2005-12-03 09:58

Encryption has been a long-time requested feature, but primarily (I hope) for other reasons.

edro1 wrote:Hello everyone, I would like to make a proposal. Due to the recent crakdown by the RIAA and MPAA, I think it would be a great idea to implement encryption into DC++.

Bah, the MPAA and RIAA have every right to enforce copyright. If you're breaking the law, you assume that risk. If you want encryption to avoid being detected, I'm against it.

From my understanding, people are caught by other people, not by having their network connection sniffed.

bastya_elvtars
Posts: 164
Joined: 2005-01-06 08:39
Location: HU
Contact:

Post by bastya_elvtars » 2005-12-03 10:26

In my country ISPs are not allowed (or only in very rare cases) to sniff your traffic, since it's the same as monitoring your phone calls. If transfers were encrypted, you could still be caught using the same kind of client as yours.
Hey you, / Don't help them to bury the light... / Don't give in / Without a fight. (Pink Floyd)

Carraya
Posts: 112
Joined: 2004-09-21 11:43

Post by Carraya » 2005-12-04 03:14

yup basta and garg are right (dare I say as always) encryption client side will not make any more difference than having a private hub, since as soon as the "bad guy" (here meaning whoever you don't want spying on you) is connected he can do exactly the same things as you can.
<random funny comment>

Phantom
Posts: 72
Joined: 2003-01-11 20:13
Location: New Zealand

Post by Phantom » 2005-12-05 23:22

But on the other hand its perfect for bypassing traffic shaping that may exist for "p2p" traffic, regardless of what you are doing with it.

Carraya
Posts: 112
Joined: 2004-09-21 11:43

Post by Carraya » 2005-12-06 05:06

Phantom wrote:But on the other hand its perfect for bypassing traffic shaping that may exist for "p2p" traffic, regardless of what you are doing with it.


Yup it's actually the only reason I can see to do this... But not sure how long it'll take the ISPs to find out...
<random funny comment>

bastya_elvtars
Posts: 164
Joined: 2005-01-06 08:39
Location: HU
Contact:

Post by bastya_elvtars » 2005-12-06 05:20

Carraya wrote:
Phantom wrote:But on the other hand its perfect for bypassing traffic shaping that may exist for "p2p" traffic, regardless of what you are doing with it.


Yup it's actually the only reason I can see to do this... But not sure how long it'll take the ISPs to find out...


Then the only thing they can do about it is outbound blocking, which would lead to pain in the ass for them, or not?
Hey you, / Don't help them to bury the light... / Don't give in / Without a fight. (Pink Floyd)

Carraya
Posts: 112
Joined: 2004-09-21 11:43

Post by Carraya » 2005-12-06 06:52

or start blocking ssl encryption, specific ports or the like... if they really want to cause pain they can, but I'm sure people would change to another ISP if they could in that case...
<random funny comment>

bastya_elvtars
Posts: 164
Joined: 2005-01-06 08:39
Location: HU
Contact:

Post by bastya_elvtars » 2005-12-06 08:15

I think blocking SSL encryption is something they will never do, since if they did it here, i could not sign up for my lessons, for example. Or, many webmail sites could not be accessed.
Hey you, / Don't help them to bury the light... / Don't give in / Without a fight. (Pink Floyd)

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2005-12-06 12:42

bastya_elvtars wrote:Then the only thing they can do about it is outbound blocking, which would lead to pain in the ass for them, or not?

I'd be surprised if this is the case. I'm sure, encrypted or not, DC++'s traffic patterns are pretty recognizable, and may even be unique. Sure, a long transfer may look like a HTTPS download of XP SP2 from Microsoft, but the hub connection is long-standing, and search results will still need to be sent via UDP, so...

Klugeman
Posts: 3
Joined: 2005-12-06 04:22
Contact:

Post by Klugeman » 2005-12-06 20:29

I just came up with some idea.
I am not in deep hack in to TCP/IP but mabe it can be usefull.
Since when sniffing filename can be recognized by packet header
mabe we need only to encript packet header
and send those packets anonimously (packet1, packet2, etc..)

Carraya
Posts: 112
Joined: 2004-09-21 11:43

Post by Carraya » 2005-12-07 03:22

well it'll have to send pretty unique stuff as well, as Garg said, so seriously this will not make it impossible for anyone to find out what you are sharing and the like, it'll only make it a little harder, and I don't really see any real gain, except more traffic...
<random funny comment>

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2005-12-07 08:59

Klugeman wrote:Since when sniffing filename can be recognized by packet header
mabe we need only to encript packet header

If you're only concerned about obscuring the filename, there aren't any legitimate reasons I can think of for that other than hiding from the enforcement agencies.

Encrypting the filename will not help. For modern versions, DC++ doesn't even use the filename, it uses the TTH root hash for the files (when requesting/sending the file).

The enforcement agencies seem (from the letters posted here in the past) to get the list of infringing filenames from search results and file lists. They seem to join the hub as normal users, so you cannot (and we are not interested in) protect against that.

Wisp
Posts: 218
Joined: 2003-04-01 10:58

Post by Wisp » 2005-12-07 15:05

The only thing to avoid the RIAA-mafia is to route the traffic through other users so that clients are unable to link a user to an IP.

@GargoyleMT, there are a lot of known cases where RIAA wrongfully accused people of sharing. Victims mostly accept a settlement because they fear the huge compensations.

Beside that, there are a lot of people sharing stuff that is forbidden by governments, encryption could also prevent that. The only downside is that anonimity can attract childporn traders or muslim terrorists, but in that case hub owners could easily ban the offenders, and the hub itself is always trackable by IP.

cologic
Programmer
Posts: 337
Joined: 2003-01-06 13:32
Contact:

Post by cologic » 2005-12-07 16:09

Wisp wrote:The only downside is that anonimity can attract childporn traders or muslim terrorists, but in that case hub owners could easily ban the offenders, and the hub itself is always trackable by IP.

Freenet's philosophy is worth keeping in mind, as well.

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2005-12-08 12:18

Wisp wrote:@GargoyleMT, there are a lot of known cases where RIAA wrongfully accused people of sharing. Victims mostly accept a settlement because they fear the huge compensations.

The existence of false positives doesn't change the conclusion that obscuring the file name wouldn't gain anything given how the enforcers seem to operate...

Wisp
Posts: 218
Joined: 2003-04-01 10:58

Post by Wisp » 2005-12-08 17:46

GargoyleMT wrote:The existence of false positives doesn't change the conclusion that obscuring the file name wouldn't gain anything given how the enforcers seem to operate...

obscuring the file name not, but routing the traffic trough other clients will.

As far as i can judge, it is possible to make clients anonymous that way

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2005-12-08 20:25

Wisp wrote:obscuring the file name not, but routing the traffic trough other clients will.
As far as i can judge, it is possible to make clients anonymous that way

I'm not sure that you could do that and maintain the things that draw users to the DC network.

DC++ will get SSL in ADC mode, and we'll have to see how things develop from there. What you suggest would require a pretty big shift in DC++, much bigger than anything I've seen so far.

cologic
Programmer
Posts: 337
Joined: 2003-01-06 13:32
Contact:

Post by cologic » 2005-12-08 21:26

Wisp, are you sure you don't want an existing anonymous P2P system? (A)DC would seem to lose whatever unique value it has to this. Further, these sorts of networks are tricky and subtle to design securely.

Wisp
Posts: 218
Joined: 2003-04-01 10:58

Post by Wisp » 2005-12-09 16:32

GargoyleMT wrote:I'm not sure that you could do that and maintain the things that draw users to the DC network.

DC++ will get SSL in ADC mode, and we'll have to see how things develop from there. What you suggest would require a pretty big shift in DC++, much bigger than anything I've seen so far.

Maybe it could be implemented in the hub software only, so users have the option of joining a secure hub (which will be a little slower)

Wisp
Posts: 218
Joined: 2003-04-01 10:58

Post by Wisp » 2005-12-09 16:34

cologic wrote:Wisp, are you sure you don't want an existing anonymous P2P system? (A)DC would seem to lose whatever unique value it has to this. Further, these sorts of networks are tricky and subtle to design securely.
I'm personally not interesed in any anonymous p2p software, dc++ in combination with peerguardian is secure enough for me. I was just brainstorming about making it possible to use dc++ in a secure way, it seems that many people are looking for clients which can do that.

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2005-12-09 17:57

Wisp wrote:Maybe it could be implemented in the hub software only, so users have the option of joining a secure hub (which will be a little slower)

I don't think that would work...

ivulfusbar
Posts: 506
Joined: 2003-01-03 07:33

Post by ivulfusbar » 2005-12-10 03:28

Wisp wrote:I'm personally not interesed in any anonymous p2p software, dc++ in combination with peerguardian is secure enough for me.


peerguardian doesn't work since the iptabels are horrifcly bad. all entries i have been able to investigate by myself has been utterly wrong. Its false security.
Everyone is supposed to download from the hubs, - I don´t know why, but I never do anymore.

Locked