Encryption Capable DC++ ?
Moderator: Moderators
Encryption Capable DC++ ?
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
(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
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.
See these three threads, as well as
in the changelog of the DC++ version currently under development.http://cvs.sourceforge.net/viewcvs.py/dcplusplus/dcplusplus/changelog.txt?view=markup/ wrote:* Added basic SSL encryption support (ADC only)
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
Encryption has been a long-time requested feature, but primarily (I hope) for other reasons.
From my understanding, people are caught by other people, not by having their network connection sniffed.
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.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++.
From my understanding, people are caught by other people, not by having their network connection sniffed.
-
- Posts: 164
- Joined: 2005-01-06 08:39
- Location: HU
- Contact:
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)
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>
-
- Posts: 164
- Joined: 2005-01-06 08:39
- Location: HU
- Contact:
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 wrote: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...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.
Hey you, / Don't help them to bury the light... / Don't give in / Without a fight. (Pink Floyd)
-
- Posts: 164
- Joined: 2005-01-06 08:39
- Location: HU
- Contact:
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
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...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?
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
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.Klugeman wrote:Since when sniffing filename can be recognized by packet header
mabe we need only to encript packet header
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.
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.
@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.
Freenet's philosophy is worth keeping in mind, as well.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.
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
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 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.
obscuring the file name not, but routing the traffic trough other clients will.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...
As far as i can judge, it is possible to make clients anonymous that way
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
I'm not sure that you could do that and maintain the things that draw users to the DC network.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
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)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.
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
-
- Posts: 506
- Joined: 2003-01-03 07:33
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.Wisp wrote:I'm personally not interesed in any anonymous p2p software, dc++ in combination with peerguardian is secure enough for me.
Everyone is supposed to download from the hubs, - I don´t know why, but I never do anymore.