[Security] CipherIM: re-post at /psa's request

David Banes david at banes.org
Sun Aug 24 21:14:40 CDT 2008


A while back I offered to re-post an outline of how we handled crypto  
in our IM client, CipherIM in the early 2000s. Here it is;

On 19/08/2008, at 7:14 AM, Peter Saint-Andre wrote:

> David Banes wrote:
>> I'll hover here and chip in, we went through all of this with  
>> CipherIM our proprietary Im client in the late 90's 'til 2001.
>> We did end up generating a key pair at client install time  
>> (including testing password strength with a little feedback  
>> 'progress bar' ) and then storing the public part of our keys on  
>> the client domains server. It all worked fine. We setup SSL client  
>> -> server, then generated a one time symmetric key for each session.
>> I did write all this up earlier, happy to re-post if I can find it.
>
> Sure, that'd be great!
>
> /psa
>


---------------------------
CipherIM was architected in a similar way to SMTP, client/server,  
with a similar addressing scheme and protocol syntax. The data format  
was different though being single line CRLF terminated with spaces  
used to delimit the elements of a command/message, for example;

100 TO dbanes at cipherim.com FROM test at cipherim.com <command  
parameters> <message> <signature>

The security was fairly simple public key with private one time  
(session) keys and digital signatures.

Simply, an SSL like connection was made by the client to the server  
and the clients identity and public key was passed to the server.  
Users rosters where stored on the server.

When two parties wanted to chat a one time symmetric key (eg  
Blowfish, 3DES) was created by the initiator, encrypted with the  
other parties public key (retrieved from the server) and passed to  
the other party. This session key was then used for that session, we  
had the facility to refresh the key automatically at a predetermined  
interval. Messages were time stamped and sequenced, and passwords  
tested for strength at installation.

Just the message was part of the '100' command was encrypted and then  
MIME encoded. We could also run in a mode where each IM was signed  
with the sender private key.

File transfers used the same mechanism with a digital signature of  
the file to be sent being passed across the channel to the recipient.  
File transfer ran concurrently with chat and commands like '...is  
typing a message', 'away'.

CipherIM also integrated with SMS and email. For example if you set  
yourself to 'BUSY' and someone tried to chat to you they would be  
prompted to send an SMS or email instead.

The last version of CipherIM was a rewrite on top of the  
jabbercom.dll using OpenSSL, Turbo Powers crypto libraries and it had  
IE embedded for tabbed browsing alongside the IM.:)

Focussing on the security angle attracted some interesting beta  
testers, eg; First America, Canadian Army, Cisco, NYU, LaPoste, AT&T,  
WebEx, eBay, Cable & Wireless, Nortel, Federal Police, Defense  
Signals, Entrust etc.

The project died due to lack of funding and my full time work running  
R&D for Symantec Security Response in APAC taking all my time.

I'm still catching up with the XEP's as it was 2003 when I last took  
a good look, so i can't comment on security in the stack at the  
moment. But i note that everyones using SSL now, that's a good start!

Here's the old site...
http://www.cleartextsystems.com/ct_cipherim/

---------------------------

A small piece of history that appears to be relevant again.

David.


David Banes
web: http://davidbanes.com/
pics: http://web.mac.com/dbanes/
email:  david at banes.org
xmpp: dbanes at clearim.net
Director & Secretary, Internet Industry Association


------------------------------------------------------------------------------------------------
Email Security by Cleartext a CO2 Free company - www.cleartext.net
------------------------------------------------------------------------------------------------


More information about the Security mailing list