mIRC Home    About    Download    Register    News    Help

Print Thread
Page 1 of 4 1 2 3 4
#220368 12/04/10 03:39 PM
Joined: Jul 2006
Posts: 248
B
bwuser Offline OP
Fjord artisan
OP Offline
Fjord artisan
B
Joined: Jul 2006
Posts: 248
Seeing that mIRC is now finally moving towards full Unicode support and stuff, I have to pitch in that we also need native FiSH encryption and DH1080 key exchange support. I mean, even Trillian supports it natively these days and mIRC users still have to jump through loops and holes (= patch mIRC.exe or use third party tools) just to get encryption.

Thanks for considering it.

Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
Do "we" really need it? SSL is a fine enough encryption to secure your data between your node and the server. Privacy is cool and everything, but FISH is overboard and unnecessary for most users.

There are also ways to implement encryption without patching mIRC, and I see no problem with third party scripts here. The whole point of mIRC's robust scripting support is for cases like these, where a smaller demographic might need a tool that does not really belong as a core feature of mIRC.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Jul 2006
Posts: 248
B
bwuser Offline OP
Fjord artisan
OP Offline
Fjord artisan
B
Joined: Jul 2006
Posts: 248
Well, it's not possible to implement FiSH as an mIRC script. That's the whole point of my post. A native (C-level) encryption API would also enable other encryption technologies like OTR.

PLEASE consider it.

To quote the FiSH DLL author:
Code:
Unfortunately it is not possible to do this by only using a mIRC script,
because it is not powerful enough for this job. Why? Well, the main
problem is that you are not able to REPLACE the original mIRC buffer
holding the (cipher) text with the encrypted/decrypted message, so that
you are required to 'halt' the original event (send/receive), encrypt
or decrypt the message and finally send/display the new (cipher/plain)
text. The result is incompatibilty within other mIRC scripts and mIRC
features, such as:

- displaying both (plain and ciphered) message lines in mIRC, workaround
  using halt command, which leads again to problems
- screwing formatted charts and ASCII pictures (simply everything that
  is using space characters as delimiters) - no workaround known
- performance loss, the mIRC DLL handling is not very fast
- and more ...

So either you request a real plug-in API in next mIRC version from the
author, or you live with the patching, which solves all these problems!

Last edited by bwuser; 23/04/10 08:49 AM.
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
An mIRC script does not mean that no C code is involved. mIRC scripts commonly make use of DLLs to accomplish a task. A FiSH script can (and would) do this too.

The FiSH author is mistaken about the inability to script this. The reasons cited are inaccurate.

- Firstly, saying DLL handling is too slow is basically saying C is too slow. Given that mIRC can't get much faster than DLL processing, "native" support would not make a difference. Sending commands via SendMessage is slow, but if you need to do that more than once per message you're doing it wrong. IIRC the latency on SendMessage is ~10-15ms, which is roughly the Windows RunLoop cycle time. You can also use a project like the CLB (http://kthx.net/clb) to bypass this and get equivalent speeds to mIRC if you really needed to, though you probably don't. Realize that 10ms is a throughput of 100 messages per second, which seems quite sufficient to me. I don't know many instances of mIRC that send/receive 100 messages per second.

- Displaying messages in mIRC is the same as a DLL or plugin system. You would script the ON TEXT/ACTION events and halt default text. This is an extremely common scripting task, and there is ample support in mIRC for this. Native support in mIRC would not make this easier to implement; certainly whatever problems exist will still exist in the native implementation (though I don't really see any problems).

- The multi-space problem can already be solved by using a DLL like spaces.dll, so unlike the author suggests, a workaround is known for this problem. This is a side-effect of using any script that modifies output, not just FiSH, so this is irrelevant to the general question of whether or not it can be scripted.

- Because FiSH encryption lives above the IRC protocol layer, you should not need (as the author suggests) to "replace" mIRC's buffers, you simply need to pass $1- from an ON TEXT/ACTION event into the dll and decrypt it. $1- should be at most 500 bytes, which is a very small amount of data. There are no performance bottlenecks here, so mIRC is certainly powerful enough to handle this end of things. Again, the cryptographic functionality would all be implemented in C.

- Incompatibilities with scripts is a fair point, but not a show-stopper. You *would* have to modify *theme-based* scripts to support FiSH (anything that modifies ON TEXT output), but it wouldn't take much lobbying to get the bigger scripts to play nicely with a FiSH install. It would also be relatively trivial to modify scripts on your own to add this support, since you would just need to modify 2 events (ON TEXT, ON ACTION). Is this really a big deal? Maybe the author should concentrate more on implementing the script than complaining that it cannot be done.

It is certainly possible to script as a DLL (or with DLL helper functions). Yes, scripting this adds complexities to mIRC, but most scripts that interact with mIRC in this way do too.

But this all goes back to the question of how many people need this functionality built-in. Currently, not many IRC clients even support this kind of encryption, and I've personally seen no outcry of users asking for it. It would be extremely unfortunate if Khaled had to delay a release of mIRC to add functionality or fix bugs in a feature that was only used by a very small minority when this could be handled simultaneously by a third party script with delays avoided.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: May 2008
Posts: 7
T
T4K Offline
Nutrimatic drinks dispenser
Offline
Nutrimatic drinks dispenser
T
Joined: May 2008
Posts: 7
I know many networks that use fish. I kinda think it's a pain in the butt that we have to go else where to implement simple things like fish. I've thought about switching to trillian even though I'm a paying mirc owner. SSL is great... But some people want a little more. I guess you don't know how paranoid people are sometimes? Having that extra layer of encryption is a rather good relaxing feeling.

T4K #221379 15/05/10 09:36 AM
Joined: Sep 2005
Posts: 2,881
H
Hoopy frood
Offline
Hoopy frood
H
Joined: Sep 2005
Posts: 2,881
SSL is the standard used for submitting credit/debit card details and other such personal information on the net: it's secure enough.

T4K #221388 15/05/10 07:21 PM
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
What do you mean "we have to go somewhere else to implement simple things like FiSH"? As I pointed out in my previous reply, you can implement it in mIRC; simply. In fact, it's already implemented in a few scripts. Scripts like Mircryption already exist for mIRC and implement Fish without modifying the binary, and there's the less-recommended "FiSH" patch available as well (recently updated for 6.35). The focus here isn't whether or not you can use FiSH with mIRC (you already can), the issue is whether it is worth Khaled's time to re-implement already-existing scripts inside mIRC for the very few users who use them.

If you know many networks that use FiSH, please list them. I'm not quizzing you, I'm genuinely interested to know which networks implement this encryption scheme.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: May 2010
Posts: 5
T
Nutrimatic drinks dispenser
Offline
Nutrimatic drinks dispenser
T
Joined: May 2010
Posts: 5
Hi,

just registered to clear up a misconception you might be having. Blowfish IRC encryption is not comparable to the SSL encryption mentioned previously in this thread. SSL is solely client to server encryption whereas blowfish is used to encrypt the communication in channels, queries , notices and topics. The difference is quite obvious. Blowfish will make sure that communication between two IRC users is encrypted. Data sent via SSL server connection will be visible in plaintext on the server.

This also makes your question regarding the networks that use blowfish pointless. It's used on each and every major IRC network. I know a bunch of channels and users on DalNet, LinkNet, EfNet and several private IRC networks that use blowfish.

Due to the fact that blowfish encryption is built on top of the IRC protocol (as mentioned earlier) it is available on all IRC networks even if they do not offer SSL connections (on top of the extra security offered by the client to client pattern).

Personally i've been using blowfish on IRC since several years and know at least a couple of hundred people and channels spread out over several networks. The audience for this is larger than you might think. I am also assuming that a lot people would like that extra privacy who do not know of this method yet due to the fact that it's not readily available. When a new mIRC version is released i was forced to wait with upgrading until the blowfish plugins/patches/scripts got updated for new versions as well. Also there have always been rumors about malware/spyware/viruses in these dll's and patches, which leads to another problem with third party assemblies: the source isn't always trustable.

All the aforementioned are reasons why i would love a native integration into the mIRC core too. I think the implementation is rather trivial and the overhead and increased size generated by it is ignorable. Hope you and the team reconsider this feature request.

Cheers,
trashcan

Joined: Oct 2004
Posts: 8,330
Hoopy frood
Offline
Hoopy frood
Joined: Oct 2004
Posts: 8,330
I think you'll find that even though you know a lot of channels and people that use FISH, they are still a very small minority compared to those who don't and who don't care about encryption. Of course, that doesn't necessarily mean that mIRC shouldn't consider supporting it. However, I can quickly see issues with people who have no idea what FISH is who suddenly can't understand each other if it was built into mIRC.

You don't see that issue now because people who are using FISH have actively gone out and went to the trouble of getting it set up, so they know what they are doing with it. The typical user could quickly become confused as to what's going on if it's built in.

Also, if you check the Developers Forum, you'll find a new method of using FISH that patches mIRC in memory rather than the file itself. That allows FISH to work on new versions of mIRC without waiting for FISH to receive an update. From those who I know who use it, I've been told it works well. It does have a few issues that are being ironed out still, but it still seems to work well. You might want to give it a try. I don't use it, so I can't give you specifics on it. Anyhow, if it works as well as it seems to and is as easy to use and it sounds and it doesn't require updating every time mIRC updates, it may be easy enough to use and less of a hassle and may be just fine as-is without needing to build it into mIRC. Just a thought.


Invision Support
#Invision on irc.irchighway.net
Joined: May 2010
Posts: 5
T
Nutrimatic drinks dispenser
Offline
Nutrimatic drinks dispenser
T
Joined: May 2010
Posts: 5
Riamus2,

i know where you're going and i agree that the audience for this feature is not the majority yet not a small one. Of course the blowfish integration should be carried out non-intrusive. IMHO A "Blowfish Encryption" submenu with informative confirmation dialogues for the individual functions would account for unaware users.

The in-memory blowfish addon does not fix some of the issues i mentioned, like trustworthiness of source and it's also only good as long as memory locations do not get changed. Though i agree that the approach is much sleeker than the previous ones. The thread on the FiSH forums made me read this thread in the first place by the way and i thought it would be sweet to have this available as a mIRC core feature.

I think it's a good thing to be able to talk safely to colleagues and friends without having to worry about a man in the middle. As much as i trust IRCOPS i value my job and i don't like talking about business strategies or in-development technologies over insecure channels. This encryption scheme is not only useful to terrorists (;)) and i'm still sure there are others who would agree who currently don't even know this kind of encryption is available at all.

Best regards,
trashcan

Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
Let's not confuse the issue. There is no technical reason why it can't be added to mIRC; however there is also no technical reason why it can't be (remain) a third party tool. It's important to point out that nearly every other IRC client with this feature has it implemented as a plugin/third party script. Probably the only reason Trillian requires this to be built-in is it's much less extensive third party plugin support. All other clients I know of that can implement this as a third party script do so.

In fact, there is no problem with the proper third party Blowfish scripts out there. I think most of the complaining is coming from users who are using bad implementations such as FiSH that require modifications to the executable and are therefore extremely easily broken. As mentioned, there are properly implemented alternatives available such as Mircryption that don't have these problems.

If you simply switch to one of these scripts you will solve many of your problems. These scripts are also well tested, have source code freely available and are reviewed by the community, so the malware issue is moot. Third party scripts are a reality for most people using mIRC, so the threat of malicious scripts is not new. Fortunately, the community has handled this extremely well and there have been very few isolated cases of such scripts. Assuming you get your scripts directly from the official sites, I have heard no cases of any malicious code in any of the popular Blowfish encryption scripts, and they have been widely used by enough people to be trusted.

Ultimately the question is whether it is a worthwhile use of Khaled's time. There are many things mIRC could use that cannot be implemented by a third party script, and given that there is already a number of solutions available for this feature and a relatively small demographic of users who need it, I personally see this as a low priority issue. That said, the only person who decides what goes into a version of mIRC is Khaled himself, not anybody else on these forums. Ultimately it is his decision. Personally I'd rather see things improved like the connection setup UI, dialog support and other such features rather than waste resources re-writing scripts that already exist for the sole benefit of a little extra "trust".


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Oct 2004
Posts: 8,330
Hoopy frood
Offline
Hoopy frood
Joined: Oct 2004
Posts: 8,330
Good points. smile

As for trustworthiness of the source, considering the source of the new one is available to look through, I'd say that isn't really such a big deal here. If anything was wrong, someone would notice and report it. Still, I do understand the concern.


Invision Support
#Invision on irc.irchighway.net
Joined: May 2010
Posts: 5
T
Nutrimatic drinks dispenser
Offline
Nutrimatic drinks dispenser
T
Joined: May 2010
Posts: 5
The Diffie-Hellman key exchange addon used by the mircryption suite you are recommending uses the FiSH.dll which you are advising not to use. But it's OK. I just thought i'd share my 2 cents on this topic and didn't want to drag anyone's attention away from more immediate concerns with mIRC.

Take care,
trashcan

Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
No, I'm advising against any script that is badly designed and breaks when new versions of mIRC are released.

The mircryption script I recommended works with any version of mIRC from 5.9 to the 7.x betas without modification. What tools it uses under the hood is irrelevant, the important part is that it works in a maintainable fashion across mIRC releases. It might use parts of FiSH, but it works when FiSH does not. There's no reason to argue semantics. If you were using this script rather than the alternative "FiSH" script, you would have been able to update to any version of mIRC without issue.

For reference, the script was last updated in 2008, and the file modified timestamp on the FiSH.dll from the archive is 4/19/2004. It seems clear that it did not need an update since well before 6.3x. I just tested it under the latest 7.x beta. It worked. It will likely work for a while longer. Use it.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
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 have a question: how do the current encryption addons mitigate Man-In-The-Middle attacks? It seems to me that IRC would be an ideal, if not trivial, environment to use such an attack, since all communication goes through the server.

Joined: May 2010
Posts: 5
T
Nutrimatic drinks dispenser
Offline
Nutrimatic drinks dispenser
T
Joined: May 2010
Posts: 5
Hi Khaled,

the "man in the middle" i was talking about was the server itself. Sorry for misusing the widely used term for a certain attack method in this case.

The encryption used is regular blowfish encryption. You can either just define your own key and share it with others through other secure channels (e.g. pgp email) or have a random key generated and exchanged.

In order for a client to identify an encrypted string the text is prefixed with an indicator. There are two different prefixes used in the wild, "+OK" and "mcps" followed by a space and the blowfish encrypted text.

Key exchange and the security of it is, as mentioned earlier, handled by the Diffie/Hellmann 1080 key exchange algorithm. http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange

You can see a few different implementations at http://fish.secure.la/ when you click on "DH1080" at the top nav. There's also a wide variety of different implementations available when you google it.

Really great news that you have this on your to-do list.

Cheers,
trashcan

Last edited by trashcan; 27/05/10 03:55 PM.
Joined: Jan 2003
Posts: 2,523
Q
Hoopy frood
Offline
Hoopy frood
Q
Joined: Jan 2003
Posts: 2,523
Correct me if I'm wrong, but DH key exchange on its own cannot prevent MITM attacks. A MITM would simply exchange keys separately with you and your friend. So while you can be sure that you've established a secure channel with somebody, you can't be sure who that somebody is. In other words, some form of authentication is necessary, which DH does not provide.

Asymmetric (public key) cryptography could be used instead of DH for key exchange (if not for the entire communication) but this assumes that you know with certainty that a particular public key belongs to a particular person (your friend). In other words, some sort of secure out-of-band (outside of IRC) communication seems necessary.


/.timerQ 1 0 echo /.timerQ 1 0 $timer(Q).com
Joined: May 2010
Posts: 5
T
Nutrimatic drinks dispenser
Offline
Nutrimatic drinks dispenser
T
Joined: May 2010
Posts: 5
qwerty,

you are absolutely correct afaict. DH1080 does not protect you against MITM attacks for the reasons you have mentioned. If you want to be 100% sure that you are not being spied on you would still have to exchange keys over a secure channel outside of IRC. (Not a big deal IMHO). DH1080 is useful when you aren't suspecting to be actively tracked or that a man in the middle is intercepting all DH1080 key exchanges. I still think DH1080 is useful when you don't require absolute security but rather want to make sure that you're not piping plain text through an irc server.

There have been attempts to implement pgp style key exchanges over IRC (i know mouser of mircryption had something like that) but it wasn't all that user-friendly and therefor didn't end up to be a success story.

Edeit: It seems Blowfish-EBC and DH1080 are pretty much the community-driven and self-established standard now. There have also been attempts (proposals) to standardize the encryption but i don't think that went anywhere. There's a nice proposal at http://www.bjrn.se/ircsrp/ircsrp.2.0.txt but i guess noone cared enough yet.

Last edited by trashcan; 28/05/10 11:32 AM.
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
Yes, I was referring to authentication. Without authentication, there is no way for you to know whether your communication on IRC is being monitored. Since it would be trivial for an IRC server to monitor all messages and to automatically initiate, without any human intervention, MITM attacks during key exchange and then decrypt all messages on-the-fly, it seems to me that this would give users a false sense of security. As you say, you would need to exchange keys on a secure channel outside of IRC, which makes things a little more complicated.

Joined: Sep 2005
Posts: 2,881
H
Hoopy frood
Offline
Hoopy frood
H
Joined: Sep 2005
Posts: 2,881
Originally Posted By: Khaled
Yes, I was referring to authentication. Without authentication, there is no way for you to know whether your communication on IRC is being monitored. Since it would be trivial for an IRC server to monitor all messages and to automatically initiate, without any human intervention, MITM attacks during key exchange and to then decrypt all messages on-the-fly, it seems to me that this would give users a false sense of security. As you say, you would need to exchange keys on a secure channel outside of IRC, which makes things a little more complicated.


Could open a DCC chat, exchange keys, close DCC chat. Would that work?

Page 1 of 4 1 2 3 4

Link Copied to Clipboard