Well, no code for it exists in 0.305 just yet. Cologic has done the most work in this area, the most helpful of which is to point out that people making their own encryption schemes are imbiciles (that summary is mine, courtesy of some posts he's shown us from a cryptographic expert mailing list) - reusing an existing SSL or SSH library is the way to go.Snooze wrote:Hmm...Just wondering ... Is there still being worked on encrypted transfers ? Or is this a plan for the future..?
Encryption?
Moderator: Moderators
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
hello
First off I think this is a great idea. Since I am sitting in bith the boats you have been talking about...college student in USA and has a summer house in sweden which I spend my whole summers in.
My problem right now is that my college has been looking in what people are downloading and have all ready kicked out people from downloading 1 move....1!! i hope they don't look on my comp...
Well anyway, I was discussing wiht my networking teacher about the problem, not just about sending files...that are "sencetive" for some people. He mentioned VPN. So i was wondering if VPN would be something that could be inplemented when 2 people "connects" to eachother? Since the data that would be infolded would pass the screening from the university and my swedish ISP.
I don't have a great knowlege about incrypting data and such so it might be something that might be alot easier to implement in DC. Hopefully I will learn some usefull stuff in my security class next semester
swefoly- Stay in school, Drink milk and if u are talking my bandwith plz let it not be only for porn..
My problem right now is that my college has been looking in what people are downloading and have all ready kicked out people from downloading 1 move....1!! i hope they don't look on my comp...
Well anyway, I was discussing wiht my networking teacher about the problem, not just about sending files...that are "sencetive" for some people. He mentioned VPN. So i was wondering if VPN would be something that could be inplemented when 2 people "connects" to eachother? Since the data that would be infolded would pass the screening from the university and my swedish ISP.
I don't have a great knowlege about incrypting data and such so it might be something that might be alot easier to implement in DC. Hopefully I will learn some usefull stuff in my security class next semester
swefoly- Stay in school, Drink milk and if u are talking my bandwith plz let it not be only for porn..
-
- Posts: 1
- Joined: 2003-12-16 14:21
- Location: SE
-
- Posts: 21
- Joined: 2003-10-11 08:59
Stated that for a provider is very simple to do a MITM attack you shouldn't rely on simple key exchange if you want really secure connections.
A provider could implement the MITM attack in different ways but.. is it legal? Decrypting an encrypted connection using theese hacher's tecniques is LEGAL???? Can the RIAA or everyone else do this LEGALLY??
To exchange the symmetric encryption key an asymmetric algo should be used (slow) with a TRUSTED certification autority..The HUB is not TRUSTED... You think you're talking with the hub but you're talking with the enemy...
[/u]
A provider could implement the MITM attack in different ways but.. is it legal? Decrypting an encrypted connection using theese hacher's tecniques is LEGAL???? Can the RIAA or everyone else do this LEGALLY??
This forces everyone to update the hub software! (and is not 100% safe) certs could be sniffed when released! We need something else...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.
To exchange the symmetric encryption key an asymmetric algo should be used (slow) with a TRUSTED certification autority..The HUB is not TRUSTED... You think you're talking with the hub but you're talking with the enemy...
[/u]
-
- Posts: 21
- Joined: 2003-10-11 08:59
The problem is: 95% of people don't have a trusted public key!! And probably they don't want to pay to have one.
A possible solution could be to manually trust the hub and let it be a CA to release the asymmetric keys.
In the "favorite hubs" the user should put hub name, address [...] and public key.
But how can the user know what's the TRUE public key of that hub?
Don't know. But I have some ideas.
An Hub admin could put it in the hub "rules".
Everyone can see the hub's public key (even the admin himself, so he can check with a double or differed connection if the PK in the motd has been modified)...
It's not 100% secure...but it can be "manually checked" by some bot that attempts a connection and analyzes the MOTD!
This was the best idea i had. Let me know if you like it.
A possible solution could be to manually trust the hub and let it be a CA to release the asymmetric keys.
In the "favorite hubs" the user should put hub name, address [...] and public key.
But how can the user know what's the TRUE public key of that hub?
Don't know. But I have some ideas.
An Hub admin could put it in the hub "rules".
Everyone can see the hub's public key (even the admin himself, so he can check with a double or differed connection if the PK in the motd has been modified)...
It's not 100% secure...but it can be "manually checked" by some bot that attempts a connection and analyzes the MOTD!
This was the best idea i had. Let me know if you like it.
Another solution would be if the hub list (for example at hublist.org) carried the public keys for all hubs. And the public key for hublist.org will be issued by a CA (or provided with implementations).
If a hub isn't listed in the hublist (like if you type it in manually), you would use SSH-like key management where the first time you get prompted about the key, and later warned if it changes. You could of course ask someone you trust to verify the key for you before you accept it.
SSH keys could be sent in the "connect to me" statements for encryped p2p transfers aswell. And the hub would verify it by comparing the key with the one used in the current session with the client.
Just a few ideas.
If a hub isn't listed in the hublist (like if you type it in manually), you would use SSH-like key management where the first time you get prompted about the key, and later warned if it changes. You could of course ask someone you trust to verify the key for you before you accept it.
SSH keys could be sent in the "connect to me" statements for encryped p2p transfers aswell. And the hub would verify it by comparing the key with the one used in the current session with the client.
Just a few ideas.
I wrote QuickDC - A DC++ compatible client for Linux and FreeBSD.
-
- Posts: 32
- Joined: 2003-12-12 14:28
- Location: FL,USA
- Contact:
i was just about to make a request for somthing like this because i beleave some isp's are capping connections based on data(from what ive read, not personal experiance). but i thought oh what a great idea encrypt client to client.. but then i realized that for the resons i was thinking it would be more dificult than it seems.. you would need to be encrypting all data from the moment the socket is connected or else isp could still recognize the protocol. im sure there are other resons to encrypt client to client.. but i think figuring a way to encrypt from start would be good.. posibly a new connecttome cmd.. $EncConnectToMe| ??
as far as the encryption type whatever i dont really think this data needs to be encrypted for security resons so i think something like basic non-Key based XOR encryption would be fine.
Tim-
as far as the encryption type whatever i dont really think this data needs to be encrypted for security resons so i think something like basic non-Key based XOR encryption would be fine.
Tim-
Encryption is great, but the question that should be asked is: what is the goal of encryption for dc++? 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.
So as some have said already, authentication of users by the hub, and encryption of the communication channels...hub<->client and client<->client.
Even a token gesture such as XOR or base64 encoding would be better than the current cleartext.
Even on private hubs, anyone watching the traffic can see the username and password (helpfully named MyPass
).
Every time a request for a file is made...there it is, floating over the net in cleartext. e.g. "MyCopyrightedFile.rar"... Every time a search is made, there it is, floating across...who has a match, who made the request...in cleartext.
Now its true that at some point you must decide who to trust, whether its the hub owner or their discretion in regards to users, but it seems to me the initial encryption step would be to make it one step beyond trivial to watch everything taking place.
Thats where I'd start.
Glad to see this is being discussed, given the current climate in the USA...$1000 material available for sharing-->3 yrs in jail. lunacy.
So as some have said already, authentication of users by the hub, and encryption of the communication channels...hub<->client and client<->client.
Even a token gesture such as XOR or base64 encoding would be better than the current cleartext.
Even on private hubs, anyone watching the traffic can see the username and password (helpfully named MyPass
![Wink ;)](./images/smilies/icon_wink.gif)
Every time a request for a file is made...there it is, floating over the net in cleartext. e.g. "MyCopyrightedFile.rar"... Every time a search is made, there it is, floating across...who has a match, who made the request...in cleartext.
Now its true that at some point you must decide who to trust, whether its the hub owner or their discretion in regards to users, but it seems to me the initial encryption step would be to make it one step beyond trivial to watch everything taking place.
Thats where I'd start.
Glad to see this is being discussed, given the current climate in the USA...$1000 material available for sharing-->3 yrs in jail. lunacy.
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
Hold on. DC++ is just a file sharing client. Encryption's primary use would be to (temporarily) defeat traffic shapers. Encryption to prevent people from being caught for copyright infringement is not the goal at all.-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.
From the warning letters I've seen on this forum, the enforcement agencies rarely transfer files, nor do ISPs sniff communications. They join hubs like normal people and search for names of copyrighted materials.
Users are definitely on their own with respect to sharing copyrighted materials - it's their choice, not mine or arne's.
heh, users are always on their own, wasn't trying to say they weren't, but given the history of dc++ (where user requests tend to lend direction to what's implemented), it seems clear that's where file trading clients are headed.
Excellent point about joining and hubs and searching for files, which is why user authentication will be another hot topic for the future (in my view).
but it seems like the rest of my spew still stands. The packet shapers do their thing by checking the headers/protocol/port/etc...at least thats packeteer's deal. They can classify by application even if its going over the same port, so even if you encrypt and tunnel over 80 they could slow ya down. It can even distinguish between the control channel and transfers.. Maybe that's why you say temporarily
Be a cool trick to wrap dc packets so they look like an http download from a site. Dunno enough about it to know if that's possible, but could be pretty entertaining.
By the way, I've been pretty impressed with the progress of dc++ over the years, nice job.
-t
Excellent point about joining and hubs and searching for files, which is why user authentication will be another hot topic for the future (in my view).
but it seems like the rest of my spew still stands. The packet shapers do their thing by checking the headers/protocol/port/etc...at least thats packeteer's deal. They can classify by application even if its going over the same port, so even if you encrypt and tunnel over 80 they could slow ya down. It can even distinguish between the control channel and transfers.. Maybe that's why you say temporarily
![Very Happy :D](./images/smilies/icon_biggrin.gif)
Be a cool trick to wrap dc packets so they look like an http download from a site. Dunno enough about it to know if that's possible, but could be pretty entertaining.
By the way, I've been pretty impressed with the progress of dc++ over the years, nice job.
-t
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. I'd kinda like client-hub trasnfers encrypted too though that would obviously require support by a hub, which I doubt would be easy to get.
I fully agree with what -triage said,
"So as some have said already, authentication of users by the hub, and encryption of the communication channels...hub<->client and client<->client.
Even a token gesture such as XOR or base64 encoding would be better than the current cleartext."
If a hub was made private, even just to the extent of not publicising the ip to anyone who isn't invited, and the transfers were scrambled in some way, it should be quite difficult for ISP's etc to find p2p activity going on.
I fully agree with what -triage said,
"So as some have said already, authentication of users by the hub, and encryption of the communication channels...hub<->client and client<->client.
Even a token gesture such as XOR or base64 encoding would be better than the current cleartext."
If a hub was made private, even just to the extent of not publicising the ip to anyone who isn't invited, and the transfers were scrambled in some way, it should be quite difficult for ISP's etc to find p2p activity going on.
Windoze Sux still....
I don't think encryption would prevent ISPs from figuring out that P2P traffic is going on. They do not need packet nor traffic shaping to detect the huge amount of data that is drawn by p2p networks. No way to get unnoticed when compared to grampa reading his email...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
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...
From the outside, a source would be seen as a web or email server and the client would behave like a web browser or a pop3 email reader... That would also prevent traffic shaping based on ports (my ex-ISP used that: all web-publicity-and-nonsense-infected traffic was going smooth at maximum speed whereas free-content P2P traffic was stuck at 0.62 kb/s even on a 1Mb/s DSL line. No joke) or packet shaping based on protocol to be able to stop the exchange. Of course the real content would be encrypted so that it is impossible to detect what is being transfered. But the protocol would also go unoticed.
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.
I think the first Kazza releases were working on such a basis since it was possible to dowload files using a standard web browser instead of the Kazaa client (pretty annoying to figure out that your computer had been turned into a web server with no security
![Confused :?](./images/smilies/icon_confused.gif)
xhost+ [/quote]
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...
Encryption is the best (and may be the only) way to stop packet shaping based on p2p. To be clear, the 'content' I'm talking about is the data sent between a client and a hub to initiate a connection. This may not be actively parsed by packet shapers right now, but that's just because it's so easy to identify the actual file transfer because of its identifiable headers. You could have just pure data in the file transfer connection (so that is no identifiable protocol), but having it based on a protocol has too many needed advantages such as for data integrity and handling, and so this needs to be encrypted. If it wasn’t encrypted, or at some point had some kind of distinguishing data to identify it, it could clearly be packet shaped.
The connections could be falsified to appear as another commonly used protocol, but I feel that this is really useless unless your ISP only allows internet communication based on an Allowed List of Protocols.
DC++ would have three options: Use its own protocol in an unencrypted mode, an encrypted mode, or appear as another protocol. The first option is clearly the worst against packet shapers. Since all ISP’s that I know of don’t operate on this allowed protocol filtering, 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++.) (And even if the DC++ protocol was encrypted after the falsified protocol, there still is the clue.) This only leaves the full encrypted option. This would only begin to fail when and if ISP’s limit allowed protocols.
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:They do not need packet nor traffic shaping to detect the huge amount of data that is drawn by p2p networks.
I may have sounded confusing, but just remember to skim through this entire thread if needed.
My Visual Studio .NET 2003 is licensed under my name, and the same for my operating system... What about you?
I surf on an OC3 without limitations, two to be exact, and I'm not joking.
I surf on an OC3 without limitations, two to be exact, and I'm not joking.
Hey don't get me wrong. I was definitely not saying that encryption is futile! I was just adding that you want encryption so that no clever sniffer know what you're downloading. What I add is that we could have added the capability that none would have known that you were downloading (on a P2P net). One thing for sure is that a shaper based on protocol would NEVER EVER disable or limit one of the comercially used protocols (eg SMTP or HTTP), too much money is involved. Faking (or more likely using) this protocol to transfer encrypted data on a P2P network would remove defintively the possibility that an ISP limit it.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?)
To answer your question, yes I know an ISP that did traffic shaping based on port numbers. Any connection using ports higer than something like 150 were bandwidth limited. No need to say I quit... It was pretty fun however to read pros complaining about the fact that they couldn't get X terminals working...
But I've read many communiqués from IP rights protection agencies that request the local governments to force ISP to "do something against the proliferation of P2P".
Limiting bandwidth based on protocol seemed so easy and cheap that I thought that it should be assessed as a potential risk.
xhost+
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
BCDC had a feature "insert garbage into incoming/outgoing connections" - it worked okay for some people for a while. It's no longer an option - but if you go back to 0.304, you can probably see it.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.
If the primary reason to go to encryption is to try to get around Packeteer's PacketShaper, etc. then it's very important that those who want that feature understand that it too can be defeated. I don't know how many connections stay open and transfer gigabytes of data - at the very least, the (presumably bright) folks at packeer can locate such connections and throttle them as appropriate. I think we're all on the same page here, anyhow.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.
Proof of concept: It didn't work for Kazaa.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.
Check out snort.org for some examples of how simple and low cost it can be to apply very complex pattern matching at incredible speeds. You may have to search for a while to find examples of the rare very complex dynamic patterns.
My Visual Studio .NET 2003 is licensed under my name, and the same for my operating system... What about you?
I surf on an OC3 without limitations, two to be exact, and I'm not joking.
I surf on an OC3 without limitations, two to be exact, and I'm not joking.
my first post.. yaay!
first i have to say that am totaly for encryption.
anyway heres what am thinking about howto add encryption.
first of all imgo i dont think we need SSL/TLS. theres 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 packet about 20bytes larger, its not mutch but everything counts in large amounts.) and with normal symetric encryption there isent any overhead. except for the key-exchanges.
for eatch client to be secure (by secure i mean that the MITM, doesnt know what were searching for or up/downloading.. witch can only be found out bruteforcing the encryption. or activily searching inside a hub.) now there are 3 ways i see that you can find out what say i have.
1. go into a hub, and download my filelist.
2. sniff the wire for down/up-loads
3. and sniff what i search for/what other people search me for.
now obvisily weeding out evil bots sendt by our evil corporate overloads (read: isps) is the hub operators job.
and when your inside a hub, the hub isent supposed to broadcast search replies to everybody inside the hub. (this may be wrong, as i dont know excatly how the protocol works. but am pretty shure it works this way anyway.) only a protocol change can fix this tho.
bots joining a hub and useing a active search/downloading filelists is the ops job to handle(ban).
but heres what am thinking: (obvisily the hub software has to support this too)
when you join a hub, you use RSA to get the current AES key the protocol is encrypted on. and for the never clients to just add a E:T(rue) to their description tag.
which whouldent break older-clients who could still just log on. and whuld still get normal unencrypted udp since they dont have a E:T in their tag.
and for file-transfers clients whould just generate a normal RSA private/public key and use some light/heavy-weight (depending on paranoia level) .. which can be turned off.
i know atleast if i had a 100mbit link i whouldent want it to have 30-40-50% unused because the file transfers are demaning too mutch from the cpu. but manadatory encryption of the protocol stuff should be done. cause then the MITM cant see what your up/down-loading without capturing the whole file and hashing it and compareing it too a database (this asumeing that the filename isent transported unencrypted in the client --> client stream, which should be encrypted just as everything in the hub --> client, client --> hub bit)
by say just adding a function that wraps around the send/recv function i.e instead of just
anyway encryption on a public hub is pretty futile.. since anyone can come and get what they want.. but in the private (rar) hub am in (thank cyberal
) that whould make it pretty *secure*.
now did that make any sence?
please correct me if you see anything horribly wrong or just disagree with me.
--
disclaimer:
i am not a cryptologist. or a (descent) programmer. and i have never read all of the dc++ code, only 3 or 4 fragments of it. but i have however read a book about the history of cryptography, and i think that ought to count![Cool 8)](./images/smilies/icon_cool.gif)
![Cool 8)](./images/smilies/icon_cool.gif)
first i have to say that am totaly for encryption.
anyway heres what am thinking about howto add encryption.
first of all imgo i dont think we need SSL/TLS. theres 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 packet about 20bytes larger, its not mutch but everything counts in large amounts.) and with normal symetric encryption there isent any overhead. except for the key-exchanges.
for eatch client to be secure (by secure i mean that the MITM, doesnt know what were searching for or up/downloading.. witch can only be found out bruteforcing the encryption. or activily searching inside a hub.) now there are 3 ways i see that you can find out what say i have.
1. go into a hub, and download my filelist.
2. sniff the wire for down/up-loads
3. and sniff what i search for/what other people search me for.
now obvisily weeding out evil bots sendt by our evil corporate overloads (read: isps) is the hub operators job.
and when your inside a hub, the hub isent supposed to broadcast search replies to everybody inside the hub. (this may be wrong, as i dont know excatly how the protocol works. but am pretty shure it works this way anyway.) only a protocol change can fix this tho.
bots joining a hub and useing a active search/downloading filelists is the ops job to handle(ban).
but heres what am thinking: (obvisily the hub software has to support this too)
when you join a hub, you use RSA to get the current AES key the protocol is encrypted on. and for the never clients to just add a E:T(rue) to their description tag.
which whouldent break older-clients who could still just log on. and whuld still get normal unencrypted udp since they dont have a E:T in their tag.
and for file-transfers clients whould just generate a normal RSA private/public key and use some light/heavy-weight (depending on paranoia level) .. which can be turned off.
i know atleast if i had a 100mbit link i whouldent want it to have 30-40-50% unused because the file transfers are demaning too mutch from the cpu. but manadatory encryption of the protocol stuff should be done. cause then the MITM cant see what your up/down-loading without capturing the whole file and hashing it and compareing it too a database (this asumeing that the filename isent transported unencrypted in the client --> client stream, which should be encrypted just as everything in the hub --> client, client --> hub bit)
by say just adding a function that wraps around the send/recv function i.e instead of just
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. */
![Smile :)](./images/smilies/icon_smile.gif)
now did that make any sence?
please correct me if you see anything horribly wrong or just disagree with me.
--
disclaimer:
i am not a cryptologist. or a (descent) programmer. and i have never read all of the dc++ code, only 3 or 4 fragments of it. but i have however read a book about the history of cryptography, and i think that ought to count
![Cool 8)](./images/smilies/icon_cool.gif)
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
IMGO = in my godly opinion ?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.
SSL and TLS are useful for two reasons:
1) Designed by experts
2) Other protocols use them
-
- Posts: 1
- Joined: 2004-04-25 17:25
First, I congratulate the developers for creating such a wonderful piece of software! DC++ is by far the best p2p software but it is very puzzling that you haven't added encryption yet. I would be grateful if you could add this. I am very surprised to find out that you guys have been talking about it for a year and haven't moved on it.
In my opinion, this is the single most important missing feature to DC++. I humbly suggest you put aside working on other features and concentrate on this
. 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?
What is the current status of DC++ encryption development? Still working on it? I sure hope so.
Maybe you could add encryption in stages. Start out with something simple and work from there. Chefle brought up a great point in the post that got moved here (don't understand why it was moved, seemed right on point...) . For now, we can secure the hub to client transfers on our own with stunnel. If you guys could start with p2p encryption, that would be wonderful. We don't even have to have certificates or any kind of protection against man in the middle attacks. Just do some basic public key exchanges in the open between peers and use those keys to encrypt. That would be a quantum jump in protection above what we have now. How about just doing that basic step and then adding more in the future?
In my opinion, this is the single most important missing feature to DC++. I humbly suggest you put aside working on other features and concentrate on this
![Smile :)](./images/smilies/icon_smile.gif)
What is the current status of DC++ encryption development? Still working on it? I sure hope so.
Maybe you could add encryption in stages. Start out with something simple and work from there. Chefle brought up a great point in the post that got moved here (don't understand why it was moved, seemed right on point...) . For now, we can secure the hub to client transfers on our own with stunnel. If you guys could start with p2p encryption, that would be wonderful. We don't even have to have certificates or any kind of protection against man in the middle attacks. Just do some basic public key exchanges in the open between peers and use those keys to encrypt. That would be a quantum jump in protection above what we have now. How about just doing that basic step and then adding more in the future?
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
There's yaSSL, which is GPL and doesn't rely on OpenSSL...
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us