Encryption?
Moderator: Moderators
-
- The Creator Himself
- Posts: 296
- Joined: 2003-01-02 17:15
Encryption?
Here's another goodie I'm planning - client to client encryption...The way I see it it will be done the standard way, i e first a secret temporary key exchange using pk type encruption, and then using the secret key with a fast encryption algorithm to encrypt all data...
My question is, does anyone have any experience with this? I can't decide on the exact algorithms to use, and whether to use something standard like openssl (which i don't like, the compressed source code distribution is 2.2 megs, bloat!!!), another library, or cook something on my own...suggestions?
My question is, does anyone have any experience with this? I can't decide on the exact algorithms to use, and whether to use something standard like openssl (which i don't like, the compressed source code distribution is 2.2 megs, bloat!!!), another library, or cook something on my own...suggestions?
I would definitely cut only the needed parts from some open-source crypto lib and not include a bloated one.
Some candidates:
* Crypto++, http://www.eskimo.com/~weidai/cryptlib.html, probably too large but rather complete
* Nettle, http://www.lysator.liu.se/~nisse/nettle/nettle.html, smaller but has got most of what you'll need and you can pick only the parts you need
I would probably go for ElGamal or RSA with 1024 or 2048 bit keys for the pk part and then AES with 256 bits keylength. Speed is not really a problem on desktop machines so why use smaller key?
Nettle is nice since you got Yarrow in there for pseudo-rand nums.
So rip out Yarrow, AES and RSA from nettle and off you go...
Some candidates:
* Crypto++, http://www.eskimo.com/~weidai/cryptlib.html, probably too large but rather complete
* Nettle, http://www.lysator.liu.se/~nisse/nettle/nettle.html, smaller but has got most of what you'll need and you can pick only the parts you need
I would probably go for ElGamal or RSA with 1024 or 2048 bit keys for the pk part and then AES with 256 bits keylength. Speed is not really a problem on desktop machines so why use smaller key?
Nettle is nice since you got Yarrow in there for pseudo-rand nums.
So rip out Yarrow, AES and RSA from nettle and off you go...
(Jay! I'm back. ;-)
First off, I think encryption is a good idea. If for no other reason than a lot of people are paranoid and having an already established encryption scheme will alliviate the demand for 3rd party addons instead. (Creating even more interoperability difficulties.)
You mention PK distribution, do you think this is actually needed? A lot of protocols support session keys, eg SSL. This would mean that a rather big and cumbersome part would be avoided. (Key management is not trivial.)
Then comes the question of what to encode. Protocol data should be encrypted naturally, this is the important part. Encrypting all file transfers might be redundant, so perhaps a way of selecting "paranoia level" would be good? Also remember the golden rule in cryptography that this also requires a compression scheme for all transfers. Particularly if protocol data is encrypted with the same key as file data. Otherwise that is a big potential exploit.
As I mentioned previously PK might be a bit overkill, but if it is included why not use it for more things? Having a PK in the system would mean that we could support authentication and signing of data as well. Eg the bzip filelists could be signed by the sender which would later allow for secure redistribution of them. (Naturally this is hypothetical, just pointing out that a PK system allows for more than pure encryption.)
When it comes to what particular algorithm to use it might be beneficial to use an established protocol such as SSL or SSH to base on. This ensures that no mistakes are made on the pre-encryption level. (This is were most mistakes are done.) In Java it is very simple to add SSL to an application. I don't know how much more work it is with C++ though.
It's probably good if the actual algorithm used (DES, Blowfish, AES etc.) is not set in stone. Most protocols allow for auto-negotiation of encryption schemes.
First off, I think encryption is a good idea. If for no other reason than a lot of people are paranoid and having an already established encryption scheme will alliviate the demand for 3rd party addons instead. (Creating even more interoperability difficulties.)
You mention PK distribution, do you think this is actually needed? A lot of protocols support session keys, eg SSL. This would mean that a rather big and cumbersome part would be avoided. (Key management is not trivial.)
Then comes the question of what to encode. Protocol data should be encrypted naturally, this is the important part. Encrypting all file transfers might be redundant, so perhaps a way of selecting "paranoia level" would be good? Also remember the golden rule in cryptography that this also requires a compression scheme for all transfers. Particularly if protocol data is encrypted with the same key as file data. Otherwise that is a big potential exploit.
As I mentioned previously PK might be a bit overkill, but if it is included why not use it for more things? Having a PK in the system would mean that we could support authentication and signing of data as well. Eg the bzip filelists could be signed by the sender which would later allow for secure redistribution of them. (Naturally this is hypothetical, just pointing out that a PK system allows for more than pure encryption.)
When it comes to what particular algorithm to use it might be beneficial to use an established protocol such as SSL or SSH to base on. This ensures that no mistakes are made on the pre-encryption level. (This is were most mistakes are done.) In Java it is very simple to add SSL to an application. I don't know how much more work it is with C++ though.
It's probably good if the actual algorithm used (DES, Blowfish, AES etc.) is not set in stone. Most protocols allow for auto-negotiation of encryption schemes.
Oh it's trivial. You just have to encrypt the IP address used in DC and then put some garbage in your IP headers.
Unfortunately decryption is a bit hairier.
Seriously though. Encryption would be a requirement if you wanted to do a "package bouncing network" which could then make you more or less anonymous.
And please notice that I haven't been even in the least sarcastic in this post. It took a /lot/ of effort. ;-)
Unfortunately decryption is a bit hairier.
Seriously though. Encryption would be a requirement if you wanted to do a "package bouncing network" which could then make you more or less anonymous.
And please notice that I haven't been even in the least sarcastic in this post. It took a /lot/ of effort. ;-)
-
- Forum Moderator
- Posts: 58
- Joined: 2003-01-03 11:30
- Location: Québec, Canada
- Contact:
-
- Forum Moderator
- Posts: 58
- Joined: 2003-01-03 11:30
- Location: Québec, Canada
- Contact:
Well...Iceman[grrrr] wrote:for example, your ISP won't be able to check what you are currently getting if they didn't get the key...
I don't know, but my guesstimate is that it would be illegal (or invalid evidence) to tap someone's traffic... even if it was legal, the usual way that people get disconnected from their ISP, is that a anti piracy organisation finds the user on the sharing networks by going there (and what does encryption help then..). It would not make sense for ISP's to disconnect users by actively searching for them - they know that people download stuff - thats a big buisness point for them!
The exception would be schools and stuff like that, it would make sense if they sniffed..
Thats what I think, anyway
-
- Forum Moderator
- Posts: 58
- Joined: 2003-01-03 11:30
- Location: Québec, Canada
- Contact:
Here in sweden, the ISP is contacted by the antipiracy organisation, who then contacts the user, and tells them to stop sharing. Usually unsharing will solve everything, and nothing further happens. If the user keeps sharing, the ISP is likely to disconnect you. So the ISP does something- but only when they need to, thats my point.. as for downloading stuff, i heard that there is not yet a law good enough to do anything about it.. sharers are the target right now
-
- Posts: 9
- Joined: 2003-01-04 12:41
Arne,
Have you ever thought about client-hub authentication? Scriptwriters all across the community are doing the weirdest things to seek and destroy fake sharers, with moderate success, and nasty side effects. If a robust means of client validation could be constructed, the whole issue would simply disappear.
Not sure if this can be done at all in open source, though. Common sense tells me no, but then encryption has always been a black art to me
Have you ever thought about client-hub authentication? Scriptwriters all across the community are doing the weirdest things to seek and destroy fake sharers, with moderate success, and nasty side effects. If a robust means of client validation could be constructed, the whole issue would simply disappear.
Not sure if this can be done at all in open source, though. Common sense tells me no, but then encryption has always been a black art to me
Hello,
i have add client<->client encryption to dcgui. I use the ssl lib to setup a encrypted line after the "$key" cmd. The new "$Supports"-parameter is "SSL".
Partial-Download-Support:
Can dc++ support partial downloads ? I use dcgui with a modified "$Get"-command: "filename$pos$size". The new $Supports-parameter is "CHUNK".
Best Regards
Mathias
i have add client<->client encryption to dcgui. I use the ssl lib to setup a encrypted line after the "$key" cmd. The new "$Supports"-parameter is "SSL".
Partial-Download-Support:
Can dc++ support partial downloads ? I use dcgui with a modified "$Get"-command: "filename$pos$size". The new $Supports-parameter is "CHUNK".
Best Regards
Mathias
I think a distinction is needed here between "Security" and "Sender Anonymity".
Security: Client Alice is sending file X to Client Bob. Alice's evil ISP SysOp Eve is trying to discover what files Alice is sending by watching all the packets coming from here machine. Having a secure connection (i.e. encrypting everything send to Bob) prevents Eve from looking at what is inside the packets.
Sender Anonymity: Nomatter what Bob does (e.g.: edits the source of his client, snoops on his incoming connections and packets etc.), there is no way he can tell who is sending him the file.
Preventing the BSA, MPAA and RIAA from finding you are sharing illegal content requires sender anonymity, NOT security. It relies on having a secure connection, but a secure connection does not guarantee sender anonymity.
Sender anonymity is what we really need to protect the file sharing community from attack. It is, however, extremely difficult to achieve without incurring massive bandwidth overheads.
Hopefully, someday we'll achieve this. Encrypting all the messages is the first step we need to get there.
On a side note: I think that the distribution of the clients' public keys is best done by the hub...
Security: Client Alice is sending file X to Client Bob. Alice's evil ISP SysOp Eve is trying to discover what files Alice is sending by watching all the packets coming from here machine. Having a secure connection (i.e. encrypting everything send to Bob) prevents Eve from looking at what is inside the packets.
Sender Anonymity: Nomatter what Bob does (e.g.: edits the source of his client, snoops on his incoming connections and packets etc.), there is no way he can tell who is sending him the file.
Preventing the BSA, MPAA and RIAA from finding you are sharing illegal content requires sender anonymity, NOT security. It relies on having a secure connection, but a secure connection does not guarantee sender anonymity.
Sender anonymity is what we really need to protect the file sharing community from attack. It is, however, extremely difficult to achieve without incurring massive bandwidth overheads.
Hopefully, someday we'll achieve this. Encrypting all the messages is the first step we need to get there.
Making the encryption scheme public knowledge has no effect as you still need to know the key used in order to decrypt it.TheekAzzaBreek wrote: Not sure if this can be done at all in open source, though. Common sense tells me no, but then encryption has always been a black art to me
On a side note: I think that the distribution of the clients' public keys is best done by the hub...
-
- The Creator Himself
- Posts: 296
- Joined: 2003-01-02 17:15
Well, it's security I'm after, and some fun implementing...
As to SSL, I would use it if there was some small and nimble easy to use implementation, but all I find is openssl which is big, cumbersome and so on (hm...I actually used it once a few years ago =)...
By public key system I meant the kind of session keying that ssl uses, i e use a public key to transfer a temporary session key, then encrypt everything with a normal crypto like aes or 3des using the session key...no need to involve the hub in other words...
it would of course be of interest to use the keys to validate users, for people that have validation needs as well...then, real public keys that are distributed in a good way would make sense...
As to SSL, I would use it if there was some small and nimble easy to use implementation, but all I find is openssl which is big, cumbersome and so on (hm...I actually used it once a few years ago =)...
By public key system I meant the kind of session keying that ssl uses, i e use a public key to transfer a temporary session key, then encrypt everything with a normal crypto like aes or 3des using the session key...no need to involve the hub in other words...
it would of course be of interest to use the keys to validate users, for people that have validation needs as well...then, real public keys that are distributed in a good way would make sense...
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
freenet
The 'D' in 'DC' is for 'direct'...
Well I think if you add anonymity to DC++ you'll get something like freenet. And freenet already does exist: http://freenetproject.org/
Well I think if you add anonymity to DC++ you'll get something like freenet. And freenet already does exist: http://freenetproject.org/
How about Microsoft's TLS implementation? This might end up being a platform-dependent piece of DC if that's done, though. Another alternative is to use the GNU TLS library; the only major disadvantage so far is that I haven't had any luck getting it to compile on Windows (anyone who wishes to try needs to get libgcrypt compiling first, for it is a GNU TLS dependency).
I know this thread is almost 2 months old but I feel encryption is becoming an increasingly important as more DirectConnect networks are monitored.
File Transfers should be encrypted between clients to prevent "digital finger printing". A read about a technology where they are monitoring files transfered between users (Our University does this). Perhaps some "junk" could be thrown into the file to make finger printing more difficult?
I'm very interested in any type of truely secure and private file sharing technology.
File Transfers should be encrypted between clients to prevent "digital finger printing". A read about a technology where they are monitoring files transfered between users (Our University does this). Perhaps some "junk" could be thrown into the file to make finger printing more difficult?
I'm very interested in any type of truely secure and private file sharing technology.
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
Well, if you think your university is groking the DirectConnect protocol, they probably have a PacketShaper. I don't think it monitors the file content of transfers, persay, but it does understand DC in general.
If you're truly a privacy buff, freenet is the way to go. I don't think it's focused on the same types of files that you'll see on DC though.
If you're truly a privacy buff, freenet is the way to go. I don't think it's focused on the same types of files that you'll see on DC though.
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
Hm, encryption is fun --> More bloat to an already bloated protocol implementation.
And, what do we actually gain by adding it?
And, what do we actually gain by adding it?
I wrote QuickDC - A DC++ compatible client for Linux and FreeBSD.
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
Why? To help people who are paranoid about illegal activities to gain a false sense of security. There's a second classs of people who are genuinely interested in their own privacy and want to erect as many barriers to people snooping on them as possible - these are the same type of people who will use PGP to encrypt all of their email, not just ones that might contain private information.
Public hubs wouldn't benefit much from SSL hub <-> client encryption, as anyone can come in, search, and get file lists. Hubs requiring registered users are pretty well protected against that already, but both gain protection from your ISP or other upstreams sniffing you - however likely (and illegal without a warrant) that is.
But that's my cynical take on the feature.
Public hubs wouldn't benefit much from SSL hub <-> client encryption, as anyone can come in, search, and get file lists. Hubs requiring registered users are pretty well protected against that already, but both gain protection from your ISP or other upstreams sniffing you - however likely (and illegal without a warrant) that is.
But that's my cynical take on the feature.
But if my ISP really want to snif my trafic it's trivial for them to do a man in the middle attack.
- Who on DC would buy an SSL certificate?
- Who on DC would buy an SSL certificate?
I wrote QuickDC - A DC++ compatible client for Linux and FreeBSD.
Heh it is hard to believe, that ISPs would have resources to do man in the middle attacks to all your encrypted connections Now they're making problems because they were asked to do it and it is trivially simple to make problems. It is always worth making barriers just to eat oponents resources.Dj_Offset wrote:But if my ISP really want to snif my trafic it's trivial for them to do a man in the middle attack.
- Who on DC would buy an SSL certificate?
Additionally sniffing encrypted transactions is still illegal in most countries without asking law-court.
In the age of super-boredom/hype and mediocrity/celebrate relentlessness/menace to society --KMFDM
Sure it's illegal, but in those countries it's still illegal to snif your trafic. If they realy want to sniff _your_ trafic it should be no problem redirecting _your_ transactions via a transparent proxy (could be a cheap freenix box) and you will not notice it unless you actually check the ssl keys (through a trusted third party).yilard wrote:Heh it is hard to believe, that ISPs would have resources to do man in the middle attacks to all your encrypted connections Now they're making problems because they were asked to do it and it is trivially simple to make problems. It is always worth making barriers just to eat oponents resources.Dj_Offset wrote:But if my ISP really want to snif my trafic it's trivial for them to do a man in the middle attack.
- Who on DC would buy an SSL certificate?
Additionally sniffing encrypted transactions is still illegal in most countries without asking law-court.
- You've essentially gained nothing.
Like someone pointed out before, use freenet if you don't feel comfortable with the nature of DC today.
I wrote QuickDC - A DC++ compatible client for Linux and FreeBSD.
-
- Posts: 202
- Joined: 2003-01-06 06:22
- Location: Salford, England.
- Contact:
Interesting thread!
Yeah, i think encryption would be useful on some parts of dc... the protocol especially.
Another thing would be to encrypt an individual clients dc++ favourites list! There are reports of people hacking OP's box's, and stealing their OP passwords to reak havok on their hub..
Coul the favourites file be encrypted to only operate on the machine that it was created for? or on one that has a licence or something?
Yeah, i think encryption would be useful on some parts of dc... the protocol especially.
Another thing would be to encrypt an individual clients dc++ favourites list! There are reports of people hacking OP's box's, and stealing their OP passwords to reak havok on their hub..
Coul the favourites file be encrypted to only operate on the machine that it was created for? or on one that has a licence or something?
You could encrypt the favourites file with a symmetric cipher requireing a password to decrypt it (each time you start the DC client).
- But this is implementation specific stuff. I don't see the point in protocol extensions for encryption.
<paranoia>
- If one would need crypto, I vote for using SSL (so we don't have to change the protocol significantly)
A hublist could contain SSL keys for each hub, and each hub could contain public keys for each user (for example via the description).
The clients and hubs will need to know the public key of the hublist server (which is the trusted third party here).
The hublist is signed and the client verifies it is ok. The hubs connect to this server and notifies it about it's presence (via an encryptet channel).
</paranoia>
- But this is implementation specific stuff. I don't see the point in protocol extensions for encryption.
<paranoia>
- If one would need crypto, I vote for using SSL (so we don't have to change the protocol significantly)
A hublist could contain SSL keys for each hub, and each hub could contain public keys for each user (for example via the description).
The clients and hubs will need to know the public key of the hublist server (which is the trusted third party here).
The hublist is signed and the client verifies it is ok. The hubs connect to this server and notifies it about it's presence (via an encryptet channel).
</paranoia>
I wrote QuickDC - A DC++ compatible client for Linux and FreeBSD.
My main issue with SSL is that (1) implementing such a complex protocol oneself, especially when openssl has had such security issues and was written by more competent people than many in this thread (including me), is stupid., and (2) there are no GPL-compatible libraries for it I've found on Windows.
Fix that, and I'd be thrilled with SSL (or TLS, its successor).
Fix that, and I'd be thrilled with SSL (or TLS, its successor).
Implementing it should be fairly easy with BSD sockets or winsock... by putting "SSL_" in front of each socket API call - ok, it's a [em]little[/em] more than that .cologic wrote:My main issue with SSL is that (1) implementing such a complex protocol oneself, especially when openssl has had such security issues and was written by more competent people than many in this thread (including me), is stupid., and (2) there are no GPL-compatible libraries for it I've found on Windows.
Fix that, and I'd be thrilled with SSL (or TLS, its successor).
The security holes have been in the OpenSSL libraries, not in the API (afaik).
Don't link it in statically, but use DLL's. If you encounter any security holes in that DLL, just replace it. - The people who need it for DC are probably paranoid enough to figure out that themeselves anyway (or atleast paranoid enough to upgrade)...
I don't see why OpenSSL is any more non-GPL compatible on Windows than any other product - My interpretation of the OpenSSL issue is that you don't have true GPL on windows as you compile and link in alot of closed source windows libraries.
That being said there are several well known SSL libraries.
- Mozilla's SSL libraries (GPL'ed and MPL'ed)
- Microsoft has their own libraries in NT/2K/XP (probably a licensing issue)
I wrote QuickDC - A DC++ compatible client for Linux and FreeBSD.
Encryption?
Why not use simple xor encryption?
Its easy, fast and, simple.
Its easy, fast and, simple.
And what about the encryption key?
I wrote QuickDC - A DC++ compatible client for Linux and FreeBSD.
suddenly, the importance of encryption becomes clear.. the swedish ISP's has turned to the "trafic shaping" company NetIntact and their product PacketLogic that analyze the traffic and limits p2p traffic!
"Ett förbud resulterar enligt operatörerna bara till att fildelningsprogrammen börjar kryptera sin trafik och då blir näst intill omöjlig att upptäcka."
Translated:
"A ban against filesharing and p2p applications will only make the p2p-apps to implement encryption and then it becomes impossible to detect, according to the ISPs"
any progress arne?
"Ett förbud resulterar enligt operatörerna bara till att fildelningsprogrammen börjar kryptera sin trafik och då blir näst intill omöjlig att upptäcka."
Translated:
"A ban against filesharing and p2p applications will only make the p2p-apps to implement encryption and then it becomes impossible to detect, according to the ISPs"
any progress arne?
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 have been trying to look for encryption for chat and file shares. Yet I was told on another forum that you'd have to change the client/server software. Isn't there a way to kind of add-in a plugin of somesort? Like a scrypt that leads to encryption on the servers?
Also what kind of encryption would they use? I know ssh is 128 bit.. but would anyone want to go higher?
Also what kind of encryption would they use? I know ssh is 128 bit.. but would anyone want to go higher?
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
OH MY FUCKING FLAMING LORD, QUALITY OF SERVICE!!cyberal wrote:suddenly, the importance of encryption becomes clear.. the swedish ISP's has turned to the "trafic shaping" company NetIntact and their product PacketLogic that analyze the traffic and limits p2p traffic!
Americans (especially college students) have had to deal with it for a while, and only when Swedes see the problem does it become a problem?
This is a good natured jibe, but it's got a real point.
And as Sandos pointed out in-hub-discussion, you can encrypt the traffic, but you can't hide the fact that it's a huge amount of traffic. Someone quoted the ifgure of 95% of all (swedish?) traffic is filesharing.
-
- Posts: 147
- Joined: 2003-01-04 02:20
- Location: Canada http://hub-link.sf.net
- Contact:
There are a bunch of Swedes who want upload limiting already due to the inherent problems with ADSL and maxing your upload. Personally I think this should be solved at the network layer, not the application layer.
As for QoS/rate limiting, the PacketLogic has existed for quite a while now, but lately universities and ISPs have begun writing new rules, and enforcing them. Can't say I blame the universities, but the ISPs really should know better. Though one ISP (Telia) has obviously gotten what it's about - their PR person, when asked about rate limiting, filtering et c, said something along the lines of "We don't take responsibility for what is transmitted over our network. We just move bits. If the postal service was responsible for something sent in the mail, you'd think that ludicrous. We're just looking at ways to give everyone what they're paying for.".
That is the kind of attitude I'd like ISPs to take. Still, I doubt many will, and therefore, encryption is needed in DC++.
As for QoS/rate limiting, the PacketLogic has existed for quite a while now, but lately universities and ISPs have begun writing new rules, and enforcing them. Can't say I blame the universities, but the ISPs really should know better. Though one ISP (Telia) has obviously gotten what it's about - their PR person, when asked about rate limiting, filtering et c, said something along the lines of "We don't take responsibility for what is transmitted over our network. We just move bits. If the postal service was responsible for something sent in the mail, you'd think that ludicrous. We're just looking at ways to give everyone what they're paying for.".
That is the kind of attitude I'd like ISPs to take. Still, I doubt many will, and therefore, encryption is needed in DC++.
huh? I would change that sentence to, "only when it becomes a problem in sweden, cyberal see that it is a problem". If this is huge where you live, I leave it up to you to tell us Gargoyle!GargoyleMT wrote:Americans (especially college students) have had to deal with it for a while, and only when Swedes see the problem does it become a problem?
You (read sandos) are ofcourse correct, hiding the huge traffic amount can not be done, but I think that the ISPs (atleast the swedish ones) is satisfied with limiting just known p2p protocols for now (fasttrack etc). Limiting unknown traffic is a big step for them, question is if they even CAN do it with current custumer agreements?..
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
LibTomNet, apparently, has been recently released, and though he "STRONGLY [RECOMMENDS] against people using this in field systems", it looks promising nonetheless.
I should probably clarify, to preempt the 'yeah, but you can't trust the protocol, it hasn't been analyzed' posts:
I know.
I/one can't trust the protocol, and it hasn't been analyzed outside of a couple of mailing list posts written in a few minutes (though the flaws they've pointed out have been fixed).
That said, it's the first bit of code I've found to pop up that meets the following criteria:
I know.
I/one can't trust the protocol, and it hasn't been analyzed outside of a couple of mailing list posts written in a few minutes (though the flaws they've pointed out have been fixed).
That said, it's the first bit of code I've found to pop up that meets the following criteria:
- License-compatible with the GPL (OpenSSL requires a license exemption it appears likely will not be added).
- In a library form usable by another program (zebedee would otherwise fit, but it was quite obviously not designed with this in mind, and likely hasn't been intensively analyzed either, leading to no particular advantage over LibTomNet.)
- Is portable to various types of Unix and Windows. (Which rules out Microsoft's TLS implementation.)
- This 'requirement' may be optional, but I don't see crypto in DC happening without it due to compatibility reasons: it's possible to hand libtomnet an already established socket, once it's been discovered that the other end is capable of encryption, whilst allowing for the same socket to be used unencrypted if it turns out the other end doesn't support it.
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
I don't have much to add to the above post, it seems pretty sensible. The concern I have is with packeteer. If client to client transfers become mostly encrypted, will they not be able to still tag us by the initial handshake?
I'm also curious (because I know nothing of the subject) if encrypted traffic provided by the library you mention is indistinguishable from http-over-ssl traffic, or something else that a University might not want to block. Even if it appears the same, transfers can probably be tagged by their length... but there has to be a line of what's "good enough" for now/initially. I think your post sums it up pretty well.
I'm also curious (because I know nothing of the subject) if encrypted traffic provided by the library you mention is indistinguishable from http-over-ssl traffic, or something else that a University might not want to block. Even if it appears the same, transfers can probably be tagged by their length... but there has to be a line of what's "good enough" for now/initially. I think your post sums it up pretty well.
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
This does not seem appreciably different from the challenge-response filters that some people have set up to protect their email from spammers. Sure, it works, but what about all the collateral damage?zurf wrote:Why not make a similar system that some websites use to stop bots, you get a picture with a code that you need to type in before you can get the filelist or start a download from a user via search.
(I'm not sure your system could work, given the largely automated way in which users expect to operate.)
Hmm...Just wondering ... Is there still being worked on encrypted transfers ? Or is this a plan for the future..?
The reason im asking. is that more ISP's (like in the UK) is getting more and more agressive about sniffing what the users transfer and even selling the info to people like RIAA. This means that the request for upped security is building up fast..
The reason im asking. is that more ISP's (like in the UK) is getting more and more agressive about sniffing what the users transfer and even selling the info to people like RIAA. This means that the request for upped security is building up fast..