mIRC Home    About    Download    Register    News    Help

Print Thread
Joined: Jul 2003
Posts: 655
Om3n Offline OP
Fjord artisan
OP Offline
Fjord artisan
Joined: Jul 2003
Posts: 655
A native mirc text encryption system would be great. Namely blowfish, but the ability to use other encryptions (if you have the dll's in your mirc directory) would be nice too i suppose. Although my whole suggestion revolves around blowfish.

Why not script it? Well as you can imagine is easily done and there are plenty of dll's and script methods of encoding/decoding, but the main problem is this must be intertwined with all other scripts in order for them to work. Which is both highly undesirable and troublesome. Not to mention the performance loss by using a patch/dll or dll/script combination.

Because of this problem somebody has been making patches to add this support to mirc for a long time, but again using this third party patch is undesirable. Not only does it have some fundamental problems, but it requires an accompanying mirc script in order to handle input echo's correctly, and has several bugs surrounding actions and notices. (besides the fact that its a breach of mirc aup).

The text encryption part of the feature seems like it would be fairly simple to implement, as the encryption of outgoing messages (msg notice action dcc etc, not server communication..) would be the very last thing applied to the text after all utf8/sjis etc, & similarly decoding would be the very first thing applied to an incoming message that is detected as encrypted.

Some of the features and options could include...
- per channel and per user incoming & outgoing keys
- priority ordering for keys
- secure key exchange (DH?, would be great but not neccersary i guess)
- message marking.. that is; marking the decoded/encoded messages in some way, if option enabled, so that you can tell if a message sent/recieved was encrypted (popular methods include a tag at the end of the line, and changing the color of the closing '>' around the nickname, personally i prefer the latter)
- ability to define the encrypted text prefix that mirc will use for outgoing messages, and ability to define (multiple) prefixes that mirc will see and attempt to decode ( ie: +OK, mcps, (blfs) )
- option to encrypt text by default (obviously will only encrypt if an outgoing key is setup for that user/chan, or encrypt manually (some kind of alias/command at beginning of input to specify encryption should be used)
- a way to send plain text (unencrypted) to a user/chan even if the above option is enabled
- options to globally enable/disable both incoming and outgoing encryption
- ability to enable some kind of key encryption so keys are not plain text in ini settings file


A tab addition to the address book dialog, setup in a similar way to the control and colors tabs seems appropriate for keys/chans/users list?


"Allen is having a small problem and needs help adjusting his attitude" - Flutterby
Joined: Jan 2004
Posts: 2,127
Hoopy frood
Offline
Hoopy frood
Joined: Jan 2004
Posts: 2,127
Other "features and options" should include:

1. Uses a public SALT to generate unique encryption keys for each message - which ensures that repeated messages don't encrypt the same, because they're using a different key each time. For example, simply using a %sequential value that increments after each of your messages, so the 1st message uses key of $md5(secret_password 1), the 2nd msg uses $md5(secret_password 2) etc.

2. A newer (spelled LONGER) hash function than $md5. MD5 has long ago become considered insecure, especially if being used to generate passwords as above. Would be nice if mIRC offered either the 160-bit SHA-1 hash, or the SHA-2 that has hash sizes up to 512-bits in length.

3. Perhaps use the AES cipher instead, or as an optional choice, which can also be used without paying fees. Blowfish has the problem of a long key setup, where it basically does the work effort to encrypt over 4kb of text in order to set up the encryption arrays. The long key setup strengthens the cipher against a brute force attack, but it slows down actual usage. a built-in blowfish would be able to re-use the 4kb of key setup only if it does NOT use the unique session keys described in #1 above.

4. mIRC can simplify the encryption by using CFB mode feedback, since it doesn't require using the decryption side of the cipher, but instead inverts the way the feedback buffer is XOR'ed against the encryption. This also means that a partial garble near the front of the message only affects up to 2 blocks, but the remainder of the message can be seen correctly. CFB also avoids the need to add junk padding to the end of the message so that it's a multiple of the blocksize.

5. Would the encrypted message be able to be sent as binary, or would it need to be text-encoded before being sent? If it needs to be encoded, that lengthens the message by 4/3rds, since it takes 4 $encode characters to represent 3 binary encrypted bytes, plus having the public-salt and the other overhead that needs to be sent along with the message. Instead of using the 64-character alphabet of $encode or mime/uuencode, perhaps it can do some of the things that yENC does in usenet to shorten messages. Even finding enough characters to have an 85-symbol encoding alphabet means the encoded message is only 5/4ths larger instead of 4/3rds larger.

6. Regarding separate encryption per user - that would need to have a handshake method for identifying each other in other ways than by nick or mask. It would also need to have the ability to use different public-keys or private-keys with each person you directly converse with, so that your messages with everyone can't be compromised by a security failure with 1 person.

7. The encryption process would need to be clearly documented, so that people can easily reproduce it to verify it's actually being done correctly. There's a famous bug in early blowfish programs because of incorrectly sign-extending an 8-bit value into a 32-bit value.

8. The biggest hurdle may be that some countries ban strong encryption that their government can't easily crack, so that might make it hard for mIRC users there to use the program. I wouldn't want to have a secure-mIRC trying to converse with a 40-bit-encryption mIRC.

Joined: Jul 2003
Posts: 655
Om3n Offline OP
Fjord artisan
OP Offline
Fjord artisan
Joined: Jul 2003
Posts: 655
I based my suggestion mainly around blowfish, for the simple fact that it is already used for many, and there are already decent script/patches for other clients. So the compatibility level is fairly good. (bindings already exist for tcl/php/nix clients/etc)

Just some responses and quiries (im not particularly knowledgable about everything your discussing)

How effective would using a public key and unique per message keys be, i mean it would reqiure interaction with a third party and constant key exchanges? wouldn't that create lag? or do i misunderstand how that works.

6. As far as the current blowfish patched/scripts are concerned the best one (listed below) seems to use a Diffie-Hellman 1080bit key exchange method hashed with sha-256.

8. I think such a feature would just have to be treated in the same manner that SSL is, any dll's would not be included, but if present the options become availible for use. ie; in terms of blowfish if a compatible blowfish dll is not found the feature is simply not availible.

Again suggestion based around blowfish being the default encryption used with the feature because it is already used quite widely on mirc and other clients.

Most of the people i know that communicate over irc (at least on windows) with encryption use a patch/dll that can be found at the following url, or they use Invision which has several types of encryption already scripted in (not sure on its method, probably just a dll or its own scripted encode/decode algorithms).

http://fish.sekure.us/

In the end i do agree that a more well rounded feature to dynamically support many types of encryption would be great. But that almost feels like asking to much so i would probably be happy with just the native blowfish (obviously a little more well rounded and bugless than the above example)

Last edited by Om3n; 20/08/06 04:00 PM.

"Allen is having a small problem and needs help adjusting his attitude" - Flutterby
Joined: Jan 2004
Posts: 2,127
Hoopy frood
Offline
Hoopy frood
Joined: Jan 2004
Posts: 2,127
Public Key is rarely if ever used for encrypting the messages, because it is many times slower than normal encryption. Instead, the public key is used to share the actual encryption key that's used. Unique session key doesn't require constant handshaking, because you're sending the public unique constant along with the message. if the secret key is "password", you can use the hash output of $md5(password sequential) as your session key, then send the 'sequential' along with your encrypted message. The receiver already knows the secret value, and uses $md5 to re-create the unique session key. Since the $md5 outputs are all different, this causes the same message to be encrypted differently each time. The secret password only needs to be handshaked the one time.

I agree that 1 strong cipher in a strong system is worth more than any group of ciphers that don't have both. The AES cipher is widely used, but the criteria for it included many things other than being a strong cipher, such as being able to be done in low-tech smartcards, short key setup times, low memory usage, etc. I'm not sure whether it would overwhelm mIRC to have to perform the 4kb encryption key-setup for each message in a busy #channel.

Joined: Feb 2004
Posts: 201
J
Jae Offline
Fjord artisan
Offline
Fjord artisan
J
Joined: Feb 2004
Posts: 201
I believe it may be a bit of a headache for Khaled to implement, although some better interface to intercept outgoing / incoming messages?
Perhaps you could simply write a form of bnc / socks proxy or such that can intercept PRIVMSG and encode/decode transparently on the fly without affecting mIRC, other than say perhaps mIRC dialogs / menu's to tell the program proxying how to do its job, encrypting to a person / channel, getting keys and so forth.
Point being perhaps there it a better way to add such functionality using widely avaliable code via a more transparent means as its really a matter of applying encryption in the appropriate layer, and less hassle for people who dont want to use it and be taxed by a 100-500k increase in mirc exe size, by something that could quite easily be implemented in a less intrusive manner.

Joined: Jul 2003
Posts: 655
Om3n Offline OP
Fjord artisan
OP Offline
Fjord artisan
Joined: Jul 2003
Posts: 655
Actually the bulk of the extra size would be the third party encryption dll, such as blowfish.dll. Which due to international laws would not be included with mirc just like openssl isn't.

The internal code would be very minimal for the actual encoding/decoding (much less than utf8 for example), since it would just need to call a function in the dll at the correct times. The biggest part of addition to mirc would logically be the code for the settings dialog that would essentially work much the same as the nick colors tab in address book (does some checks to see if its needed, if so whats needed, then applies it).

As mentioned the problem with anything that is not native, is that it bypasses all other events rendering the rest of your script useless unless you write it in all over the place.

Lucky for me i dont have all sorts of event handling scripts, so by using a dll, ini file for settings, and no dialog its all of 10 lines of code.

The one script i do have that handles certain events is a regex message filter that i wrote myself (basically antispam), which of corse does not work in channels/queries that use encrypted conversation. For it to work i would have to tie the scripts together.

As far as being intrusive goes, it would be no more so than utf8 support is to those who dont use utf8. ie un-noticable.


"Allen is having a small problem and needs help adjusting his attitude" - Flutterby

Link Copied to Clipboard