Messages

1

Mircryption / Re: A Couple Blowssi Suggestions

« on: May 19, 2014, 09:26 AM »

Also, just ran into a minor bug that crashes blowssi.  I set a cbc channel key for my channel, and when I gave the key to a friend of mine, he forgot to set it to cbc, and defaulted it to ecb.  So, when he sent a short test message "test" to the channel, it crashed my blowssi script.

This comes from an issue with the cbc handling portion of decrypt_msg.  When you strip the +OK and the extra character for the *, then decode the base64 message, it leaves you with less than 8 bytes when you grab the randomiv portion of the message.  I solved this with a simple length check on $randomiv.

Code: Perl [Select]

1. sub decrypt_msg {
2.   my ($key, $message) = @_;
3.  
4.   # Added to allow for returning the unmodified message, since it would otherwise have the +OK... stripped from it before entering the cbc section
5.   my $orig_message = $message;
6.  
7.   ...
8.  
9.   my $randomiv = substr($message,0,8);
10.   return ("{unencrypted} $orig_message",$method) unless length($randomiv) == 8; # Sanity check that prevents a CBC crash

2

Mircryption / A Couple Blowssi Suggestions

« on: May 16, 2014, 08:08 AM »

I had an issue with channels not decrypting for all messages.  It took me a while to figure out that certain users/bots were using different channel names for the encrypted channel that we were using.

For example ...
The channel is registered as "#Test", so you "/join #Test" and you "/blowkey #Test myprivatekey".  This works for most things, however, we had some bots who were set to send to "#TEST" and these messages were not being decrypted.  I finally realized that I needed to "/blowkey #TEST myprivatekey" as well to get those to properly decrypt.

My suggestion would be to handle all hash keys in the %channels hash as lowercase hash-keys (not the encryption keys).  The simple fix (theoretically) should be replacing all calls to the key hash from

Code: Perl [Select]

1. $channels{$channel}

to

Code: Perl [Select]

1. $channels{lc $channel}

I can't think of a reason where you'd need the channel/nick identifier to be case-sensitive, but it saves you from needing to have duplicate entries just to catch all the cases.

My other suggestion would be to not have the blowssi script handle the pasting decrypted messages directly to the window and directly sending the encrypted messages to the server.  Instead, just catch the events and alter the contained message and forward it on, allowing Irssi to naturally handle the messages.

For example, if I want other scripts to be able to interact with the recieved/sent encrypted messages, your script in its current form would prevent that from happening, since you're using add_signal_first.  If I wanted a script that prevented me from typing certain words into the irc window (like if I were to blacklist my passwords from accidentally being pasted into the input box), I'd need my checker script to process the input before the blowssi script would encrypt the input and forward it to the server.

Example:

Code: Perl [Select]

1. sub handleMessagePublic {
2.   my ($server, $msg, $nick, $address, $target) = @_;
3.  
4.   $msg = decrypt_msg($target, $msg);
5.  
6.   Irssi::signal_continue($server, $msg, $nick, $address, $target);
7. }
8.  
9. sub handleMessageOwnPublic {
10.   my ($server, $msg, $target) = @_;
11.  
12.   $msg = encrypt_msg($target, $msg);
13.  
14.   Irssi::signal_continue($server, $msg, $target);
15. }
16.  
17. Irssi::signal_add_first('message public', \&handleMessagePublic);
18. Irssi::signal_add_last('message own_public', \&handleMessageOwnPublic);

(Obviously your Blowssi script is set-up differently than how this example works, but I hope the gist is clear.)

If you considered this route, you'd want the incoming encrypted messages to be processed first, and the outgoing encrypted messages to be processed last.

Note: I don't use the keyx/dh1080 stuff, so I'm not sure if any of that would be affected by my suggestions, just thought this might be of some use to the cause.  Nice useful script though, so thanks for the hard work you've put into it.


Also, I had an issue with handling keys that have the '%' sign in them.  They don't output correctly and might need to be escaped.  Not a big deal though.

3

Mircryption / Irssi Bot Using Blowssi

« on: February 02, 2014, 10:43 AM »

I have an Irssi bot that needs to be able to understand encrypted channels using Mircryption.  After getting Blowssi installed and set-up on my Irssi bot, I noticed that my triggers like !ep for TvRage only worked on unencrypted messages.  After fiddling with Blowssi for a while, I finally came up with this workaround:

At the bottom of "sub decrypt {}" change:

Code: Perl [Select]

1. Irssi::signal_stop();
2.   return 1;

to

Code: Perl [Select]

1. if ($event_type eq 'message_public') {
2.     Irssi::signal_continue($params[1], $result, $params[3], $params[4], $params[5]);
3.   }
4.   else {
5.     Irssi::signal_stop();
6.   }
7.   return 1;

Is there a better option to retain the ability of my other scripts working from the decrypted text after Blowssi decrypts it?

As a clarification for my problem:

My triggers are currently set to

Code: Perl [Select]

1. Irssi::signal_add("message public", \&handle_message_public_sub);

So, when I do "!ep <tvshow>" in unencrypted text from another account, it responds normally, however, when I run the same command in encrypted text, Blowssi decrypts it just fine, but my !ep trigger never fires.

My solution above posts double on my bot's screen (which isn't really an issue, since it's a bot and no human is going to look at it very often):

18:40:46 <MyNick:#chan> !ep <tvshow>
18:40:46 <!MyNick> !ep <tvshow>

I thought about adding a custom signal to be emitted by Blowssi for when Blowssi decrypted a message_public type.  However, I'm going to need to be decrypting up to 30 times per second and handling the public messages once I get all of my bot scripts written, so I wasn't sure on how good adding another signal emit would be.