I already did the search to see if it was brought up before, and I don't believe it has, or at least not in this way. We already have one way encryption, MD5, added to mIRC. $encode and $decode isn't encryption before anyone replies. It would be nice if in a future verson to have an identifier to encrypt both ways. Frontwards and backwards, like blowfish. And I know there are dlls out there, I have one. I'm just suggesting this as the next step in making it built in.

MD5 is not encryption. MD5 is hashing. Encryption is both encryptable and decryptable, MD5 is not. Blowfish is considered strong cryptography and therefore fa 6.0under the same problems that SSL does.

I would think there would be a rights/copyright infringement if it were intergrated with mirc, unless thats what yo were inferring by falling under the same category as SSL.

Well, anyways. I just hope gets built in encryption sometime. Cause it would probably be common use.

In common use by who? How many people would bother using strong encryption for IRC conversations? 99% of what people are saying is so painfully dull and unimportant to anyone at all that it would be a waste of their time to encrypt it and the receiver's time to decrypt it.

blowfish would be a nice addition, but I think the world is still governed by stupid export restrictions on such things as encryption and useful information.

I've seen only one blowfish DLL, and it's nice, but I don't like the fact that it chooses base64 (ie MIME/$encode) for the string output, instead of hexidecimal as most encryption and hash routines will output in a text environment.

If blowfish is ever added to mIRC, please use hex or add the option of dumping to a &binvar.

- Raccoon

It would be best to have blowfish done like the below.
$bf(string,key).hex
And as for commas in the string, it would consider whatever is after the last comma inside the identifier to be the key. And .hex would consider the output to be converted to hex, and the input to decode to be hex before conversion.

About exporting laws, I don't know how we would solve that problem.

If Blowfish ever were added then it would most likely use (and should use) the same behaviour that all other mIRC identifiers use: If you want a string containing commas to be treated as a single parameter then assign it to a variable first.

Maybe you're right. It would be important however to get encryption added in the first place though.

Only recently joined, so a bit late in weighing in. There is also a scripted version of blowfish, though its not quite as fast as the DLL.

You can find it here.