Forums Feature Suggestions Native FiSH support

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.

The CBC encryption mode - as implemented by Mircyption and FiSH 10 - mitigates that attack vector.

That may be true, but the more popular FiSH does not, and in my tests of a "default" Mircryption install (with no options tweaked), this was also not the case (it wasn't using CBC by default). I therefore imagine that there are many installs setup in this insecure way.

Hi everyone :-)

Well, im a fellow user of mIRC since many Years. Im not a Programmer or Coder, just a User.

Here my Facts:


Im forced, to use 3rd-Party Patches/Plugins, to get my Channels working properly.

Personally i feel saver, knowing, my Chat is Encrypted. Specially in Germany, to keep your privat stuff "privat", hehe.

Me (and ALOT of other Users), would love to see a implemented FiSH-Function in mIRC. Alot of Friend (like 9 or 10), switched from mIRC to XChat, cause of the FiSH-Feature.

So, to the Coders:
If its possible, to add FiSH, by the name of all mIRC+FiSHUsers... ADD IT :-)

Best wishes from sunny Germany,


Sven

seems to me that you are just genrally against encryption and same time keep calling fish a cheap solution allthough it for a very long time was the best solution and it cant be that cheap since mircryption adopted some of it

also u say people may get confused
do you really feel mirc is so straight forward
adding fish as an option cant confuse anyone those who dont need it doesnt look for it

as i see it the more encryption options the better and i really want to see secure transfers in irc too (thats not just mirc though its also irc servers)

excellent news

I look forward to it

Use the ident server so to speak(IS):
CLIENT: /ctcp <nick> GETKEY <ip>
SERVER: /ctcpreplay <nick> GETKEY <ip>:<port> pass

CLIENT-> connects to IS -> SENDS: server-port, user-port :: KEYREQ nick:pass network/server
SERVER -> REPLIES: server-Port, user-Port :: KEYACK <key>

Then, for a user to get the key: /GetKey <nick>/<address> port
Or something of the such

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.

How wonderful to see a bunch of 'know it alls' dictate to others what they think we do and don't need. A clear indication of how the progression of software can be hindered by people who think that as long as all there needs are met, no one else should need anything else. MIRC is not a freeware program, and if a customer asks for something that makes sense, I don't understand why it's not already done. I'll put a rest to this silly argument. A full test done by 10 different users around the world using 2 mirc's. The first is an older version with a direct patch applied to mirc.exe, the other is the latest version of mirc using a mirc script without a patch. For all 10 users, the speed difference under heavy traffic load was enough to make us all sick. NO WE DON'T WANT SCRIPTS OR WORK-AROUNDS!!! We paid for this software and are asking for something someone already did long ago. So go ahead and keep trying to argue how it's 'not needed' just because you don't use it. For the rest of us who make proper sense, please implement... Done, fixed, all are happy, never have to worry about it again. It's not that hard.

This is a weird argument. Are you really suggesting that because you paid for mIRC you have the right to *demand* that every feature you want be implemented? Sorry sir, that's not how paying for things works. You paid for mIRC as it was at version X, not as it would be from now on. mIRC is not run by a public company, and buying the product does not make you a shareholder. Khaled implements the features that are feasible, have actual user support, and cannot be implemented by other means. So far there has been little user support and ample alternatives. Also keep in mind that Khaled can only do so much. He has already mentioned that it's on his todo list. The existence of reasonably usable scripts makes this a fairly low priority issue IMO.



Great. Where are the results of this test? Specifically, what is your metric on "heavy traffic load"? What is your metric on "make us all sick"? What script were you using? Did you try *ALL* available scripts? If you had actual results, you might be able to make a case. Frankly, my observation to your hypothetical results is that, if the script you tested was slow, the script is pretty poor. An encryption/decryption script is not computationally expensive enough to cause any kind of significant lag/delay. Or in other words, there exist performant FiSH implementations-- it's certainly not impossible to do.



Then why are there so many of them? And why are there so many users using them without issue? Do you speak for every user?

Besides argv0's excellent points, even if mIRC did add in some form of encryption similar to FiSH, people would *still* choose to use something else. I'd be willing to bet that over half of the people who use some form of encryption (FiSH or otherwise) would choose to continue using something other than what mIRC implements. So even among the users who want encryption, many wouldn't really be interested in mIRC's if it were offered. That means a significantly lower number of people who would want mIRC's version of encryption. You're probably looking at a total of a whole 1% of the total mIRC user base who would use mIRC's encryption if it were added. With that low a number, I have to agree with argv0 that it's going to be very low on Khaled's to-do list.

And just to stress argv0's point... just because you paid for mIRC does not give you any rights to demand anything from mIRC. For that matter, Khaled could choose to completely stop development today and you couldn't say a thing about it. You purchased the current version at the time of purchase and were given lifetime upgrades. That doesn't mean that Khaled has to do the upgrades that you want, though he might choose to if they are good suggestions. It just means that you can have free updates of whatever Khaled chooses to add/update/fix.

i understand, the devs not very interested into implement FiSH, for some reasons.

but seriously, in thouse days, where every stupid hacker, goverment or whoever tracking, hacking, sniffing or reading out, personal datas, chats, emails or other informations, its more than important, to keep chat in private (encrypted).

i use irc ALOT (its like 98% of communication on the internet i do), and i encrypt nearly all my chat now.

here some infos, about my mainchat:
* we have 23 static users there.
* till 7.x release of mIRC, 12 users used mIRC.
* after the release of mIRC 7.x, 8 users switched to XChat, cause of implementation Problems of the known fish.secure.la.
* today we still have 23 users, only 2 of em (one of thouse is me) still using mIRC.

i know, this isnt maybe representativ for the whole mIRC Community, but i think, this shows the tendences, how bad peoples today want to have a secure communcation. imho you cant ignore that fact and override it.

Chat used to be about meeting new people. Can't do that with encrypted text unless you're always turning it off. That tells you more about today's society than any potential (very small potential) of hacking/etc does.

I have nothing to hide in chat from anyone including the government and that is true for a majority of users. If they want to log everything I say, they are free to waste their time. I'm not saying encryption is bad or not useful, because it can be useful for some people and even for companies that use it. However, it really is a small number of people overall who care much about it.

Why not? Are you aware that there are DLLs available? If you use a DLL then the performance cost of having a mIRC script call that DLL will be minimal. There will be little to no benefit to having a built-in method if you use a DLL.

If they switched because of one script, they obviously didn't have very heavy ties to the program, since they didn't even bother to try the other scripts out there. So, question:

Did they actually try the other WORKING mIRC encryption scripts? Scripts like mircryption, which have been working since 5.9.

Here's another, out of curiosity: how many of those 8 had registered mIRC?

This is what I'm not understanding: you're trying to tell us that mIRC should effectively be more like XChat w.r.t. FiSH support, but both clients support FiSH through THIRD PARTY SCRIPTS/PLUGINS. So the only way to be more like XChat is to do what they do. Great... so, let's keep the same support we already have for third party plugins! If anything, XChat is proof that you do not need to build blowcrypt support straight into mIRC- it can live as a third party plugin. XChat users don't mind. Why do mIRC users mind?

The real issue here is that a script you used to rely heavily on stopped working, not because of any fault of mIRC, but because the author lost interest in supporting mIRC. That happens. Note that this same issue can happen with XChat in the future. Fortunately, there are great alternatives. Use mircryption.

Many apologies... I spoke too soon before getting more data. Turns out all scripts run faster on previous versions. Users have reported that they favour 6.2 and even some won't use anything newer than 6.17. At first I didn't believe, but after installing clean mirc's with no additional scripts or fish, there were noticable speed differences on small test loops. Even a generic socket read from web sites showed quite a difference. So no need to worry about fish, I imagine there's more to this than I have time to research. But as for mirc, I've enjoyed it from the beginning. It's always nice to take a break from other languages and write scripts in mirc. I'm hoping that once I buy a cpu with more than 4 cores it'll make the difference not so noticable.

The only noticeable speed difference if your scripts are decent is due to unicode and that was not introduced until 6.35. Anyone using older than that is only doing so because they are too lazy to upgrade mIRC, too lazy to upgrade scripts, or too lazy to fix any script problems. Unicode does make mIRC slower because of the nature of unicode. Each character is 2 bytes instead of 1. However, in the majority of scripts (if they are written well), this difference is not noticeable. Regardless of your extremely small and biased group of people, the newest version of mIRC is in use by a very large number of people without a problem.

Just to test speeds, the newest mIRC is a whole 0.3 seconds slower in a basic loop of 100,000 over older version of mIRC. 0.3 seconds? That's not worth noting. And 100,000 loops? Your script(s) shouldn't be looping that many times anyhow in almost all situations if they are written well. And, yes, if you start talking about millions of loops, it will become noticeable. But again, if a script is written well, you shouldn't have to loop anywhere near that many times. If you do, then your script isn't very good.

I run many scripts (23) including socket scripts and many of the scripts are very large (most are part of Invision, which is one of the largest scripts available as far as total number of features available) and there is not any noticeable difference in how the scripts perform. I could double that number of scripts (or more) and still see no noticeable difference.

Again you haven't posted details of your "tests," so it's impossible for us to look into the script(s) you supposedly tested and what is causing the problem. As Riamus said, mIRC 7.xx is slightly slower than 6.xx but the differences are negligible and you should not see noticeable slowdowns.

In fact, Khaled often re-writes routines so that they're faster than they previously were; you need to get the newest version to gain these benefits.

mIRC is single threaded (other than $dllcall and $comcall) and does not take advantage of multi-core processors so you won't see any improvements. Well, besides the improvements from the load being shared amongst the cores by the OS if you're running a newish OS.

I completely agree that some people wrongly assume that because their own needs are met, nobody else should need or want anything further. Absurd.

Now, usage of Fish and DH1080 with IRC are common place. I see no sane reason how adding support for these is in any way a detriment to mirc. It's quite simply a useful feature that's been requested over & over by users. Such requests should be approached as follows:

- Is the request useful? Yes.
- Is the request recurring? Yes.
- Does the request add value by extending functionality? Yes.
- Does implementing the request involve an unreasonable amount of time, effort, or resources? No.

The above questions should be the deciding factor, not mere personal opinion. Does it matter if "you" think other people need this feature? Absolutely not. Therefore arguing against it's addition, with the above considerations, is completely wasteful and useless.

Further, it doesn't take an exceptionally intelligent mind to understand the reason so many other apps now include this stuff....they're meeting an obvious demand.

I'm not arguing against the addition of encryption/fish, I'm trying to explain that there are existing, efficient methods of doing this.

Khaled said that this was on his todo list nine months ago so it's probably not coming anytime soon.

Also:

"- Does implementing the request involve an unreasonable amount of time, effort, or resources? No."

You would need access to the mIRC source code to be able to say that with any certainty.