Forums General Discussion General encyption

So I set up an SSL connection with mirc. I connect to the servers as I need with openSSL connection. I also setup a private key and cert chain file on: http://www.mobilefish.com/services/ssl_certificates/ssl_certificates.php

I'm wondering.. If I use all that and start a DCC chat with someone that's also done the above, is that DCC sent plaintext or encrypted?

Are they (dcc messages) locked up just because their server connections were?

Side question, if I connected with the ssl options blank even, is that still encrypted at all to the server? If so, how and what level?

I spoke to someone on efnet #mirc that was pretty amazing, and it appears that there is nothing at this point that isn't entirely broken.

So I guess my request is.. Add AES support for mirc for DCC chats. Can it be done at all?

AES in and of itself isn't a viable encryption method for DCC. It's a symmetric cipher requiring both parties to share the same key, which of course, would require some kind of out-of-bound method of passing the key between two parties. Obviously that isn't practical. This is precisely where SSL/TLS comes in, by having an asymmetric cipher perform the key-exchange and then allowing the symmetric protocol to go ahead using the generated key. AES is one of the symmetric ciphers supported within the TLS protocol as of v1.2.

mIRC's current SSL support is for encrypting the connection between the client and the server, so yes, SSL-encrypted DCC would be nice (and such protocols are already implemented in some IRC clients I believe). This would probably best be made into a thread in the Feature Suggestions forum.

It's not really fair to say that offline key exchange isn't a practical method of exchanging keys. There are many "protocols" that use this method extensively. I'm referring to nearly every website that uses authentication on the web. Passwords are chosen and agreed upon in a secure channel before they are used to authenticate the connection in subsequent sessions. In some cases, passwords are auto-generated and given to the user via some means (usually web or email). Obviously these methods are not 100% secure (specifically the email one), but it's been used widely and successfully enough that it is certainly "practical".

There are many secure channels in which a shared key can be exchanged. Email can be one of them, if done right. There are also a lot of IM/chat protocols (including IRC, of course with its own set of baggage) that support encryption that can be used (again, if done right). This won't work for everyone, but it's certainly a viable and practical option for many people-- I'd wager that it's practical for most people who know each other well enough to chat via DCC-- and have the need for an encrypted connection to boot.

Just because insecure methods are widely used doesn't make them any less insecure. When I said OOB key exchanges weren't practical I was of course referring to an actual secure method of exchange. In a conversation about secure DCCs, or secure anything for that matter, I'm going to go ahead and assume that any reference to a solution will actually fulfill the 'secure' aspect of it. If we're going to allow security theatre as an acceptable solution then let's just go ahead and tell everyone to use ROT-13 for untappable communications.

In the cases where web or e-mail based authentication is performed in a truly secure manner it's almost always by using... SSL to wrap the insecure protocol so it seems ridiculous to imply that not using SSL for DCC is acceptable because we can instead use AES combined with users manually generating their own keys and then manually launching separate applications to transfer those keys via a different protocol which ultimately uses the exact same transport layer protocol to secure the data as I'm suggesting can (and should) be retained within the chat mechanism itself.

Email is not always wrapped in SSL. What happens in most of these cases is you're given a temporary password to change-- the password is usually sent in cleartext, and if the user doesn't check their email with encrypted POP/IMAP, it's open for all. Of course, it works just fine in 99.99% of cases, and I call that "practical".

Security is not a boolean value, it's a spectrum, and there *is* such a thing as "secure enough". Your assumption is that we're not talking "security" unless we're talking "untappable communication". That's really not how it works. I also didn't say things were completely secure, I said they were practical (as in secure enough), and simply responded because you said it was not. Trying to achieve 100% security is a waste of time, or at least, not required by most users. I think it would be great for mIRC to support async encryption mechanisms (SSL), I just think it's silly to discount symmetric encryption because "it's not entirely secure". mIRC supports SSL connections for IRC, and those are usually not 100% secure (all data is leaked between links, or non SSL clients). There are many cases where users have the ability to exchange keys, in secure [enough] forms, "offline". Personally, I would manage fine with that (and many people do, with existing scripts).

I still agree that SSL is better, though.

I wasn't really meaning anything top secret level. Just maybe personal convos with DCC people that you may know well. Enough that'll keep any snoops in between from getting any personal info is enough. I realize that a DCC itself is relatively secure, but something encrypted would always help. It should be transparent for performance using AES or Twofish or something.

I'd like a public key style as well, but idea was a little simpler. Just having the option to start up a conversation with a stored encrypted pre-shared key (say over the phone hushmail or whatever) that is pretty invisible once setup.

Using a symmetric key is much easier to implement as a script, which effectively makes it much easier because Khaled doesn't need to implement it. If you want AES or Twofish, there are scripts available to do this, I think. Certainly mircryption supports some kinds of symmetric encryptions.