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,412
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,412
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,412
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,412
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?

Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
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"
Joined: Jul 2006
Posts: 248
B
bwuser Offline OP
Fjord artisan
OP Offline
Fjord artisan
B
Joined: Jul 2006
Posts: 248
Originally Posted By: argv0
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).

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

Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
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.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Jun 2010
Posts: 7
S
Nutrimatic drinks dispenser
Offline
Nutrimatic drinks dispenser
S
Joined: Jun 2010
Posts: 7
Hi everyone :-)

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

Here my Facts:
Code:
* Conntected to 3 Server (all via SSL)
* 16 Channels at all
* 12 of thouse Channels using FiSH/DH1080


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

Joined: Jul 2010
Posts: 2
U
Bowl of petunias
Offline
Bowl of petunias
U
Joined: Jul 2010
Posts: 2
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)


Joined: Sep 2007
Posts: 202
F
Fjord artisan
Offline
Fjord artisan
F
Joined: Sep 2007
Posts: 202
Originally Posted By: Khaled
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.
excellent news smile

I look forward to it

Joined: Apr 2010
Posts: 969
F
Hoopy frood
Offline
Hoopy frood
F
Joined: Apr 2010
Posts: 969
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 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.


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

Last edited by FroggieDaFrog; 18/07/10 01:47 PM.

I am SReject
My Stuff
Joined: Aug 2003
Posts: 20
S
SGR Offline
Ameglian cow
Offline
Ameglian cow
S
Joined: Aug 2003
Posts: 20
Quote:
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.

Last edited by SGR; 02/08/10 08:51 PM.
Joined: Feb 2011
Posts: 4
N
Self-satisified door
Offline
Self-satisified door
N
Joined: Feb 2011
Posts: 4
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.

Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
Originally Posted By: Nikademus
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.


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.

Originally Posted By: Nikademus
A full test done by 10 different users around the world using 2 mirc's


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.

Originally Posted By: Nikademus
NO WE DON'T WANT SCRIPTS


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?


- 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
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.


Invision Support
#Invision on irc.irchighway.net
Joined: Jun 2010
Posts: 7
S
Nutrimatic drinks dispenser
Offline
Nutrimatic drinks dispenser
S
Joined: Jun 2010
Posts: 7
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.

Joined: Oct 2004
Posts: 8,330
Hoopy frood
Offline
Hoopy frood
Joined: Oct 2004
Posts: 8,330
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.


Invision Support
#Invision on irc.irchighway.net
Joined: Sep 2005
Posts: 2,881
H
Hoopy frood
Offline
Hoopy frood
H
Joined: Sep 2005
Posts: 2,881
Originally Posted By: Nikademus
NO WE DON'T WANT SCRIPTS OR WORK-AROUNDS!!!


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.

Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
Originally Posted By: SvenV
after the release of mIRC 7.x, 8 users switched to XChat, cause of implementation Problems of the known fish.secure.la.


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.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Feb 2011
Posts: 4
N
Self-satisified door
Offline
Self-satisified door
N
Joined: Feb 2011
Posts: 4
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.

Joined: Oct 2004
Posts: 8,330
Hoopy frood
Offline
Hoopy frood
Joined: Oct 2004
Posts: 8,330
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.


Invision Support
#Invision on irc.irchighway.net
Joined: Sep 2005
Posts: 2,881
H
Hoopy frood
Offline
Hoopy frood
H
Joined: Sep 2005
Posts: 2,881
Originally Posted By: Nikademus
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.


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.

Joined: Jul 2007
Posts: 66
B
Babel fish
Offline
Babel fish
B
Joined: Jul 2007
Posts: 66
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.

Joined: Sep 2005
Posts: 2,881
H
Hoopy frood
Offline
Hoopy frood
H
Joined: Sep 2005
Posts: 2,881
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.

Joined: Jul 2007
Posts: 66
B
Babel fish
Offline
Babel fish
B
Joined: Jul 2007
Posts: 66
Originally Posted By: hixxy
I'm not arguing against the addition of encryption/fish, I'm trying to explain that there are existing, efficient methods of doing this.

The issue isn't whether or not preexisting alternate methods exist, it's whether or not Mirc will have this feature included in it's core.

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

I was unaware of that. Good decision on his part.

Quote:
"- 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.

With absolutely certainty, yes. However, you can make a pretty good guess with just a basic understanding of how to implement such a feature. It's likely easy on a scale of very easy-to-very difficult. But it should neither require any major effort nor be very difficult unless Mirc is designed to be exceptionally limiting and handicapped... Something I seriously doubt.

From a code perspective, this stuff isn't anything you'll lose sleep over. It's just not that mountainous or challenging of a task 99%+ of the time. I'd guess that the only reason it hasn't happened yet is Khaled has other things on his TODO list which take higher priority.

Joined: Oct 2004
Posts: 8,330
Hoopy frood
Offline
Hoopy frood
Joined: Oct 2004
Posts: 8,330
Originally Posted By: beer
I'd guess that the only reason it hasn't happened yet is Khaled has other things on his TODO list which take higher priority.


Exactly. No matter how much anyone might want a certain feature, Khaled puts things in based on whatever priority he chooses. It was stated many times in this thread and others that it is on his to-do list. As it hasn't yet been done, it's probably a low priority for him. As mentioned, the percent of users who 1) want encryption, and 2) would use mIRC's instead of a third party if it was available in mIRC, is VERY small. There are many more feature requests that have a much stronger support and would affect a much larger number of people. Those are the features that should have a higher priority. Throw in the fact that was mentioned of various third party options that work great already and it is going to drop even further in priority. Until those are taken care of (and if no other requests come in that also deserve a higher priority), I have a feeling this will remain low on the list.

The point most have been making is that regardless of whether or not it's a useful feature that some would really like to see, there are many more features that are even more useful and affect more people. Most of those who aren't posting in "support" of this wouldn't mind if it was added. They're not saying it shouldn't be added. Instead, if you read the posts, they're just explaining that it's not likely to happen soon and that there are some good alternatives in the meantime. We can't know what Khaled's plans are for upcoming features, but just as you said in your post about guessing... we can make a fairly informed guess that it won't be soon.


Invision Support
#Invision on irc.irchighway.net
Joined: Sep 2005
Posts: 2,881
H
Hoopy frood
Offline
Hoopy frood
H
Joined: Sep 2005
Posts: 2,881
Originally Posted By: beer
The issue isn't whether or not preexisting alternate methods exist, it's whether or not Mirc will have this feature included in it's core.


If you read the thread you'll see that the poster I replied to was suggesting there are no viable alternatives; I wasn't the one who brought it up.

Quote:
I'd guess that the only reason it hasn't happened yet is Khaled has other things on his TODO list which take higher priority.


You're probably right.

Joined: Apr 2004
Posts: 871
Sat Offline
Hoopy frood
Offline
Hoopy frood
Joined: Apr 2004
Posts: 871
Originally Posted By: beer
I'd guess that the only reason it hasn't happened yet is Khaled has other things on his TODO list which take higher priority.

I'd guess that it has something to do with the fact that Khaled's own question in this thread regarding how to properly perform initial key exchanges has yet remained unanswered.


Saturn, QuakeNet staff
Sat #229768 16/02/11 11:47 PM
Joined: Jul 2007
Posts: 66
B
Babel fish
Offline
Babel fish
B
Joined: Jul 2007
Posts: 66
Originally Posted By: Sat
Originally Posted By: beer
I'd guess that the only reason it hasn't happened yet is Khaled has other things on his TODO list which take higher priority.

I'd guess that it has something to do with the fact that Khaled's own question in this thread regarding how to properly perform initial key exchanges has yet remained unanswered.

The issue of defeating the MITM scenario has been beat to death with plenty of information readily available using simple google searches. The answers are there if you bother to look. I would really hope Khaled doesn't rely on forum replies for something like this.

Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
Originally Posted By: beer
Further, it doesn't take an exceptionally intelligent mind to understand the reason so many other apps now include this stuff


So many? Name two. (by "this stuff" I assume you mean blowcrypt)


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
Originally Posted By: beer
The issue of defeating the MITM scenario has been beat to death with plenty of information readily available using simple google searches


Enlighten us with some keywords, then. The resource I posted a few pages back claims that all existing methods are vulnerable to MITM. I haven't seen any dead horses in my searches. I can barely find any information on blowcrypt implementations at all.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Jul 2007
Posts: 66
B
Babel fish
Offline
Babel fish
B
Joined: Jul 2007
Posts: 66
Originally Posted By: argv0
Originally Posted By: beer
Further, it doesn't take an exceptionally intelligent mind to understand the reason so many other apps now include this stuff


So many? Name two. (by "this stuff" I assume you mean blowcrypt)

First, if you're just looking to argue, don't waste my time. I'm not interested in the petty back & forth some of "you" seem to enjoy. Secondly, in the future you can google this stuff yourself but this one single time I will play along; SecureCRT, OpenSSH, TIVO DVR's, the Linux kernel, ShareCrypt, SafeHouse, various password management applications for Windows/Linux/Mac/PalmOS/Apple iOS, ........and countless others. It's foolish to question support of fish and DH considering how widely used it is. Basically all it says is that you don't know what you're talking about. I don't say that to be offensive, it's merely a simple observation.

Originally Posted By: argv0
Enlighten us with some keywords, then. The resource I posted a few pages back claims that all existing methods are vulnerable to MITM. I haven't seen any dead horses in my searches. I can barely find any information on blowcrypt implementations at all.

I have no interest in teaching you how to better use the google search engine. If you're having trouble coming across this stuff, you do indeed need to do better at thinking up search terms to use. I'm sure there's plenty of information available on that subject as well. My only suggestion is that you find reference material a little more current then 2009.

I'm done feeding the troll now.

Joined: Sep 2005
Posts: 2,881
H
Hoopy frood
Offline
Hoopy frood
H
Joined: Sep 2005
Posts: 2,881
Originally Posted By: beer
I have no interest in teaching you how to better use the google search engine. If you're having trouble coming across this stuff, you do indeed need to do better at thinking up search terms to use. I'm sure there's plenty of information available on that subject as well. My only suggestion is that you find reference material a little more current then 2009.

I'm done feeding the troll now.


Translation: "I searched and couldn't find anything, therefore I'm going to pretend that I won't waste my time because it's so easy and call you a troll for added effect."

If you really want the feature, and Khaled has asked a genuine question about how to prevent MITM style attacks, then maybe you should just humour him and it might give the feature a nudge up his todo list. Implementing a feature when you have the necessary research in front of you is usually quite trivial; having to research something is much more time consuming.

Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
Originally Posted By: beer
It's foolish to question support of fish and DH considering how widely used it is.


Perhaps you should try paying attention. I wasn't questioning the support of the BLOWFISH ENCRYPTION ALGORITHM. I was asking you to name IRC programs that implement blowcrypt (a specific "protocol"). It doesn't take an exceptionally intelligent mind to understand that TIVO DVR's have little relevance to the needs of an IRC client. Implementing Blowfish over SSH, or encrypting passwords on a local machine with a salt is not at all the same thing as implementing Blowfish over IRC. If you actually read the resource I posted, you will see that the differences are discussed in detail. The article was written for a reason, and the issues mentioned present unique implementation problems w.r.t. IRC.

Since you brought it up, however, the reason those apps include encryption mechanisms is because they are security tools (exception of TIVO DVR's). This is an idiotic comparison. Certainly a security tool will include security features. mIRC is a chat client, not a security tool. The point here is that every other IRC client [that supports plugins] supports blowcrypt through third party plugins (FiSH, mircryption, etc). Why does mIRC need to be different here?

Originally Posted By: beer
My only suggestion is that you find reference material a little more current then 2009.


You do realize that even the *scripts* people use for blowcrypt implementations are 2009 or older, right? FiSH's last release for mIRC was Jan 2010. mircryption's last release was April 2007. These scripts still work for mIRC. New resources are useful when there is new information. There is no new information w.r.t. these implementations. Again, if there is, please show us. This doesn't need to be a google match or some geek-off where you prove that your google fu is better than everybody else's. It's a simple query: please show us some of the information that you claim is out there.



- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Jul 2007
Posts: 66
B
Babel fish
Offline
Babel fish
B
Joined: Jul 2007
Posts: 66
Originally Posted By: hixxy
Originally Posted By: beer
I have no interest in teaching you how to better use the google search engine. If you're having trouble coming across this stuff, you do indeed need to do better at thinking up search terms to use. I'm sure there's plenty of information available on that subject as well. My only suggestion is that you find reference material a little more current then 2009.

I'm done feeding the troll now.


Translation: "I searched and couldn't find anything, therefore I'm going to pretend that I won't waste my time because it's so easy and call you a troll for added effect."

What exactly do you hope to accomplish by making up a fake "translation"? I don't speak in riddles and secret meanings. It is just as I said. No amount of pretend nonsense you dream up and post is going to change that fact. My suggestion to you is to leave the childish attitude on the playground. Translation: Come on, grow up.

Joined: Jul 2007
Posts: 66
B
Babel fish
Offline
Babel fish
B
Joined: Jul 2007
Posts: 66
Originally Posted By: argv0
Originally Posted By: beer
It's foolish to question support of fish and DH considering how widely used it is.


Perhaps you should try paying attention. I wasn't questioning the support of the BLOWFISH ENCRYPTION ALGORITHM. I was asking you to name IRC programs that implement blowcrypt (a specific "protocol").

My statement referring to apps supporting fish was not specific intentionally to point out how widely used it is. Perhaps you should take your own advice and pay more attention. And for the record, I did exactly that.. By all means, please point out where you explicitly asked about "IRC programs that implement blowcrypt":
Originally Posted By: argv0
Originally Posted By: beer
Further, it doesn't take an exceptionally intelligent mind to understand the reason so many other apps now include this stuff


So many? Name two. (by "this stuff" I assume you mean blowcrypt)


[...useless text removed...]

Originally Posted By: argv0
Since you brought it up, however, the reason those apps include encryption mechanisms is because they are security tools (exception of TIVO DVR's). This is an idiotic comparison.

I am not comparing irc clients and security tools. I am not comparing any type of software against another. That's nothing more then an idiotic assumption on your part, with absolutely no merit behind it. I said a lot of apps support fish, you requested I name 'at least two', and I played your game. As has already been pointed out to you, "my statement referring to apps supporting fish was not specific intentionally to point out how widely used it is." I would hope that isn't too difficult of a concept for you to follow.

[...useless text removed...]

Originally Posted By: argv0
You do realize that even the *scripts* people use for blowcrypt implementations are 2009 or older, right?

True or not, that has no relevance what-so-ever. Fish encryption is widely used. That's fact. Fish encryption is something users have consistently requested be a part of mirc's core. That's fact.

[...useless text removed...]

In closing I'll say quite simply that your lack of knowledge, refusal to do your own homework, and your resistance to the truth is nothing more then your problem. I'm not particularly motivated to help those who willingly choose to be ignorant or want to argue just for the sake of arguing because they have nothing better to do. This is in fact an internet message forum, I probably shouldn't have expected any different.

Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
Originally Posted By: beer
I'm not particularly motivated to help those who willingly choose to be ignorant or want to argue just for the sake of arguing because they have nothing better to do.


The irony of this is funny. I'm not "arguing", I'm asking you to provide information to Khaled. You're the one who is resisting, citing idiotic reasons such as "I shouldn't need to teach you how to use Google".

If you want to have a constructive discussion, I'm all for it. We're waiting on you, though. You mentioned you know of resources regarding ways to solve the MITM attack over IRC. Please list your resources.

If you're only interested in passive aggressive idiocy and personal attacks, go somewhere else. That behaviour is not tolerated here.


- 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
Might as well not bother arguing with him. He's your typical troll... providing no useful information to the thread while inciting arguments. I think this thread has already been derailed enough that it's not really very useful to anyone.

For anyone who really wants encryption, then as requested, please offer real suggestions on implementation of a secure key exchange method that would work in IRC. Offering real suggestions instead of telling people to search will give you a much greater chance to see this implemented. Acting high and mighty about how superior you are because you know something someone else doesn't is a waste of everyone's time and really just shows how little you know.


Invision Support
#Invision on irc.irchighway.net
Joined: Sep 2005
Posts: 2,881
H
Hoopy frood
Offline
Hoopy frood
H
Joined: Sep 2005
Posts: 2,881
Sorry you're right, that was childish, however you chose to ignore the sensible part of my post.

Khaled asked if there was a decent method of preventing MITM attacks. You claim to know of such a method. Clearly, if you furnish Khaled with that information, there is a slight chance this may get into mIRC faster.

Joined: Jul 2007
Posts: 66
B
Babel fish
Offline
Babel fish
B
Joined: Jul 2007
Posts: 66
argv0:
I've already said I'm done playing your game. If you want your questions answered, do the work yourself, as I have. Stop being the adolescent that whines about not knowing something but refuses to take any initiative to learn. I'm not here to spoon feed you, put on your big boy pants and do it yourself. While you're working on you, try to stop being the adolescent that spills milk on the floor and then tries to blame whoever is in closest proximity for it. Take responsibility for your own behavior before you attempt advise others on it. Lead by example, champ.

Riamus2:
I hope you're not implying that I'm the one acting high, mighty, and superior. I have never made any such claims or insinuations, nor do I believe a person with more knowledge & experience on a given subject somehow makes them superior as a person. People who claim to be superior, and those who accuse others of it with no real merit, tend to be the victim of their own feelings in inadequacy.

hixxy:
Khaled made an inquiry nearly a year ago. If after all this time he still needs guidance, and assuming he's already done his own homework first, then he's welcome to msg me privately on the matter.

Joined: Apr 2004
Posts: 871
Sat Offline
Hoopy frood
Offline
Hoopy frood
Joined: Apr 2004
Posts: 871
Originally Posted By: beer
I'm not here to spoon feed you, put on your big boy pants and do it yourself.
[..]
I hope you're not implying that I'm the one acting high, mighty, and superior.

One single post. Amazing.

Originally Posted By: beer
he's welcome to msg me privately on the matter

He could, but so far you've done nothing to show your expertise on the subject. Moreover, if you know anything about design of security-related algorithms, you would know it is in everyone's best interest that it gets as much public scrutiny as possible.

Khaled asked for help with a problem, you're not providing a solution, and yet you're making claims about how hard the solution would be to implement. Why don't you put your money where your mouth is, and present a solution right here?

If you don't, the conclusion must be that either you don't know, or you don't care all that much. Either way you'd have made a lot of noise for nothing.


Saturn, QuakeNet staff
Sat #229850 18/02/11 05:44 AM
Joined: Jul 2007
Posts: 66
B
Babel fish
Offline
Babel fish
B
Joined: Jul 2007
Posts: 66
Originally Posted By: Sat
Originally Posted By: beer
he's welcome to msg me privately on the matter

He could, but so far you've done nothing to show your expertise on the subject. Moreover, if you know anything about design of security-related algorithms, you would know it is in everyone's best interest that it gets as much public scrutiny as possible.

By the same token, nobody has outlined their expertise on this subject. All I've seen is a lack thereof which doesn't exactly motivate me to oblige.

Public scrutiny only has value when the people doing the scrutinizing have a level of knowledge & experience on the subject. From what I've seen thus far this is hardly the place for such discussions. If you actually have genuine experience dealing with encryption and security systems then by all means let's move this to a forum of peers where the conversation can flourish rather then continue the useless bantering & petty insults going on here.

Quote:
Khaled asked for help with a problem, you're not providing a solution, and yet you're making claims about how hard the solution would be to implement. Why don't you put your money where your mouth is, and present a solution right here?

As I've said, he's welcome to msg me privately. Beyond that nobody here has given me any indication I should take anything they say seriously. People are free to make all the demands they like but if they don't provide motivation to meet them, they won't be.

Quote:
If you don't, the conclusion must be that either you don't know, or you don't care all that much. Either way you'd have made a lot of noise for nothing.

In all honesty, the more posturing that takes place, the less I care so you are correct in that assessment. I should have read all posts rather then skimming through so. However, that doesn't place blame solely on my shoulders by any means. Had some of these people replied with a little more decency and a little less adolescence, this thread would likely be quite different and far more beneficial to the end goal.

Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
Originally Posted By: beer
... let's move this to a forum of peers where the conversation can flourish rather then continue the useless bantering & petty insults going on here.


This is a forum of peers. And to be fair, the source of most of the "petty insults" are coming from your username. So far you're the only person to have made assumptions about other people's qualifications and intelligence (in fact, you've done so in this very post). Everybody else is genuinely curious what information you think is too complicated for us to understand that you require a private discussion with Khaled.

Secondly: why does Khaled need to message you? Just provide your solution right here. --- as many people have asked you to. Or.. if you're really worried about public scrutiny, you can message him privately. Otherwise, I concur with Sat: you either have no information, or don't actually care enough about actually getting this implemented. A pragmatic person would put aside their ego if they actually believed their information was more valuable than... their ego.

I'll repeat my request again, just in case you want to derail the discussion again with personal attacks: can you please provide us with the information Khaled requested regarding MITM attacks and Blowfish encryption? I'll ask that you please not respond to me unless you plan on sharing this information. Anything else would be useless bantering and petty insults, and I know you don't want that either.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Feb 2011
Posts: 4
N
Self-satisified door
Offline
Self-satisified door
N
Joined: Feb 2011
Posts: 4
If it's on the todo list then that's good enough for me... Unfortunately when I first read this thread I had assumed that it was not in consideration. Especially when a few users argued strongly that it wasn't needed. We could argue that ssl was never needed and just use a wrap... but isn't using port +xxxx nicer?
As for my tests, I didn't think I needed to post a simple loop to explain...
alias looptest {
unset %counter
echo START
set %testtime $ctime
while ($calc(%testtime + 5) >= $ctime) {
inc %counter
}
scon 1 echo END - %counter
}
anything similar is good enough... anyhow 6.2 outputs 200,000 to 250,000 and 7.17 outputs 160,000 to 190,000. (Other commands were put in the loop with similar % ratio differences) Now here's a weird one... If I set the priority of mirc.exe (7.17) to real time, it only uses one core at 100% (when loaded). But if I set it back to normal, it uses all 4 with a range of 40-60%. The weird part is the above loop yields the same results.
I would have naturaly assumed that multi-core would have considerable difference but nope. What's even funier is I was not even aware of all this until I told someone my script was just tested in 7.17 and works 100%... His reply was "Just make sure it still works in 6.xx" What would be really cool is if we could send aliases to cores of our choosing, but probably too hard or impossible to implement. (Just an need idea, like scon 1, have core 1) Anyhow I'll leave that up to u guys to figure out. Always strapped for time. wink
http://msdn.microsoft.com/en-us/magazine/cc163340.aspx

Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
What exactly are you proving with the looptest? It was already pointed out that mIRC is single threaded and does not in any way benefit from multi-core CPUs. mIRC probably won't be multi-threaded in your lifetime, so the feature you described probably won't happen, but, but if you're really requesting multi-core support, please start a new thread-- you're just confusing this discussion by posting it here.

Secondly, is this really the test you ran to prove that blowfish isn't usable on 7.x? Please tell me you've done something more comprehensive than time an empty loop.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Feb 2011
Posts: 4
N
Self-satisified door
Offline
Self-satisified door
N
Joined: Feb 2011
Posts: 4
The loop was actually a specific # not using $ctime as it would include a 1 sec discrepancy. I just put it there so noone hangs up a slower comp. All the tests were to see if the speed difference with the fish patch on 6.2 vs what we use for 7.17 was in fact all due to fish or due to code execute speeds. If you look at previous posts, it was suggested fish be used as a .mrc script and that native support wasn't needed. It is needed... Glad it's on the todo lists. No I don't want a new thread on multi-core. I was just curious if we could control what routines could be sent to specific cores or the thread pool. And as I suspected, not bloody likely.

And as for significance, the user clames under heavy load in an encrypted environment on several servers on several channels, mirc 6.12 (patched) will hang at maximum 5 seconds on a heavy request load (ie many users searching at relatively the same time). He then points out he gets up to a 15 second hang on 7.17 (script with dll's). Most of the work in his script centers around irc text in priv msg and in chans that are using fish encryption.

Maybe we should all enjoy a 15-30ms delay like someone meantioned. After all, 15 chans more than enough for anybody.
I try my best to encourage users to get a shell so they can use the same type of script using perl and sql. But not everyone wants to a pay monthly fee so some prefer the mirc version of my utility. And mostly a lot less complicated to install for novice users who want to use it.

Not only will it make mirc more appealing and convenient to use, it'll make encryption/decryption faster. And by the looks of it I need all the help I can get. What are u going to suggest now? Tell all the users of my script to overclock cpu to keep up?

A simple routine... lol Next time I'll paste 10,000 lines and u can pick which command was a better example for comparison. You keep asking "what tests?" "what tests?". JUST CODE SOMETHING AND RUN IT ON BOTH!!! Are you that lazy???



Joined: Oct 2004
Posts: 8,330
Hoopy frood
Offline
Hoopy frood
Joined: Oct 2004
Posts: 8,330
As I pointed out before, yes, the newer mIRC is slower than the older mIRC. However, any decently written script is not going to need to loop hundreds of thousands of times. In normal use, you're looking at unnoticeable differences in times. I know people who use FiSH on 7.17 and have absolutely no difficulties and they are in many large channels at once.

Once again, the points being made are that there are working and usable options at this time and until this gets to the top of Khaled's to-do list (probably not anytime soon), those work just fine if used correctly. Another point being made is that there are really a very small percentage of users who care about encryption or who would use mIRC's encryption instead of a third party's encryption if it were added. Many other features are desired by a much wider audience and those deserve to be higher up on the list.


Invision Support
#Invision on irc.irchighway.net
Joined: Jul 2007
Posts: 66
B
Babel fish
Offline
Babel fish
B
Joined: Jul 2007
Posts: 66
Originally Posted By: argv0
Originally Posted By: beer
... let's move this to a forum of peers where the conversation can flourish rather then continue the useless bantering & petty insults going on here.

This is a forum of peers. And to be fair, the source of most of the "petty insults" are coming from your username. So far you're the only person to have made assumptions about other people's qualifications and intelligence (in fact, you've done so in this very post). Everybody else is genuinely curious what information you think is too complicated for us to understand that you require a private discussion with Khaled.

When you are done pointing your finger at me, be sure to point it at yourself as well. Your attitude isn't one that's lead this thread in a positive and forward-moving direction of any kind.

Unless all of "you" have working knowledge and experience of encryption, security, and associated delivery systems, then no, this is not a forum of peers in that regard. And your curiosity on the subject is of no concern to me.

Quote:
Secondly: why does Khaled need to message you? Just provide your solution right here. --- as many people have asked you to. Or.. if you're really worried about public scrutiny, you can message him privately. Otherwise, I concur with Sat: you either have no information, or don't actually care enough about actually getting this implemented. A pragmatic person would put aside their ego if they actually believed their information was more valuable than... their ego.

There's nothing to discuss with you about an offer I've made to someone else. Had you been included in the invitation then it would be otherwise, but you weren't. Ego plays no part in any of this but I have no interest in explaining it to you.

Further there's no mystery on my stance, I've made it quite clear... Here's a refresher: "In all honesty, the more posturing that takes place, the less I care..."

Quote:
I'll repeat my request again, just in case you want to derail the discussion again with personal attacks: can you please provide us with the information Khaled requested regarding MITM attacks and Blowfish encryption? I'll ask that you please not respond to me unless you plan on sharing this information. Anything else would be useless bantering and petty insults, and I know you don't want that either.

The irony in the above quote is humorous. Now, it seems you've missed a previous statement of mine. Here's another refresher, "As I've said, he's welcome to msg me privately. Beyond that nobody here has given me any indication I should take anything they say seriously. People are free to make all the demands they like but if they don't provide motivation to meet them, they won't be."

In other words, don't waste your breath asking because I simply do not care about any of your requests. They will all be declined so maybe it's best you adhere to your own request and not respond.

Joined: Jun 2003
Posts: 994
C
Hoopy frood
Offline
Hoopy frood
C
Joined: Jun 2003
Posts: 994
Originally Posted By: beer
hixxy:
Khaled made an inquiry nearly a year ago. If after all this time he still needs guidance, and assuming he's already done his own homework first, then he's welcome to msg me privately on the matter.

Sounds to me like you think Khaled does nothing whatsoever but spend time researching things for you and you alone. In the last year, Khaled did absolutely nothing but finish bringing mIRC to the point where it's a more complete unicode client. I'm sure he had plenty of time to do research for you as well.

What's your problem re: giving him some answers? It's not like he works for you, or something. Like has been said over, and over, and over, and over .... Give him some information like you were asked, otherwise drop the subject.


Last edited by CtrlAltDel; 18/02/11 05:10 PM.

I refuse to engage in a battle of wits with an unarmed person. wink
Joined: Jul 2007
Posts: 66
B
Babel fish
Offline
Babel fish
B
Joined: Jul 2007
Posts: 66
Originally Posted By: CtrlAltDel
Originally Posted By: beer
hixxy:
Khaled made an inquiry nearly a year ago. If after all this time he still needs guidance, and assuming he's already done his own homework first, then he's welcome to msg me privately on the matter.

Sounds to me like you think Khaled does nothing whatsoever but spend time researching things for you and you alone. In the last year, Khaled did absolutely nothing but finish bringing mIRC to the point where it's a more complete unicode client. I'm sure he had plenty of time to do research for you as well.

....Wow, ... Is this even meant to be serious? I have neither ever asked Khaled to do anything for me, nor do I care how he spends his time. And how do you confuse asking someone to do some reading on their own first as asking them to do reading for you? Kindly get your head out of the clouds.

Quote:
What's your problem re: giving him some answers? It's not like he works for you, or something. Like has been said over, and over, and over, and over .... Give him some information like you were asked, otherwise drop the subject.

How in the world does offering Khaled direct help translate into you thinking I have a problem answering his questions? In addition, I've said repeatedly that I do not care about anyone's demands in this thread. It's astounding how you can take something made very clear and become so confounded by it. Only fools keep doing the same thing while expecting a different result. You've reminded how easy it is to overestimate a persons common sense. Please make more of an effort to pay attention.

Joined: Jun 2003
Posts: 5,024
M
Hoopy frood
Offline
Hoopy frood
M
Joined: Jun 2003
Posts: 5,024
This is a general response not directed to any particular person.

There's nothing wrong with feeling passionately about something, but as this thread has pretty much fallen into a personal dispute that has no value to the original feature suggestion, I'm regrettably locking it.

I would remind all posters to read (or re-read) the sticky topic at the top of this forum by d00dman and try and stay within those guidelines in future.

Cheers smile


Mentality/Chris
Page 1 of 4 1 2 3 4

Link Copied to Clipboard