Encrypted Transfers
Moderator: Moderators
Encrypted Transfers
if i create a nice looking, decent patch for dc++, for encryted transfers, would it be worth my time making one
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
http://bodstrom.omfg.se - Bodströmsamhället, Länksamling om hoten mot vår personliga integritet
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.
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.
no. it just need to begin with diffrent values...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.
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.
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.
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.
It says on their website:cologic wrote:OpenSSL's license is incompatible
(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.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."
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
oops..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.
i will just be quiet.. implementing OpenSSL sounds realy good... didnt know it worked.
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).
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).
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?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.
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
http://bodstrom.omfg.se - Bodströmsamhället, Länksamling om hoten mot vår personliga integritet
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â€
[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â€
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us