Menu
▾
▴
Re: [Gaim-e-developer] Re: [Gaim-devel] Support for Secure IM across multiple clients and services
|
From: <gai...@li...> - 2003-06-24 23:00:14
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ceterus parabus(all things being equal), I think interoperable IM is a good thing(tm). However, the popularity of the SSL schemes overlooks a key feature of using our methodology. Unless you pay a certification authority, you don't know who you're talking to, just that it is secure. The security of our method relies in strong gpg public and private keys and the web of trust that goes along with them. Since we encrypt a session key with gpg and then use that for the encryption of the chat, we incur less overhead than using gpg to encrypt and decrypt every IM. This is especially true if the gpg/pgp keys are sufficently large. With gaim now being available on windows, perhaps we should look more at how we could get our plugin to work there, as well as publishing an interoperability document. Adam Schreiber gai...@li... wrote: > I like the concept, honestly... but I have reservations. > > Secure IM is a noble concept and absolutely must be promoted. Making our > modules interoperate would definitely promote popularity of all the > various IM encryption options users enjoy today. That's a good thing! > > However... we also need to offer options. If a security hole is exposed, > not in the algorithms we use, but in our protocols then all secure IM > solutions adhering to that standard would be vulnerable. Keeping our > codebases completely seperate in both form and concept is the only > defense the world as a whole has to protocol vulnerabilities--because > other drop-in solutions are available at all times. > > There are also other technical problems that Dario touched on. gaim-e > has opted to employ gpg as our crypto engine. other IM solutions use > SSL. the two schemes are basically entirely incompatible. If all > codebases out there adopt a standard, one has to win--somebody will be > rewriting their entire codebase. (afaik gaim-e will be doing that for > 2.0 anyways...) > > If we decide to rewrite gaim to be <catchy name>Universal Secure > IM-friendly</catchy name>, we 1) will have to react faster to protocol > vulnerabilities, since a wider audience is affected, and 2) we lessen > our freedom to alter our protocol as needed. > > I like the idea. Can we make it work? > > Stu > >> From: gai...@li... >> Reply-To: gai...@li... >> To: Alan Humpherys <al...@us...> >> CC: Gaim-e Developer Mailing List >> <gai...@li...>, >> gai...@li... >> Subject: [Gaim-e-developer] Re: [Gaim-devel] Support for Secure IM >> across multiple clients and services >> Date: 23 Jun 2003 20:54:57 -0700 >> MIME-Version: 1.0 >> Received: from sc8-sf-list1.sourceforge.net ([66.35.250.206]) by >> mc9-f40.bay6.hotmail.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, >> 23 Jun 2003 20:55:53 -0700 >> Received: from sc8-sf-list2-b.sourceforge.net ([10.3.1.14] >> helo=sc8-sf-list2.sourceforge.net)by sc8-sf-list1.sourceforge.net with >> esmtp (Cipher TLSv1:DES-CBC3-SHA:168) (Exim 3.31-VA-mm2 #1 (Debian))id >> 19UeuP-0008CT-00for <stu...@us...>; Mon, 23 Jun >> 2003 20:55:53 -0700 >> Received: from sc8-sf-list1-b.sourceforge.net ([10.3.1.13] >> helo=sc8-sf-list1.sourceforge.net)by sc8-sf-list2.sourceforge.net with >> esmtp (Exim 3.31-VA-mm2 #1 (Debian))id 19Ueu1-0002gJ-00; Mon, 23 Jun >> 2003 20:55:29 -0700 >> Received: from outbound01.telus.net ([199.185.220.220] >> helo=priv-edtnes61.telusplanet.net)by sc8-sf-list1.sourceforge.net >> with esmtp (Exim 3.31-VA-mm2 #1 (Debian))id 19Uesh-0006gM-00; Mon, 23 >> Jun 2003 20:54:07 -0700 >> Received: from akjz4447y503c.bc.hsia.telus.net >> ([207.6.33.36]) by priv-edtnes61.telusplanet.net >> (InterMail vM.5.01.05.17 201-253-122-126-117-20021021) with >> ESMTP id >> <200...@ak...>; >> Mon, 23 Jun 2003 21:54:01 -0600 >> X-Message-Info: JGTYoYF78jEHjJx36Oi8+Q1OJDRSDidP >> In-Reply-To: <D80...@us...> >> References: <D80...@us...> >> Organization: Message-Id: >> <105...@ak...> >> X-Mailer: Ximian Evolution 1.2.4- Sender: >> gai...@li... >> Errors-To: gai...@li... >> X-BeenThere: gai...@li... >> X-Mailman-Version: 2.0.9-sf.net >> Precedence: bulk >> List-Help: >> <mailto:gai...@li...?subject=help> >> List-Post: <mailto:gai...@li...> >> List-Subscribe: >> <https://lists.sourceforge.net/lists/listinfo/gaim-e-developer>,<mailto:gai...@li...?subject=subscribe> >> >> List-Id: <gaim-e-developer.lists.sourceforge.net> >> List-Unsubscribe: >> <https://lists.sourceforge.net/lists/listinfo/gaim-e-developer>,<mailto:gai...@li...?subject=unsubscribe> >> >> List-Archive: >> <http://sourceforge.net/mailarchive/forum.php?forum=gaim-e-developer> >> X-Original-Date: 23 Jun 2003 20:54:57 -0700 >> Return-Path: gai...@li... >> X-OriginalArrivalTime: 24 Jun 2003 03:55:53.0263 (UTC) >> FILETIME=[820C4BF0:01C33A04] >> >> 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, >> > >> > Hopefully I am sending this to the right address, so that it eventually >> > gets to the right person. >> > >> > I am one of the main developers of "Fire" (Multi-protocol IM client >> > for Mac OS X) an open source freeware project also hosted at >> > sourceforge.net. ( You can visit our web site at http://fire.sf.net ) >> > >> > I am writing because I have a desire to promote better interoperability >> > of Secure IM between various third party IM clients. At the present >> > time, Fire, GAIM, and Trillian all support mechanisms for encryption of >> > Instant Messages, however all three use incompatible schemes, and >> > therefore can only be used when both ends of the conversation are using >> > the same client. >> > >> > I would like to create a working group whose focus is promoting >> > interoperability of Secure Instant Messaging. As one of the leaders in >> > the third-party IM client world, I believe strongly that this effort >> > will only be successful if your team is involved in it. >> > >> > Working Group Charter >> > --------- >> > The creation of an open standard that any IM client creator can follow >> > to provide interoperable Secure Instant Messaging across any IM >> service. >> > >> > 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 >> > >> > Technical Challenges to Address >> > --------- >> > 1. Data payload length limitations on some services >> > - Some data payloads (like keys or long signatures) may need to be >> > 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 >> > understood by the remote user to be an encrypted message, that their >> > 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 >> > >> > There are probably other issues to address, but this is a first attempt >> > at outlining them. I don't intend to overly formalize this process, >> > nor make it take more time than necessary. The goal is to build upon >> > the three great solutions we already have, and come to an agreement on >> > a common solution we can all move forward with. >> > >> > Please have the right person contact me at your earliest convenience so >> > we can discuss this further. >> > >> > Thank you, >> > Alan Humpherys >> > -- >> > Fire Development Team >> > al...@us... >> > >> > >> > >> > ------------------------------------------------------- >> > 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 >> << signature.asc >> > > > _________________________________________________________________ > Help STOP SPAM with the new MSN 8 and get 2 months FREE* > http://join.msn.com/?page=features/junkmail > > > > ------------------------------------------------------- > 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-e-developer mailing list > Gai...@li... > https://lists.sourceforge.net/lists/listinfo/gaim-e-developer > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE++Nf2jU1oaHEI4wgRAp2AAJ9Dt516xLOgti7Z6oasNkcazyXouQCggs+6 Mtf82J1dLeHvkBg48YQJjwE= =QRTd -----END PGP SIGNATURE----- |
