Adding support for key exchange and encryption is on my to-do list. I have not added it so far because implementing it correctly and robustly is not necessarily trivial.
I don't see what is gained by tacking on encryption to mIRC except potentially a mass of bad/broken security processes and user issues?
IRC was never designed as a protocol to provide any guarantees around identity, integrity, privacy or non-repudiation between communicating parties.The whole idea of mIRC being retrofitted to provide these plainly smacks of kludging this into the wrong tool for the job. If your job is secure delivery of messages, IRC in its current incarnation simply isn't designed to support that.
So far you've all been talking about establishing a private communication channel (i.e. confidentiality), but no one has addressed how mIRC is going to verify the identity of the remote parties or the integrity of messages. These are critical, there is little point implementing encryption if you can't provide these alongside it*. I note that someone else has already pointed out how the server can perform a MITM, so I won't labour the other points which highlight this as a hugely flawed idea at current.
* - It made sense to provide SSL connections between clients and servers, for two reasons - you can verify the server against a mutually trusted part of the PKI infrastructure to establish a secure channel, and YOU TRUST THE SERVER. For client-to-client comms you don't have this infrastructure / trust network in place to leverage, so you're back to square one.
I haven't once used mIRC's SSL features, or any other crypto systems over IRC for that matter, other than Quakenet's CHALLENGEAUTH system.
So, back to my original questions: can someone highlight a sensible use-case where it makes sense to use an IRC client with secure client-to-client security guarantees? (i.e. something where other systems, designed for this, are best avoided).
Regards,
SGR.
EDIT: Its worth mentioning that given the live-nature of IRC, if your threat-model doesn't include it, you may want to consider how to frustrate timing attacks and attacks based on the very small amount of entropy found in the average IRC message - if we're even looking at this properly. Given the server will see this information, I suspect a lot of information could be leaked from some trivial statistics over these kinds of metrics.
EDIT2: BTW, if anyone here is heading to the SHA-3 conference in California later this month, can you PM me. I won't be there, but our R&D folks in the US will be (they designed one of the algorithms in Round 2) - I'd appreciate it if someone could pass on a message.
