Certainly that begs the question of why the whole private conversation can't just take place in a DCC CHAT? If multiple users are the issue, there's always eggdrop-style partyline scripts or the possibility of mIRC improving on DCC CHAT to support multiple users (and allow SSL). I'd rather see that than an encryption mechanism that is cheaply tacked onto the IRC protocol and doesn't work all that well.

Of course there are other issues with the "security" of blowcrypt. The same person who proposed IRCSRP wrote this very good summary of encryption mechanisms on IRC: http://blog.bjrn.se/2009/01/proposal-for-better-irc-encryption.html

It explains that under many blowcrypt scripts, the same message will always be encrypted into the same string, given a specific key, no matter who writes it (or when). That makes it relatively easy to crack, especially when a smart user can easily and intuitively detect what messages are "hi", or "cya". And if you know the message, the key is nothing but a brute-force away-- with rainbow tables it's even simpler. IMO blowcrypt is an inherently false sense of security, given all the factors involved.

PS. As I quickly touched on, DCC CHAT currently does not support SSL encryption, so using an unmodified DCC CHAT to pass the key has the same MITM problem. Not to mention the server could also mangle the IP in the DCC request to one of its own and perform a MITM attack like that too.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"