dcdev mailing list

Hi all,

The topic has been active previously, but afaik we haven't united upon a
standard for encryption in ADC yet. I'm raising this issue again, with
my ideas on it, and with contribution to benchmarks. Refer to those
early ones cologic attached, they indicate that encryption is feasible.
I'll propose a scheme for an efficient encryption implementation on hubs
and clients, for hub-client and client-client communication.

INTRODUCTION
First of all, encryption on todays computers are often efficient, as
cologic showed. This is an argument for applying encryption to the ADC
protocol as a compulsory element rather than an optional one,
particularly since encryption is more or less useless if not every user
in the hub encrypts the communication. However, such a requirement must
follow some more in-depth analysis of its effects.
The user count limitation for hubs has been bandwidth throughput rather
than CPU usage, and it has been shown that an increase in user count
does not affect bandwidth linearly. In some cases CPU issues have been
taken care of by smart socket buffer pooling to respect the processor
cache. This indicates the importance of doing real-situation
simulations. I have simulated encrypted messages passing through a hub,
being decrypted and then encrypted by a few thousand different keys (to
be sent to the individual clients). I request a more accurate simulation
basis with a quite large recorded session from a hub with lots of users.
User passwords can be removed, and usernames can be changed to fakes if
necessary.
The technique with encryption has negative effects on data re-use in the
processor cache relative the non-encryption case, but I'll show that the
bottleneck for hubs will continue to be throughput limitations on
broadband connections, and not CPU throughput.

IMPLEMENTATION
The algorithms I suggest are RSA and AES(Rijndael i.e.). AES as the
symmetric cipher for encrypting/decrypting all data (between hub and
client, as well as between clients), and RSA being the asymmetric
algorithm for exchanging keys. Rijndael has some quite positive
features, for example it not only follows the AES requirements of
supporting 128, 192 and 256-bit key-sizes, it actually supports and
key-size with bit count being a multiple of 8, hence full bytes. This
can be useful for other implementations apart from the protocol. RSA is
a widely accepted algorithm, often used for symmetric key exchanges.
Both of these algorithms are part of the libssl package. This means that
implementations doesn't require large new pieces of (buggy) code, but
rather that it requires just another library. Clients today are familiar
with both zlib and bzip2. They require some sort of xml library and a
socket library unless this is written by hand. I've heard a few
frightening comments on how protocol complexity might injure hub
development, and I hope such ancient ideas are left out by now, so that
the usefulness and features one could expect from a protocol in the 21st
century aren't underestimated. However, by exporting the work to a
library for this, one can certainly not complain about complexity
issues. In Unix variants and Unix-like systems such as Linux, this is
the easiest of tasks. In debian, apt-get for libssl0.9.7 and libssl-dev.
In windows, it requires you to compile the libssl library correctly.
I've done this for those of you who want to start right ahead. The
library as well as the headers can be downloaded from here:
http://gempond.com/openssl-win32.zip
It's for vs2003, without debug-code i.e. 'release', and statically since
that will probably become most useful.
You probably know how to apply this to visual studio. I haven't actually
tested if the win32-library works, but it I'm sure it does...

SCHEME
My scheme for implementing encryption is as follows:
All parts in an ADC network (hubs and clients i.e.) must initially
generate a unique RSA key-pair (the library does this for you), just as
they also need a unique ClientID.
ADC commands, sequences and structures are untouched as they are defined
in the draft. The encryption occurs rather at socket-level than at
message level. Only the login sequence is slightly changed - key
exchange is injected before any other commands, and server has already
sent CID before it gets HSUP from client, so it shouldn't send it again.

1. Upon connection, the server (in client-hub this means the hub, in
client-client this means the callee not the caller) sends its public RSA
key Tiger-hashed (base32 encoded just as any other tiger hash unless we
can agree upon a better suggestion) followed by a newline (\n) followed
by a key-size (an integer, just as share-sizes etc are encoded) followed
by another newline (\n), followed by its CID and finally terminated with
a final newline (\n). I.e.:
TTH(RSA Public key)
Requested AES key size (the server fully decides this), e.g. 128
CID
2. The client receives this information, looks in a 'database' for the
CID to check if it has a stored copy of this particular server's (note:
hub or client) public RSA key. If it doesn't (or if it does, but the
hashed keys differ, and after the user might've been notified on this)
it sends a newline (\n). This will cause the hub to send its public RSA
key (base32 encoded also?).
Now the client stores the public RSA key bound to this CID. It generates
a random Rijndael key of the key-size sent by the server (the library
can generate this). The key-size should be (even though not required
pure algorithmly as mentioned) 128, 192 or 256 bits (openssl for
instance, requires this). This key (being unique for this connection) is
what will be used for ciphering all data sent between these parts.
3. The client encrypts the AES key by the server's public RSA-key, and
sends it to the server. The server decrypts it (and stores it as two
binary AES-objects, if implemented using openssl as I've done) in its
internal user object structure.
Now both parts have a copy of a unique 128-256 bit AES(Rijndael) key.
No one else have had the chance of stealing this on its way (I happily
ignore the man-in-the-middle attack possibility, or will someone look
into running its own DC CA, and why would we trust him/her?). Nothing is
now encrypted using RSA (which is slow), instead _everything_ is
encrypted by the AES key.
Step 4 to infinity (i.e. all future communication in this connection)
will be just as before, HSUP/CSUP and everything, but AES encrypted.

FEATURES
Further on, one could ask for and require the possibility of private
message to really be private, hence encrypted. This should be an
optional state (to not collide with "chat channels"/"group chats"). In
this case the encryption requester (the one who wants a PM to be
encrypted) requests the other part's (by nick? I'd prefer CID for key
storage as suggested above, but looking at pm in MSG in the draft, this
seems not to be possible without another message type, I hope I'm
mistaken here) public RSA key. This could be skipped if we know the
user's CID and already have his/hers public key. We must be certain
anyway, and check if the key's TTH is the same. Exactly how this could
be done is better being thought through by someone more familiar to ADC.

In the request for the other part's public RSA key, the requester can
send its own public RSA (if it assumes by looking in a
'reverse-database' that the user doesn't already know this). I'm not too
sure how this is supposed to be implemented, but it shouldn't be too
difficult. The point is to RSA-encrypt the private messages when such a
request has been made. This will mean, RSA-encrypting the text,
base32:ing it into a "text-like" string, packaging it into ADC MSG and
AES-encrypting it before sending to the hub. Double encryption i.e. But
I'm confident that this will not stress any part at all, and
RSA-encrypting private messages will never end up consuming "too much"
CPU for anybody. Well, maybe if you can type _very_ fast...

EXTENSIONS
ADC supports zlib as an extension. I see no problem with compressing
before encrypting (the plain text message is most definitely more easily
compressed, and Better compressed than an encrypted message). As a
general rule, encryption is the outer-most part of sending/receiving a
message (except for in the previous case of encrypting private
messages), and please don't forget to pad the messages to whole 16-byte
blocks, it won't entirely be encrypted otherwise!

Lastly, client-client communication is encrypted with the scheme stated
above with no exception.

VIABILITY
Now, is this viable or even feasible? It surely sounds good, but
defining it as a compulsory part of ADC (with all positive effects that
means) requires it to be fast (enough). The fact that protocol omplexity
increases drastically if encryption is optional due to agreeing on
whether to use it etc. is an argument by itself. Anyway, one basic
approach to optionality is the levels [require-not, prefer-not, prefer,
require] where level 1-4 means No communication (!), [1-2]-[1-3] means
unencrypted communication and [2-4]-4 and 3-3 means encrypted
communication. However, connecting to a hub that by itself is claiming
level 1-3, can that be considered safe? What if a few users communicate
unencrypted with the hub. My searches as well as main chats can't be
considered safe. Anyone interested in defining these things more
strictly as well as suggesting a neat implementation (especially
client-wise) on how to inform the user whether communication is safe or
not, is welcome to do so. Add a new description-tag (INF-part i.e.)?
Unless the implementation is intelligent enough to appear very clear to
even not so technically blessed users, I suggest we skip encryption
entirely, and to me that would mean a great protocol loss.

BENCHMARK
My benchmark is written in C++ (and attached to this mail), and is
compiled on Linux and linked with openssl 0.9.7 (when linking with
gcc, don't forget -lcrypto, that's the library name containing all
necessary functions - libcrypto i.e. not libssl, I use this line:
gcc -lcrypto -lstdc++ -o cbench crypto_benchmark.cpp)
If you run the benchmark on your own, change the KEY_SIZE macro in the
top of the source code for different key sizes.
The benchmark can probably be run in win32 by fairly small
justifications in the code, if any. First of all, I simulate messages
passing through a hub. They are received encrypted (with different
encryption with respect to the user who sent the message). Every message
is decrypted, and then individually encrypted and sent back to each
user. (Yes, I currently only simulate broadcast messages, they stress
ciphering the most I suppose, and I never 'send'.)
This is for stressing encryption against a large amount of keys, and
suitably corresponds to a hubs daily job. Many short strings, many
different keys, many users. In the client-client case below, I focus
on quite the opposite - Few but very large (relatively) strings and few
keys.
I once again request; A recorded hub session containing (except password
info) all messages passed through the hub for a substantial number of
seconds, and converted from DC to ADC. I'm optimistic that one of us
writes a py-script in 2 minutes for the conversion. I know of one who
has proved good py skills more than once...
The importance of using session recordings (logs) is to simulate things
like active/passive searches, user list propagation, hub-restart
situation etc...

Today client-client transfers is more or less; read from file - send -
receive - write to file. Clients should try to copy the data as little
as possible. In C/C++ cases this is fairly simple and comes naturally,
by allocating once, using pointers and sending the data from that same
address. In the case of encrypting, this becomes an even more important
issue. The openssl implementation of the symmetric Rijndael cipher can
use the same data as input and output. Therefore the same procedure can
be taken but with adding an encryption step for each block before
sending the data. Remember, strings Must be sized as multiples of 16
bytes. Pad with nulls to accomplish this at the 'end' of a message/file.
I'm unsure client-client needs more 'realistic' benchmarks than the ones
cologic gave, which are openssl's speed test.

RESULTS
I simulate a hub with 2500 users. I generate 10000 message with random
readable ASCII text at random length (between 16 and about 200
characters). A message here is a Text, its Length and a Pointer to a
user object. A user object has some Dummy information and a Pointer to
an AES key (an openssl-internal structure, actually two, one for
encryption and one for decryption).
 From the messages I randomly look at one, decrypt it, and then go
through the list of users and encrypt it against each users unique key.
I loop this behavior for 30 seconds and show how many bytes were
totally encrypted/decrypted, as well as how many messages passed through
the hub (One message equals one Incoming message sent to everybody).

Benchmark run on my server, which is a PII (Deschutes) @ 450 MHz.
Throughput:
Key-size 128 bits: 9.2 MiB/s, 29 messages/s.
Key-size 192 bits: 7.9 MiB/s, 25 messages/s.
Key-size 256 bits: 7.0 MiB/s, 23 messages/s.

Benchmark run on a server at the university, which is a P4 @ 1.7 GHz.
Throughput:
Key-size 128 bits: 29.1 MiB/s, 97 messages/s.
Key-size 192 bits: 25.6 MiB/s, 84 messages/s.
Key-size 256 bits: 23.1 MiB/s, 77 messages/s.

CONCLUSION
As far as I'm aware, most hubs today are being limited to 10 Mbit/s,
and that's the most critical bottleneck. I have shown that a simple (but
more thorough than an openssl speed test) quantitative simulation of a
hub even at 256 bits AES encryption handles more than 50 Mbit/s (7 MiB/s
x 8 bits) on an ancient machine, and on a today more regular computer
the same bit size shows well above 200Mbit/s.
I seriously don't believe one is supposed to run a messaging server for
thousands of users with fully encrypted traffic on a computer like mine,
and on the more modern ones, we see an outstanding performance well
above what's necessary on even massively loaded hubs.

For p2p transfers we have: the faster connection (broadband), the more
pressure on the computer. You need fast hardware to fully use a 100Mbit
connection, and if you use a fast computer (for example something like a
P4 1.7 GHz), then not even at the greatest key size will affect the
speed of the transfers.

In this conclusion, I discard any further slow-down due to file-handling
in clients, etc. Instead I focus on the raw ciphering speeds. I can
hardly imagine an encryption as this one to give such a negative effect
on transfer speeds and/or CPU utilization as to draw conclusions that
it's not viable, and by that I mean compulsory. In other upcoming
bandwidth-heavy and even worse - CPU-heavy - applications such as Skype
do encryption occur, and not being optional.
But if it for some reason needs to be optional, then someone should not
be able to reject secure transfers unless they also claim it in the INF,
and again, it needs its own implementation, and I'm personally not
willing of figuring that one out.

I also have ignored key-propagation for searches in the implementation
scheme, but this should not be a burden to satisfy, if we can just unite
on the very basics of encryption in the first place.

However the bandwidth results are more than convincing, the message
count could be more of an issue, therefor I request that anyone with
experience in this particular entity gives comments on this, as well as
anyone willing of sharing thoughts on this topic in general.

Opera

On Friday, March 11, 2005, 10:44:18, 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?

I think the biggest problem are content-based throttling programs that some
ISPs use - they can detect the protocol from the data sent in a connection
and then throttle more if they detect P2P. This becomes much harder to do
when encryption is set up properly.

Of course, with encryption it also becomes pretty much impossible for the
ISP to determine what you're transferring.

-- 
< Jernej Simoncic ><><><><>< http://deepthought.ena.si/ >

It's always darkest just before the lights go out.
       -- Clark's Law

--

--On fredag den 11 mars 2005 11:22 +0100 Gustaf Räntilä <[email protected]> wrote:

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.

Even if you lose your private key, the data transfered up to that point should not be compromised. This is what PFS is. An example of a protocol using PFS is IPSEC, using the Diffie-Hellman key-exchange in it's OAKLEY (RFC 2412) protocol.

See <http://www.itsecurity.com/asktecs/may201.htm> and <http://www.faqs.org/rfcs/rfc2412.html> for more info.

Surely one would like Some sort of negotation though, I fully agree on
that.

If nothing else, you want to be able to choose a new algorithm should AES be compromised.

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.

If they can separate it, they can shape or block it. We're not just aiming for privacy here - a huge part of the purpose is to make it harder for ISPs to block DC, by saying, for example, "OK, we've just made DC look exactly like HTTPS or IPSEC traffic. Now it's up to you - block or shape all traffic that looks like this, or accept the fact and move on."

Only support encrypted connections is by far the easiest way.

I agree, and I think this is the way to go. Less complexity, better privacy.

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

Nothing says you have to use X.509 just because you want to use SSL, although it's much easier that way. :)

Also, you don't have to interpret that field in the certificate as a host name if you don't want to - use it to store the CID instead?

/fnord

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

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...
2) No perfect forward secrecy - lose the key to someone and any recorded data can be decrypted (authorities spring to mind)
3) No algorithm negotiation - locked to one algorithm pair, and algorithms tend to lose credibility over the years
4) No separation between adc and encryption (what's that cid etc doing in the initial negotiation?)
5) Still identifyable as ADC with all the packetfilter problems that follow
6) Server speaks first - in general the server shouldn't waste resources sending data until the client has made an effort
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...
8) No authentication - vulnerable to the good ole' man in the middle attack
9) I can probably thing of more - these were just the first things that sprung to mind...

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

/J

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

Hi all,
See my responses below ;)

On Friday 11 March 2005 11:22, Gustaf Räntilä wrote:
(....)

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

Actually both Blowfish and Twofish are quite fast. Speaking about the former, 
also quite secure. I use Blowfish all the time for scp/sftp operations 
because it doesn't slow down transfers on fast networks, compared to 3DES.
For a general crypto benchmark see this page: 
http://botan.randombit.net/bmarks.html

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

Traffic shaping. All medium-large ISPs use this these days. A standard SSL/TLS 
connection is harder to classify as P2P oposed to other SSL connections (like 
company VPNs over SSL, etc).

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

(...)

Which again makes it easier for classification. The ISP can merely connect to 
the port see what's on there and disconnect. 

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

Well how much complexity does it add to the hub? 
The hub will merely have to register it's key to the hublist, while it still
have to register its existance to the hublist.

The complexity is added to the client that will have to check the authenticity 
of the hub by quering the CA (hublist)... (if the user is paranoid enough). 
 The hub will deal with passwords to authenticate users.

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

Sure you can, as on HTTP, try connection using plain HTTP on a HTTPS-port such 
as http://sourceforge.net:443/. You can easily delay the SSL initialization 
so that after the SUP-command is sent the server may send a special command 
requesting SSL. 

However, this adds complexity... :/

Dj_Offset, out.

-- 
Jan Vidar Krey

E-mail: [email protected]
Mobile: +47 98607328
WWW   : http://www.extatic.org/
--

Mattias Bergsten wrote:

Even if you lose your private key, the data transfered up to that point should not be compromised. This is what PFS is. An example of a protocol using PFS is IPSEC, using the Diffie-Hellman key-exchange in it's OAKLEY (RFC 2412) protocol.

Oh, so _that's_ what the 30 year old Diffie-Hellman algo is for... Well, it sure sounds reasonable. So then, what about RSA -> Diffie-Hellman -> AES(or other negotiated symmetric key)? Or simply skip the RSA part? I don't have any experience with RSA in OpenSSL, I'm not sure it'll generate everything for you (d, e, n etc), and this would be very nice not to have to do yourself.
And as I said, the private keys can easily be protected anyway. AES them with a password for instance. But maybe this is only reasonable on hubs that rarely restart.

If they can separate it, they can shape or block it. We're not just aiming for privacy here - a huge part of the purpose is to make it harder for ISPs to block DC, by saying, for example, "OK, we've just made DC look exactly like HTTPS or IPSEC traffic. Now it's up to you - block or shape all traffic that looks like this, or accept the fact and move on."

Well, to make it totally transparent as to just being unrecognizable traffic is impossible. Even if the hand-shake is extremely like HTTPS the continuous traffic is still the same. Trying too much to make it unrecognizable isn't worth it I think.

Nothing says you have to use X.509 just because you want to use SSL, although it's much easier that way. :)

Also, you don't have to interpret that field in the certificate as a host name if you don't want to - use it to store the CID instead?

Hmm, well yeah. Using the fields they way we feel is pleasing, well... Is it okey if I still just don't like certificates at all? ;)

And btw Df_Offset, ciphers like blowfish might be fast but comes with a draw-back in my opinion. It's by far too complex. In the competition for being _the_ AES algorithm, most people didn't understand blowfish, they simply didn't get the code, and the authors being open source 'hackers' had problems mathematically proving its concept. The same applies for any 'difficult' algorithm, even Rijndael being very algebraic. The more difficult it gets to understand the more dangerous it is for future flaws found by geniuses that actually understand it thoroughly.

Opera

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...
2) No perfect forward secrecy - lose the key to someone and any recorded data can be decrypted (authorities spring to mind)
3) No algorithm negotiation - locked to one algorithm pair, and algorithms tend to lose credibility over the years
4) No separation between adc and encryption (what's that cid etc doing in the initial negotiation?)
5) Still identifyable as ADC with all the packetfilter problems that follow
6) Server speaks first - in general the server shouldn't waste resources sending data until the client has made an effort
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...
8) No authentication - vulnerable to the good ole' man in the middle attack
9) I can probably thing of more - these were just the first things that sprung to mind...

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

/J

Gustaf Räntilä wrote:

Oh, so _that's_ what the 30 year old Diffie-Hellman algo is for... Well, it sure sounds reasonable. So then, what about RSA -> Diffie-Hellman -> AES(or other negotiated symmetric key)? Or simply skip the RSA part? I don't have any experience with RSA in OpenSSL, I'm not sure it'll generate everything for you (d, e, n etc), and this would be very nice not to have to do yourself.
And as I said, the private keys can easily be protected anyway. AES them with a password for instance. But maybe this is only reasonable on hubs that rarely restart.

Well, to make it totally transparent as to just being unrecognizable traffic is impossible. Even if the hand-shake is extremely like HTTPS the continuous traffic is still the same. Trying too much to make it unrecognizable isn't worth it I think.

Hmm, well yeah. Using the fields they way we feel is pleasing, well... Is it okey if I still just don't like certificates at all? ;)

And btw Df_Offset, ciphers like blowfish might be fast but comes with a draw-back in my opinion. It's by far too complex. In the competition for being _the_ AES algorithm, most people didn't understand blowfish, they simply didn't get the code, and the authors being open source 'hackers' had problems mathematically proving its concept. The same applies for any 'difficult' algorithm, even Rijndael being very algebraic. The more difficult it gets to understand the more dangerous it is for future flaws found by geniuses that actually understand it thoroughly.

Picking off technical inaccuracies that taken together suggest that designing one's own protocol is indeed tricky, and error-prone (as someone's hinted, read about SSHv1 and SSLv2. Both were, and unfortunately are, widely used.):

(1) DH doesn't imply PFS. It is neither necessary nor sufficient. Your sketches of a possible protocol elucidate essentially nothing, though, so I can't usefully comment more.

(2) Different traffic patterns might betray the nature of encrypted DC traffic despite all other masking - but, for example, forcing ISPs into doing such analysis opens them up to false positives detrimental to business, among other risks.

(3) Disliking certificates is fine. One should not, however, refuse to recognize their possible utility, and claim to be designing good crypto. (The details of this are currently unimportant, though they should be discussed.)

(4) Blowfish was never submitted as an AES candidate. Twofish was. The rest of the section strikes me dubiously too: Schneier is an open source hacker only able with difficulty to mathematically prove the concept? Read http://www.schneier.com/twofish.html ; while depending on the rigor one's looking for, they don't prove that there may never in the future be a break in an algorithm, they show that most existing techniques don't work.

-cologic