Encrypted Transfers

Technical discussion about the NMDC and <a href="http://dcpp.net/ADC.html">ADC</A> protocol. The NMDC protocol is documented in the <a href="http://dcpp.net/wiki/">Wiki</a>, so feel free to refer to it.

Moderator: Moderators

Locked
Pothead
Posts: 223
Joined: 2005-01-15 06:55

Encrypted Transfers

Post by Pothead » 2005-10-29 19:02

if i create a nice looking, decent patch for dc++, for encryted transfers, would it be worth my time making one :?:

Flow84
Posts: 31
Joined: 2004-11-08 17:59

Post by Flow84 » 2005-10-29 19:36

please do... :)
If it is not implemented in the orginal one. maybe in a mod.. :P
but it would be cool so it would be harder to spy on dc traffic.
no im not refering to dc upload/download... i most want it for pm/main chat :)

cyberal
Posts: 360
Joined: 2003-05-16 05:42

Post by cyberal » 2005-10-30 19:35

are there any developments in this area from the original DC++ dev team.. or any plans for ADC? I've seen nothing about encryption at all in teh ADC documentation.. seems a bit strange to me to develop a new protocol at this time and not include support for encryption.. I may way off on this one though.. maybe there are plans for it and I've just not found anything about it..
http://whyrar.omfg.se - Guide to RAR and DC behaviour!
http://bodstrom.omfg.se - Bodströmsamhället, Länksamling om hoten mot vår personliga integritet

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

Post by Phantom » 2005-10-30 22:29

I'd personally love to see a good patch for this.
I'd also like to see encryption for the connection to the hub aswell (although with that i'm playing with stunnel)

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

Post by Carraya » 2005-10-31 02:59

well seriously it wouldn't be much good, since it would just require a dc++ client to decrypt it...
<random funny comment>

Flow84
Posts: 31
Joined: 2004-11-08 17:59

Post by Flow84 » 2005-10-31 04:21

Carraya wrote:well seriously it wouldn't be much good, since it would just require a dc++ client to decrypt it...
it depends on how it is done...
if use 2 keys that is made on the first connect or something...

Pothead
Posts: 223
Joined: 2005-01-15 06:55

Post by Pothead » 2005-10-31 04:37

I was thinking anything involving a hub and encrypting data would be a bad idea, as it'll need to encrypt the data differently for each user if you want it to be secure. Maybe ways around this, but i don't know. Like stunnel which Phantom mentioned, which impiles an encrypted ssl tunnel between the two. Could work, but i really don't know enough about stuff like that.

I was also thinking the PGP method would probably be best for transfers.
2 keys for each user, one public and one private.
The uploader encryts the datastream, using the downloaders public key.
The downloader uses their private key to decrypt it.

Flow84
Posts: 31
Joined: 2004-11-08 17:59

Post by Flow84 » 2005-10-31 04:50

Pothead wrote:I was thinking anything involving a hub and encrypting data would be a bad idea, as it'll need to encrypt the data differently for each user if you want it to be secure. Maybe ways around this, but i don't know.
no. it just need to begin with diffrent values...
Dont know what thouse values should be but...

Time of first message recieved to hub from client (in sec),
client ip, client nick and client id...

maybe?...

about the client 2 client transfers. it would probably be good.

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

Post by cologic » 2005-10-31 10:20

Pothead, this DC++ wiki page contains a discussion a comprise which avoids the potential performance issue you refer to. Compression differs from encryption, but in this case from whom is one encrypting it? C-H encryption doesn't defend from the hub (since it has to see them) or from other users (who should never see them, as long as the hub never sends them said messages), but rather from external entities. For this purpose, one could conceivably use a similar approach as that wiki describes: batch up broadcast messages, encrypt them with a single key, and send them out.

The wiki approach, most directly, doesn't hide that (A)DC's being used, which I regard as probably more important, for avoiding traffic throttling and suchlike. For that, transparent encryption would find usage. Unfortunately, the trick used by the wiki entry to avoid CPU usage ceases working generally (since non-broadcast messages must be encrypted, which differ between users).

Flow84, I find your post entirely opaque, except for the last line (with which I agree).

Rather than invent one's own cryptosystem, a patch similar to Phantom's suggestion should probably incorporate a known and tested SSL/TLS library. OpenSSL's license is incompatible, but I've seen reasonably good reports of MatrixSSL and yaSSL.

Finally, this thread contains much information and discussion which needs not be repeated here.

ullner
Forum Moderator
Posts: 333
Joined: 2004-09-10 11:00
Contact:

Post by ullner » 2005-10-31 10:46

cologic wrote:OpenSSL's license is incompatible
It says on their website:
If you develop open source software that uses OpenSSL, you may find it useful to choose an other license than the GPL, or state explicitly that "This program is released under the GPL with the additional exemption that compiling, linking, and/or using OpenSSL is allowed."
(FAQ) From what I understand of that, it is allowed to use OpenSSL together with DC++, but only if you state that OpenSSL is not under the GPL.

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

Post by GargoyleMT » 2005-10-31 12:28

ullner wrote:From what I understand of that, it is allowed to use OpenSSL together with DC++, but only if you state that OpenSSL is not under the GPL.
No, you have to change the license of DC++ so that people are allowed to link it with OpenSSL. Similar exceptions have been discussed in the past.

Flow84
Posts: 31
Joined: 2004-11-08 17:59

Post by Flow84 » 2005-10-31 12:49

cologic wrote: Flow84, I find your post entirely opaque, except for the last line (with which I agree).

Rather than invent one's own cryptosystem, a patch similar to Phantom's suggestion should probably incorporate a known and tested SSL/TLS library. OpenSSL's license is incompatible, but I've seen reasonably good reports of MatrixSSL and yaSSL.
oops.. :P
i will just be quiet.. implementing OpenSSL sounds realy good... didnt know it worked. :)

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

Post by Phantom » 2005-10-31 12:58

In all honesty, personally i'm not too concerned about client <-> client transfers being encrypted. The thing I really want is DC protocol to be encrypted. ZLine looks good apart from the fact that $ZLine can still be detected and associated with DC traffic.
I use/run a DC Hub for legitimate purposes, and some ISPs are now watching for basic protocol and limiting peoples connection to the hub itself. Hence for those people I am trying to get Stunnel to work (and find a way to make it easy for the connecting clients to use too).

Pothead
Posts: 223
Joined: 2005-01-15 06:55

Post by Pothead » 2005-10-31 14:22

Thanks for the info cologic. :)

cyberal
Posts: 360
Joined: 2003-05-16 05:42

Post by cyberal » 2005-10-31 16:26

Pothead wrote:I was thinking anything involving a hub and encrypting data would be a bad idea, as it'll need to encrypt the data differently for each user if you want it to be secure. Maybe ways around this, but i don't know. Like stunnel which Phantom mentioned, which impiles an encrypted ssl tunnel between the two. Could work, but i really don't know enough about stuff like that.

I was also thinking the PGP method would probably be best for transfers.
2 keys for each user, one public and one private.
The uploader encryts the datastream, using the downloaders public key.
The downloader uses their private key to decrypt it.
aren't assymetric algorithms generally much slower than symmetric, why a symmetric session key exchange with an assymetric public/private key-pair would be preferrable?
http://whyrar.omfg.se - Guide to RAR and DC behaviour!
http://bodstrom.omfg.se - Bodströmsamhället, Länksamling om hoten mot vår personliga integritet

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

Post by cologic » 2005-10-31 18:27

cyberal, ADC 0.7 explicitly anticipated SSL:
[quote]Addresses are always sent as x.x.x.x:port for IPv4 and RFC2732 ([x:x:x:x:x:x:x:x]:port) with following :port for IPv6 (port must always be specified, default ports don’t exist). Hub addresses must always be specified in url form, with “adcâ€

Pothead
Posts: 223
Joined: 2005-01-15 06:55

Post by Pothead » 2005-11-09 10:15

cologic wrote:I've seen reasonably good reports of MatrixSSL and yaSSL.
After having a quick look at both Matrix one looks like it'll probably be better, as it's 4x smaller, and the developers have made it cross system compatable, and also provided a nice project file, which actually works with VS, without warnings / errors. :)

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

Post by GargoyleMT » 2005-11-09 10:49

MatrixSSL seems to be dual licensed under a commercial license and the GPL, so that's good. (They must've chosen the GPL [versus the LGPL] so open source applications could use it, while commercial ones could not.)

Locked