radagast has asked for the wisdom of the Perl Monks concerning the following question:

I am currently in the beggining stages of developing secure chat software in Perl, mainly for my own benefit (even though there may be free ones out there). It will be basically peer-to-peer chat although I should be able to design a secure chat server later on. All communications should be handled by IO::Socket.

Here are the modules/components I'll be using. Each client will develop a public/private key pair using this four line Perl RSA code I found at www.cypherspace.org/~adam/rsa. A random session key will be generated and RSA encrypted with the public key of the other client. Once the session key is decrypted, I will use the Blowfish module for encryption of the transmission.

I have a question regarding performance. As this is a chat system and is limited in speed to manual typing, I don't foresee any performance slowdowns. However, should I decide to transmit files across similar to IRC's dcc send command, will performance be sacrificed? Also, if I reimpliment this as a secure chat server, provided I fork of the processes accordingly, will performance also suffer.

I have toyed with the idea of writing this in c but why do so if I can do it in perl and make it more portable in the process.

Replies are listed 'Best First'.
Re: Secure Chat Clients
by merlyn (Sage) on Nov 01, 2000 at 18:50 UTC
    You might at least make sure your client and server are Jabber compliant. I'm pretty sure the protocol is flexible enough to exchange secure keys, and probably already does. {grin}

    -- Randal L. Schwartz, Perl hacker

[reply]
Re: Secure Chat Clients
by AgentM (Curate) on Nov 01, 2000 at 21:16 UTC
    I'm wondering about how you plan to implement these chat programs. If they are in "telnet" style, then every character is sent one at a time, depending on you implementation, potentially each one with encryption bloat. There, I certainly see a performance issue, increasing as the connection gets fuzzier. On the other hand, if you are interested in writing something like a messenger where you type the entire message before the other is able to see it, then I see performance benefits over the other. If I'm wrong about such a "graffiti" chat method, then forgive me- you pretty mcuh can't get much faster than that. You will want to send your packets as large as possible to minimize fragmentation. Of course, with chatting, this becomes impractical, so sending a question or a sentence at a time would help you considerably.

    Really, it all depends on what you will be using this for. If you use the telnet method and you and your peer are relatively close and the speed is OK, then you're done (you did mention personal use). If, however, if you do find that you need a performance boost, then you should switch to using a messenger-type system.

    server: implementing a server (as you say with fork on one user) will give you little if any benefit since you are doing exactly the same thing, only in a different process which is waiting on blocked I/O from the other.

    If you send a file vs. one character, then you will certainly notice a simulated bandwidth increase since you are using one encryption function once and sending it perhaps as one or two packets instead of 100 encrypted packets for a sentence.

    Since it is only chat, you may want to consider a faster albeit not-so-secure encryption algorithm. Something as simple as XOR or MD5 would certainly do for me since i may be only afraid of packet sniffers. On the other hand, if what you plan on sending through is top secret, then you should certainly use strong encryption.

    So, unfortunately, the answer to your questions is: it depends, since it depends on whether or not you see need for such a performance boost when you actually get it running for the first time. I would certainly recommend keeping fragmentation to a minimum, but WUWIWUG (what u want is what u get) and this usually becomes impractical in things such as telnet and chat. Good luck!

    AgentM Systems nor Nasca Enterprises nor Bone::Easy nor Macperl is responsible for the comments made by AgentM. Remember, you can build any logical system with NOR.
[reply]
      I'm no expert on encryption, but many session encryption schemes have no overhead aside from the initial key exchange, so sending one payload character only requires one encrypted character (and all the TCP overhead, of course).

      --isotope
      http://www.skylab.org/~isotope/
[reply]
Re: Secure Chat Clients
by brainpan (Monk) on Nov 02, 2000 at 04:20 UTC
    radagast, if you're planning on the possibility of scaling this to be more than just for your own personal use, (and even then) why not just write a plugin for tik or gaim (which has built-in support for perl)? Unless this is intended to be a proof of concept / educational project it seems like overkill to reinvent the wheel when there are so many other chat clients out there.

    While we're on the topic, mentioning that AOL has opened their AIM protocol may be worth knowing.

    And before people reply to this post, yes, I do realize that I've only mentioned AOL compatible clients here. Others have provided links to alternate systems, and I don't see a need to duplicate that here.
[reply]

Back to Seekers of Perl Wisdom