Encryption Capable DC++ ?

edro1 · Post by **edro1** » 2005-12-03 14: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

Todi · Post by **Todi** » 2005-12-03 14: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 · Post by **cologic** » 2005-12-03 14: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.

Post by **GargoyleMT** » 2005-12-03 14: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 · Post by **bastya_elvtars** » 2005-12-03 15: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.

Carraya · Post by **Carraya** » 2005-12-04 08: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.

Phantom · Post by **Phantom** » 2005-12-06 04: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 · Post by **Carraya** » 2005-12-06 10: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...

bastya_elvtars · Post by **bastya_elvtars** » 2005-12-06 10: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?

Carraya · Post by **Carraya** » 2005-12-06 11: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...

bastya_elvtars · Post by **bastya_elvtars** » 2005-12-06 13: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.

Post by **GargoyleMT** » 2005-12-06 17: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 · Post by **Klugeman** » 2005-12-07 01: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 · Post by **Carraya** » 2005-12-07 08: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...

Post by **GargoyleMT** » 2005-12-07 13: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 · Post by **Wisp** » 2005-12-07 20: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 · Post by **cologic** » 2005-12-07 21: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.

Post by **GargoyleMT** » 2005-12-08 17: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 · Post by **Wisp** » 2005-12-08 22: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

Post by **GargoyleMT** » 2005-12-09 01: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 · Post by **cologic** » 2005-12-09 02: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 · Post by **Wisp** » 2005-12-09 21: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 · Post by **Wisp** » 2005-12-09 21: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.

Post by **GargoyleMT** » 2005-12-09 22: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 · Post by **ivulfusbar** » 2005-12-10 08: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.

Encryption Capable DC++ ?

Encryption Capable DC++ ?

Who is online