Encryption?

Technical discussion about the NMDC and <a href="http://dcpp.net/ADC.html">ADC</A> protocol. The NMDC protocol is documented in the <a href="http://dcpp.net/wiki/">Wiki</a>, so feel free to refer to it.

Moderator: Moderators

arnetheduck
The Creator Himself
Posts: 296
Joined: 2003-01-02 17:15

Encryption?

Post by arnetheduck » 2003-01-04 15:57

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?

ender
Posts: 224
Joined: 2003-01-03 17:47

Post by ender » 2003-01-04 17:21

DCgui has some kind of encryption (for chat) planned... Maybe you could contact it's author...

Windrider
Posts: 4
Joined: 2003-01-03 10:55

Post by Windrider » 2003-01-05 13:03

Mmm you might try using AES (aka Rjaendel) and something like El Gamal for key distribution. AES is fast, has a decent security and I remeber seeing distributions of it less than 100Kb long compressed.

coma
Posts: 5
Joined: 2003-01-05 16:33

Post by coma » 2003-01-05 17:04

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... ;)

eHast
Posts: 18
Joined: 2003-01-09 02:36
Location: Lund, Sweden

Post by eHast » 2003-01-09 10:38

(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.

Locutus
Posts: 21
Joined: 2003-01-05 15:25

Post by Locutus » 2003-01-09 13:07

It would be extreamly nice to have ones IP address encrypted. The main reason this is so people can be 100% anonymous.

I see no reason in encrypting file transfers.
Web-Programmer - Application Developer

aDe
Forum Moderator
Posts: 138
Joined: 2003-01-07 09:14
Location: SE
Contact:

Post by aDe » 2003-01-09 13:20

Locutus wrote:It would be extreamly nice to have ones IP address encrypted. The main reason this is so people can be 100% anonymous.
If it only was that easy :) :) :)

eHast
Posts: 18
Joined: 2003-01-09 02:36
Location: Lund, Sweden

Post by eHast » 2003-01-09 13:44

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. ;-)

Iceman[grrrr]
Forum Moderator
Posts: 58
Joined: 2003-01-03 11:30
Location: Québec, Canada
Contact:

Post by Iceman[grrrr] » 2003-01-10 07:14

Locutus wrote:It would be extreamly nice to have ones IP address encrypted. The main reason this is so people can be 100% anonymous.
For people to connect to you, they need to know your IP.
DC++ QoS Person

the_bean
Posts: 3
Joined: 2003-01-06 11:37

Post by the_bean » 2003-01-12 10:24

And exactly what good would come out of encrypting the file transfers ?

"Yes now noone besides the uploader and me knows what I'm downloading. Just like before."

oh well it keeps the cpu warm.
Anytime is coffee time !

Iceman[grrrr]
Forum Moderator
Posts: 58
Joined: 2003-01-03 11:30
Location: Québec, Canada
Contact:

Post by Iceman[grrrr] » 2003-01-12 16:40

for example, your ISP won't be able to check what you are currently getting if they didn't get the key...
DC++ QoS Person

aDe
Forum Moderator
Posts: 138
Joined: 2003-01-07 09:14
Location: SE
Contact:

Post by aDe » 2003-01-12 16:46

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...
Well...
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 :)

Iceman[grrrr]
Forum Moderator
Posts: 58
Joined: 2003-01-03 11:30
Location: Québec, Canada
Contact:

Post by Iceman[grrrr] » 2003-01-12 22:08

the ISP can be sued if they let you download illegal files and they don't do a thing, that's why they are supposed to control what you see...

at least those are the laws in Canada and I think in the Sates too...
DC++ QoS Person

aDe
Forum Moderator
Posts: 138
Joined: 2003-01-07 09:14
Location: SE
Contact:

Post by aDe » 2003-01-13 04:21

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

TheekAzzaBreek
Posts: 9
Joined: 2003-01-04 12:41

Post by TheekAzzaBreek » 2003-01-27 17:47

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

mathen
Posts: 2
Joined: 2003-01-27 17:40

Post by mathen » 2003-01-27 17:58

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

qqzm
Posts: 47
Joined: 2003-01-23 07:08

Post by qqzm » 2003-01-30 05:19

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.

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
Making the encryption scheme public knowledge has no effect as you still need to know the key used in order to decrypt it.


On a side note: I think that the distribution of the clients' public keys is best done by the hub...

arnetheduck
The Creator Himself
Posts: 296
Joined: 2003-01-02 17:15

Post by arnetheduck » 2003-01-30 06:35

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...

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2003-02-01 22:16

mathen wrote: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".
It looks like that would be a good topic for another thread... it might be lost here under the topic of encryption.

d-.-b
Posts: 1
Joined: 2003-02-01 17:26

freenet

Post by d-.-b » 2003-02-02 15:21

The 'D' in 'DC' is for 'direct'... :wink:

Well I think if you add anonymity to DC++ you'll get something like freenet. And freenet already does exist: http://freenetproject.org/

cologic
Programmer
Posts: 337
Joined: 2003-01-06 13:32
Contact:

Post by cologic » 2003-02-07 19:56

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).

chubs
Posts: 1
Joined: 2003-04-04 03:26

Post by chubs » 2003-04-04 03:31

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.

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2003-04-04 07:48

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.

Brian
Posts: 31
Joined: 2003-04-04 13:28
Location: Ontario, Canada
Contact:

Post by Brian » 2003-04-05 08:37

i made an entirely encrypted DChub before and it worked fine wish i still had it though it was a great hub

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2003-04-05 08:46

You could likely affect the same outcome by using stunnel and one of the linux DC hub daemons, with appropriate wizardry client side.

Dj_Offset
Posts: 48
Joined: 2003-02-22 19:22
Location: Oslo, Norway
Contact:

Post by Dj_Offset » 2003-04-05 11:16

Hm, encryption is fun --> More bloat to an already bloated protocol implementation.

And, what do we actually gain by adding it?
I wrote QuickDC - A DC++ compatible client for Linux and FreeBSD.

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2003-04-06 08:03

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.

Dj_Offset
Posts: 48
Joined: 2003-02-22 19:22
Location: Oslo, Norway
Contact:

Post by Dj_Offset » 2003-04-06 12:40

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?
I wrote QuickDC - A DC++ compatible client for Linux and FreeBSD.

yilard
Posts: 66
Joined: 2003-01-11 06:04
Location: Slovakia

Post by yilard » 2003-04-06 13:07

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?
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.

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

Dj_Offset
Posts: 48
Joined: 2003-02-22 19:22
Location: Oslo, Norway
Contact:

Post by Dj_Offset » 2003-04-06 13:59

yilard wrote:
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?
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.

Additionally sniffing encrypted transactions is still illegal in most countries without asking law-court.
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).

- 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.

OLDoMiNiON
Posts: 202
Joined: 2003-01-06 06:22
Location: Salford, England.
Contact:

Post by OLDoMiNiON » 2003-06-03 07:22

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?

Dj_Offset
Posts: 48
Joined: 2003-02-22 19:22
Location: Oslo, Norway
Contact:

Post by Dj_Offset » 2003-06-03 07:46

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>
I wrote QuickDC - A DC++ compatible client for Linux and FreeBSD.

cologic
Programmer
Posts: 337
Joined: 2003-01-06 13:32
Contact:

Post by cologic » 2003-06-03 17:24

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).

Dj_Offset
Posts: 48
Joined: 2003-02-22 19:22
Location: Oslo, Norway
Contact:

Post by Dj_Offset » 2003-06-04 02:53

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).
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 ;).
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.

mytoz
Posts: 1
Joined: 2003-07-14 05:12

Encryption?

Post by mytoz » 2003-07-14 07:02

Why not use simple xor encryption?
Its easy, fast and, simple.

Dj_Offset
Posts: 48
Joined: 2003-02-22 19:22
Location: Oslo, Norway
Contact:

Post by Dj_Offset » 2003-07-14 07:23

And what about the encryption key?
I wrote QuickDC - A DC++ compatible client for Linux and FreeBSD.

cologic
Programmer
Posts: 337
Joined: 2003-01-06 13:32
Contact:

Post by cologic » 2003-07-15 14:04

ph33rm3R1AA

cyberal
Posts: 360
Joined: 2003-05-16 05:42

Post by cyberal » 2003-07-25 05:20

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? :)
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

ToxicFool
Posts: 3
Joined: 2003-03-11 18:10
Contact:

Post by ToxicFool » 2003-07-26 12:26

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?

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2003-07-27 10:55

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!
OH MY FUCKING FLAMING LORD, QUALITY OF SERVICE!!

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.

HaArD
Posts: 147
Joined: 2003-01-04 02:20
Location: Canada http://hub-link.sf.net
Contact:

Post by HaArD » 2003-07-27 11:41

I wonder... if Swedish users found that uploading strangled your ability to download do you think upload limiting would gain support? ;)

fnordpojk
Posts: 1
Joined: 2003-08-03 21:33
Location: Sweden
Contact:

Post by fnordpojk » 2003-08-03 23:03

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++.

cyberal
Posts: 360
Joined: 2003-05-16 05:42

Post by cyberal » 2003-08-04 01:57

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?
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! :)

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

cologic
Programmer
Posts: 337
Joined: 2003-01-06 13:32
Contact:

Post by cologic » 2003-09-16 16:02

LibTomNet, apparently, has been recently released, and though he "STRONGLY [RECOMMENDS] against people using this in field systems", it looks promising nonetheless.

cologic
Programmer
Posts: 337
Joined: 2003-01-06 13:32
Contact:

Post by cologic » 2003-09-16 19:49

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:
  • 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.
In the absence of any alternatives I've found, I'm going to keep watching LibTomNet to see how it matures, but I'd be quite interested for someone to come up with an more standard, analyzed, and known secure protocol implementation that conforms to the criteria I listed (or feel free to write your own, of course :wink: ).

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2003-09-19 11:28

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.

distiller
Posts: 66
Joined: 2003-01-05 18:05
Location: Sweden
Contact:

Post by distiller » 2003-11-15 03:17

Using zblock/dropping connection every x MB should solve the problem with tagging based on connection time. Initial handshake between clients is a problem though... Some friends are starting to complain, getting 5 KB/s on a 10 Mbit conenction. Traffic shaping in action for sure.

zurf
Posts: 2
Joined: 2003-12-02 05:30

Post by zurf » 2003-12-02 05:40

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.

That would atleast slow down the antipiracy agencys that rely on bots for "evidence" gathering.

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2003-12-02 12:41

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.
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?

(I'm not sure your system could work, given the largely automated way in which users expect to operate.)

Snooze
Posts: 119
Joined: 2003-01-26 13:42
Location: Denmark
Contact:

Post by Snooze » 2003-12-04 03:12

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..

Locked