Zdenek Stangl wrote:

With all due respect, Im still not sure what good is the encrypted connection for DC. I was out for longer time. Are there any troubles with anti-pirate organizations?

Well, yes. As well as new EU laws (which my country is pushing for, which is embarassing). But the most important is the privacy for users. I think it's fair to implement encryption as a basic privacy model for people no matter protocol. Big brother is getting paranoid.

Jacek Sieka wrote:

Well, this has crossed my mind a few times, I actually downloaded a few ssl libs the other day to have a look around...
In any case, while being a good (verbose) initiative, there are some technical flaws, like:
1) Reinventing a secure handshake - dangerous, it took the ssl folks 3 versions, and hopefully they knew more than us about this stuff...

Well yes, and they depend on third-party organizations like Verisign. If you site is verisign:ed then you are to be trusted... Maybe we should beg users to pay tenths of dollars for a signed certificate ;)
But I agree, handshaking is critical.

2) No perfect forward secrecy - lose the key to someone and any recorded data can be decrypted (authorities spring to mind)

Lose how? The symmetric keys are temporary for each session/connection, and never stored. How the assymetric keys are locally stored, can be made safe quite easily. However, this problem occurs to any program implementing asymmetric ciphers. In Unix you depend on filesystem rights for the private keys etc.

3) No algorithm negotiation - locked to one algorithm pair, and algorithms tend to lose credibility over the years

Today you can "choose" from a set of symmetric keys (in SSL). But AES is by far the best one afaik. I don't know of inheriting the entire ssl set of ciphers are good, would anyone ever want to use DES/3DES? It's both much slower and more insecure than AES. The same with all fishes (blowfish, twofish etc). Surely one would like Some sort of negotation though, I fully agree on that.

4) No separation between adc and encryption (what's that cid etc doing in the initial negotiation?)

The CID is there because we poor P2P users have a tendancy of switching IP numbers very frequently, and CID is used for storing public keys, just like SSH does. It's not at all necessary, but efficient and slightly increases security. So they say ;)

5) Still identifyable as ADC with all the packetfilter problems that follow

What packetfilter problems? Sure it's identifyable unless one uses a common cipher-handshake such as ssl/tls gives you. I don't have an opinion on whether this is an issue or not... Unless 'they' can read the traffic, do we care if they know what it's for? Maybe.

6) Server speaks first - in general the server shouldn't waste resources sending data until the client has made an effort

This was inteded so that hubs send their public key. Therefor one should at least trust a hub's key. Also this makes the client responsible for generating the symmetric keys. Not that this is much of a burden, but still...
Surely clients could go off first, by requesting the key, maybe by sending a TTH of the stored key (if they have one), and only if it differs hubs send their new key.

7) On a more philosofical note - who is this encryption targeted against? ISP listening in? hub listening in? neighbour on the same subnet listening in? As I read it there's one encrpytion layer between hub and client and then another one in that between clients when speaking through the hub...those are two completely separate use-cases and should thus imho be covered in separate extensions - if encrypted c-c messages through the hubs should be supported at all...

This is very interesting. Developing a fully waterproof solution is not feasible. Personally i think ISP's and authorities in general are the target of the reason for privacy.
About encrypted c-c, well, isn't this the reason for the FourCC? Hubs shouldn't care what clients send to each other, it should only broadcast B's, broadcast to actives by A's etc...? Then clients should have the possibility of sending what lookes like junk to each other, but that is encrypted traffic. This is probably only a client issue anyway.

8) No authentication - vulnerable to the good ole' man in the middle attack

Yes, you're welcome to setup an own certificate authority if you like ;)
This is actually possible. Having like the hublist-servers to be authentication servers is a possibility. It would look like a one way kerberos sollution, by depending on a third part. It makes sense, but *trying to express myself as if I were a hub developer* it adds complexity ;)

9) I can probably thing of more - these were just the first things that sprung to mind...

Well, I'm satisified that you looked into it.

Instead I was just about to do something a lot more simple with dc++ and adchpp; SSL tunneling for both c-c and c-h connections, solves all those issues above. there are a few details to be considered though, mainly regarding key distribution, i e should the hub sign keys of its users (probably not) or should all keys that can be verified by querying the user for their hash with a d message be seen as valid? One potential issue is that we can't up-negotiate the protocol to encrypted mode if we want to make it http-lookalike - which means that the server must either have a unique port open or use some ugly heurestics (or perhaps best - support only encrypted connections)...

Only support encrypted connections is by far the easiest way. Tunneling ssl, by that you mean to for example implement the openssl's ssl part, and not only its ciphers? To actually let the library handle the connections? Well, it's a possibility. I personally just dislike the so called 'certificates' that are being generated. I'm not sure they fit a p2p system. They depend on dns names and so on iirc...

Opera