Moderator: Moderators
Snooze wrote:Hmm...Just wondering ... Is there still being worked on encrypted transfers ? Or is this a plan for the future..?
SuperZorro wrote:How about letting the Hub generate the certs for the users, and then send them to the user at login (over the DC protocol or email). Then when you request a file, the sender will get your public key from the hub, and use this to encrypt the file.
).
-triage wrote:It seems to me that given the userbase dc++ finds itself with, the goal would be do obfuscate what exactly is being traded between the clients, and to prevent unauthorized persons from joining private hubs.
I for one would love to see even some very low level encryption on all data transfers, simply for the purpose of defeating packet sniffers that are looking at packet headers
) This is already commonly done with a few other p2p programs, just like you said, and it doesn't fix the problem. Read the documentation on packetter for example; they are prepared for this exact case.xhost+ wrote:What I would have liked in terms of encryption is to encrypt the content but also make the transfer look like a "standard" well known protocol... Like HTTP or SMTP...
xhost+ wrote:They do not need packet nor traffic shaping to detect the huge amount of data that is drawn by p2p networks.
Does this really merit no encryption at all then? If your ISP decides to throttle bandwidth based on your usage there really isn't anything you can do about it besides using less bandwidth. (But I think you are trying to tie this usage to any protocol that does not match an Allowed List of Protocols. Are you aware of an ISP using something like this?)
xhost+ wrote:I don't know if its possible with DC. Should be possible to use port 80, 25 or 119 when you're a source and insert a few "From:" or "<HTTP>" in the frames.
Qbert wrote:Does this really merit no encryption at all then? If your ISP decides to throttle bandwidth based on your usage there really isn't anything you can do about it besides using less bandwidth.
xhost+ wrote:One thing for sure is that a shaper based on protocol would NEVER EVER disable or limit one of the comercially[SP] used protocols (eg SMTP or HTTP), too much money is involved.
Qbert wrote:If DC++ were to appear as another protocol, that would only give packet shapers a clue as to DC++ traffic (even though it would require further analysis to accurately detect DC++.) ......... This is already commonly done with a few other p2p programs, just like you said, and it doesn't fix the problem. Read the documentation on packetter for example; they are prepared for this exact case.
Code: Select all
send(socket,*data, strlen(data),0);
Code: Select all
enc_connect_to(username,(OUT)keybuffer,(OUT)enc_method) ;
enc_send(username,filename,key,enc_method);
/* where enc_connect is afunch for getting the symetric encryption key/type from username.and enc_send which is basicly a encryption wrapper for normal send/to. */
) that whould make it pretty *secure*.
augie wrote:first of all imgo i dont [sic] think we need SSL/TLS. theres [sic] no need to add that overhead (as i understand it is that it wraps the normal tcp/ip packet into a brand new packet, which makes eatch [sic] packet about 20bytes larger, its not mutch [sic] but everything counts in large amounts.) and with normal symetric encryption there isent [sic] any overhead. except for the key-exchanges.
. I think it is that important. The other planned features seem so minor in comparison. I know a ton of other people who feel this way. I want it to get around packet shapers and many others want it for private transfers. It seems like a no-brainer, no?