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
Code: Select all
Code: Select all
/* 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. */
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.
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