[Gaim-e-developer] Re: [Gaim-devel] Support for Secure IM across multiple clients and services

[<gai...@li...>]

Hello Alan,

I understand the need for a common encryption mechanism.  And I
understand that some work is being done in this respect.

However, there are a couple of points that I would like to share with
you.

1) gaim does not support encryption unless the protocol itself supports
it, or at least gaim will support it in the future.

2) encryption on gaim is handled by two plugins, gaim-e and
gaim-encryption, so your best bet would be to contact them directly.

3) current IM encryption methods uses two different approaches
:	a) GPG based encryption, gaim-e, fire, and miranda use this method
(afaik)
	b) SSL based encryption, gaim-encryption and trillian uses this method
(afaik)

4) trillian is closed-source, so I am not sure how co-operative they are
going to be.

Chances are you are already aware of this points, but just in case you
don't I thought I would write them down.

Both gaim-e and gaim-encryption can be found on sourceforge.

I hope to hear more on this.  I have forward it to the gaim-e dev
mailing list

Sincerely,

Dario

PS: I am the UI developer for gaim-e.

On Mon, 2003-06-23 at 15:20, Alan Humpherys wrote:
> Hello,
>=20
> Hopefully I am sending this to the right address, so that it eventually=20
> gets to the right person.
>=20
> I am one of the main developers of "Fire"  (Multi-protocol IM client=20
> for Mac OS X) an open source freeware project also hosted at=20
> sourceforge.net.  ( You can visit our web site at http://fire.sf.net )
>=20
> I am writing because I have a desire to promote better interoperability=20
> of Secure IM between various third party IM clients.  At the present=20
> time, Fire, GAIM, and Trillian all support mechanisms for encryption of=20
> Instant Messages, however all three use incompatible schemes, and=20
> therefore can only be used when both ends of the conversation are using=20
> the same client.
>=20
> I would like to create a working group whose focus is promoting=20
> interoperability of Secure Instant Messaging.  As one of the leaders in=20
> the third-party IM client world, I believe strongly that this effort=20
> will only be successful if your team is involved in it.
>=20
> Working Group Charter
> ---------
> The creation of an open standard that any IM client creator can follow=20
> to provide interoperable Secure Instant Messaging across any IM service.
>=20
> Technical Scope
> ---------
> 1. Key Exchange methodology and protocols
> 2. Message Encryption
> 	- Selection of algorithm(s)
> 3. Message Signing
> 	- Selection of algorithm(s)
> 4. Definition of data payload structure
> 	- Markers indicating
> 		algorithm
> 		signing status
> 		encryption status
> 	- Data format and encoding
> 5. Detection of compatible client on other end of conversation
>=20
> Technical Challenges to Address
> ---------
> 1. Data payload length limitations on some services
> 	- Some data payloads (like keys or long signatures) may need to be=20
> broken apart  and reassembled.
> 2. Packet frequency limitations on some services
> 	- AIM rate throttling
> 3. Server interpretation of data
> 	- Some IRC servers truncate messages after the first newline/return
> 	- Some services may not deal with null bytes
> 	- Some services may only deal with 7-byte ASCII
> 4. Allowance for disconnected operation
> 	- Yahoo, MSN, Jabber allow offline messages to be sent
> 5. Reasonable operation with non-compatible clients.
> 	- Ensure that secure messages sent to non secure clients can be=20
> understood by the remote user to be an encrypted message, that their=20
> client can't decipher.
> 6. Compliance with applicable laws and patent restrictions.
> 7. Secure messaging in a group chat environment.
> 8. Backward compatibility with our existing client bases
>=20
> There are probably other issues to address, but this is a first attempt=20
> at outlining them.  I don't intend to overly formalize this process,=20
> nor make it take more time than necessary.  The goal is to build upon=20
> the three great solutions we already have, and come to an agreement on=20
> a common solution we can all move forward with.
>=20
> Please have the right person contact me at your earliest convenience so=20
> we can discuss this further.
>=20
> Thank you,
> Alan Humpherys
> --
> Fire Development Team
> al...@us...
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: INetU
> Attention Web Developers & Consultants: Become An INetU Hosting Partner.
> Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
> INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> _______________________________________________
> Gaim-devel mailing list
> Gai...@li...
> https://lists.sourceforge.net/lists/listinfo/gaim-devel