From evan at adiumx.com Thu Feb 9 02:59:21 2006 From: evan at adiumx.com (Evan Schoenberg) Date: Thu, 9 Feb 2006 02:59:21 -0500 Subject: [OTR-dev] Offline ICQ message with OTR crash, I think Message-ID: I've seen this backtrace in the Adium crash reporter a couple times... 0 Libgaim 0x04a62ba8 _gcry_mpi_free 32 1 Libgaim 0x04a5da58 otrl_auth_handle_v1_key_exchange 1320 2 Libgaim 0x04a57f0c otrl_message_receiving 1164 3 Libgaim 0x04a54054 process_receiving_im 192 4 Libgaim 0x04a0654c gaim_marshal_BOOLEAN__POINTER_POINTER_POINTER_POINTER 64 5 Libgaim 0x04a05fe8 gaim_signal_emit_vargs_return_1 304 6 Libgaim 0x04a05ea4 gaim_signal_emit_return_1 108 7 Libgaim 0x04a03d64 serv_got_im 156 8 Libgaim 0x049de5f8 incomingim_chan4 564 9 Libgaim 0x049e086c gaim_offlinemsg 156 10 Libgaim 0x049cef6c icqresponse 420 The usual user explanation is typified by this user's: "sent an otr-ed message to an offline contact. everytime i log on, it crashes again." Any thoughts? -Evan -------------- next part -------------- An HTML attachment was scrubbed... URL: From ian at cypherpunks.ca Thu Feb 9 10:18:58 2006 From: ian at cypherpunks.ca (Ian Goldberg) Date: Thu, 9 Feb 2006 10:18:58 -0500 Subject: [OTR-dev] Offline ICQ message with OTR crash, I think In-Reply-To: References: Message-ID: <20060209151858.GZ31179@smtp.paip.net> On Thu, Feb 09, 2006 at 02:59:21AM -0500, Evan Schoenberg wrote: > I've seen this backtrace in the Adium crash reporter a couple times... > > 0 Libgaim 0x04a62ba8 _gcry_mpi_free 32 > 1 Libgaim 0x04a5da58 > otrl_auth_handle_v1_key_exchange 1320 Good catch. Try this patch: Index: auth.c =================================================================== RCS file: /cvsroot/otr/libotr/src/auth.c,v retrieving revision 1.3 diff -u -r1.3 auth.c --- auth.c 30 Oct 2005 21:01:15 -0000 1.3 +++ auth.c 9 Feb 2006 15:14:36 -0000 @@ -1188,7 +1188,7 @@ unsigned char *buf = NULL, *bufp = NULL; unsigned char *fingerprintstart, *fingerprintend; unsigned char fingerprintbuf[20], hashbuf[20]; - gcry_mpi_t p, q, g, y, received_pub; + gcry_mpi_t p, q, g, y, received_pub = NULL; gcry_sexp_t pubs = NULL; size_t buflen, lenp; unsigned char received_reply; In the event of certain error conditions, received_pub was being gcry_mpi_release()d before it was initialized. Oops. *covers face in shame* ;-) I'm not saying this is exactly the problem you're seeing, but it seems pretty likely. Thanks for the report! Fixed in CVS. - Ian From evan.s at dreskin.net Thu Feb 9 10:34:11 2006 From: evan.s at dreskin.net (Evan Schoenberg) Date: Thu, 9 Feb 2006 10:34:11 -0500 Subject: [OTR-dev] Offline ICQ message with OTR crash, I think In-Reply-To: <20060209151858.GZ31179@smtp.paip.net> References: <20060209151858.GZ31179@smtp.paip.net> Message-ID: <1E01301F-162A-4C1B-8959-08364B22C035@dreskin.net> On Feb 9, 2006, at 10:18 AM, Ian Goldberg wrote: > In the event of certain error conditions, received_pub was being > gcry_mpi_release()d before it was initialized. Makes perfect sense. Thanks for the quick fix; I can definitely believe that was the source of the problem. I'll let you know if the crash is reported again with it applied. :) -Evan -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From asm at CS.Stanford.EDU Mon Feb 13 21:04:46 2006 From: asm at CS.Stanford.EDU (Andrew S. Morrison) Date: Mon, 13 Feb 2006 18:04:46 -0800 Subject: [OTR-dev] OTR Formal Analysis Security Properties Message-ID: <20060214020446.GA4865@xenon.Stanford.EDU> As mentioned awhile back, myself and a partner are working on a formal security analysis of OTR. Before we try to break it, I just wanted to send you what we're working on in terms of what security properties OTR claims to see if we're in agreement. Attached is a PDF of our working definitions for the properties that should hold on OTR. Do you guys agree or disagree on any of the definitions? Is anything missing? Are any of the claims too strong or weak? Thanks. -- Andrew S. Morrison asm at cs.stanford.edu (650) 575 9261 -------------- next part -------------- A non-text attachment was scrubbed... Name: otr_properties.pdf Type: application/pdf Size: 49658 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ian at cypherpunks.ca Tue Feb 14 14:56:49 2006 From: ian at cypherpunks.ca (Ian Goldberg) Date: Tue, 14 Feb 2006 14:56:49 -0500 Subject: [OTR-dev] OTR Formal Analysis Security Properties In-Reply-To: <20060214020446.GA4865@xenon.Stanford.EDU> References: <20060214020446.GA4865@xenon.Stanford.EDU> Message-ID: <20060214195649.GZ31096@smtp.paip.net> On Mon, Feb 13, 2006 at 06:04:46PM -0800, Andrew S. Morrison wrote: > As mentioned awhile back, myself and a partner are working on a formal > security analysis of OTR. Before we try to break it, I just wanted to send > you what we're working on in terms of what security properties OTR claims > to see if we're in agreement. Attached is a PDF of our working definitions > for the properties that should hold on OTR. Do you guys agree or disagree > on any of the definitions? Is anything missing? Are any of the claims too > strong or weak? Thanks. I took a quick look. In the PFS definition, Mallory *is* allowed to be able to read _very recent_ messages sent between Alice and Bob (i.e. messages sent with keys Alice and/or Bob are still using). So just saying Mallory cannot read messages with timestamp t' < t isn't quite right, I think. And a tiny nit, but I think you mean "principal" where you write "principle". ;-) Otherwise, it looks pretty plausible. I look forward to seeing the results of your work! - Ian From twanfox at gmail.com Wed Feb 15 14:15:03 2006 From: twanfox at gmail.com (Twan Fox) Date: Wed, 15 Feb 2006 13:15:03 -0600 Subject: [OTR-dev] Building an OTR plugin for Trillian 3.1 Message-ID: <63dc64100602151115p34dbb6e6w5d4b14357eef68fa@mail.gmail.com> Greetings, New to this list but using Trillian for a while, I have been getting a little antsy about not being able to encrypt messages across multiple IM clients. Having originally intended to use another encryption protocol to do this (already supported on Gaim), I find myself redirected to use OTR for various reasons. At any rate, my whole goal is to craft up a plugin which impliments OTR encryption for Trillian (latest version being 3.1). I come across lacking a few things, though. Due to the basics of plugin development for Trillian having been designed in Visual Studio (it seems), that is likely the tool under which I am going to develop the plugin. However, obtaining or building a VS-usable library for libotr seems to be quite an excersize (for me, especially). I understand that, at least in the case of Libgcrypt, .dll files have been built, but I have yet to come across a dynamic (or static) library of libotr available for Windows development. To me, ideally, I would like to build libotr as a statically linked library within the plugin, to make it simple on placing the final plugin within Trillian, but I haven't a notion where to begin in porting the build environment over. Any assistance is gladly appreciated. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From ian at cypherpunks.ca Wed Feb 15 14:25:56 2006 From: ian at cypherpunks.ca (Ian Goldberg) Date: Wed, 15 Feb 2006 14:25:56 -0500 Subject: [OTR-dev] Building an OTR plugin for Trillian 3.1 In-Reply-To: <63dc64100602151115p34dbb6e6w5d4b14357eef68fa@mail.gmail.com> References: <63dc64100602151115p34dbb6e6w5d4b14357eef68fa@mail.gmail.com> Message-ID: <20060215192556.GL31096@smtp.paip.net> On Wed, Feb 15, 2006 at 01:15:03PM -0600, Twan Fox wrote: > Greetings, > > New to this list but using Trillian for a while, I have been getting a > little antsy about not being able to encrypt messages across multiple IM > clients. Having originally intended to use another encryption protocol to do > this (already supported on Gaim), I find myself redirected to use OTR for > various reasons. At any rate, my whole goal is to craft up a plugin which > impliments OTR encryption for Trillian (latest version being 3.1). I come > across lacking a few things, though. > > Due to the basics of plugin development for Trillian having been designed in > Visual Studio (it seems), that is likely the tool under which I am going to > develop the plugin. However, obtaining or building a VS-usable library for > libotr seems to be quite an excersize (for me, especially). I understand > that, at least in the case of Libgcrypt, .dll files have been built, but I > have yet to come across a dynamic (or static) library of libotr available > for Windows development. To me, ideally, I would like to build libotr as a > statically linked library within the plugin, to make it simple on > placing the final plugin within Trillian, but I haven't a notion where to > begin in porting the build environment over. > > Any assistance is gladly appreciated. Francesco "s0rr0w" Picasso reported he'd done this: http://lists.cypherpunks.ca/pipermail/otr-dev/2005-October/000428.html - Ian From twanfox at gmail.com Wed Feb 15 14:45:58 2006 From: twanfox at gmail.com (Twan Fox) Date: Wed, 15 Feb 2006 13:45:58 -0600 Subject: [OTR-dev] Building an OTR plugin for Trillian 3.1 In-Reply-To: <20060215192556.GL31096@smtp.paip.net> References: <63dc64100602151115p34dbb6e6w5d4b14357eef68fa@mail.gmail.com> <20060215192556.GL31096@smtp.paip.net> Message-ID: <63dc64100602151145g6941ab05he9f8572ecb56b15f@mail.gmail.com> I had attempted to use that visual studio environment, but when I tried, it was a little less than intuitive to set up, and the build attempt I made was all horktified (ie: it be broke). I've been using Visual Studio .NET 2003 and the environments given were at best Visual Studio 6. If there is more documentation on how to use that environment, I'm more than willing to use an already set up project to kick this thing off. I suppose I can tinker with it more. Also just contemplating building the environment from scratch in VS.NET 2k3 for sanity sake, if I can figure out what must be done for it. On 2/15/06, Ian Goldberg wrote: > > On Wed, Feb 15, 2006 at 01:15:03PM -0600, Twan Fox wrote: > > Greetings, > > > > New to this list but using Trillian for a while, I have been getting a > > little antsy about not being able to encrypt messages across multiple IM > > clients. Having originally intended to use another encryption protocol > to do > > this (already supported on Gaim), I find myself redirected to use OTR > for > > various reasons. At any rate, my whole goal is to craft up a plugin > which > > impliments OTR encryption for Trillian (latest version being 3.1). I > come > > across lacking a few things, though. > > > > Due to the basics of plugin development for Trillian having been > designed in > > Visual Studio (it seems), that is likely the tool under which I am going > to > > develop the plugin. However, obtaining or building a VS-usable library > for > > libotr seems to be quite an excersize (for me, especially). I understand > > that, at least in the case of Libgcrypt, .dll files have been built, but > I > > have yet to come across a dynamic (or static) library of libotr > available > > for Windows development. To me, ideally, I would like to build libotr as > a > > statically linked library within the plugin, to make it simple on > > placing the final plugin within Trillian, but I haven't a notion where > to > > begin in porting the build environment over. > > > > Any assistance is gladly appreciated. > > Francesco "s0rr0w" Picasso reported he'd done this: > > http://lists.cypherpunks.ca/pipermail/otr-dev/2005-October/000428.html > > - Ian > _______________________________________________ > OTR-dev mailing list > OTR-dev at lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From twanfox at gmail.com Wed Feb 15 15:00:44 2006 From: twanfox at gmail.com (Twan Fox) Date: Wed, 15 Feb 2006 14:00:44 -0600 Subject: [OTR-dev] Building an OTR plugin for Trillian 3.1 In-Reply-To: <63dc64100602151145g6941ab05he9f8572ecb56b15f@mail.gmail.com> References: <63dc64100602151115p34dbb6e6w5d4b14357eef68fa@mail.gmail.com> <20060215192556.GL31096@smtp.paip.net> <63dc64100602151145g6941ab05he9f8572ecb56b15f@mail.gmail.com> Message-ID: <63dc64100602151200q756deba7g6c88a9a5c161edff@mail.gmail.com> Ok, well, I don't know what I did differently yesterday to today, but it seems like I just figured out how to make a libotr 'head' build of a VS.NETcompatable static library. On 2/15/06, Twan Fox wrote: > > I had attempted to use that visual studio environment, but when I tried, > it was a little less than intuitive to set up, and the build attempt I made > was all horktified (ie: it be broke). I've been using Visual Studio .NET > 2003 and the environments given were at best Visual Studio 6. If there is > more documentation on how to use that environment, I'm more than willing to > use an already set up project to kick this thing off. I suppose I can tinker > with it more. Also just contemplating building the environment from scratch > in VS.NET 2k3 for sanity sake, if I can figure out what > must be done for it. > > On 2/15/06, Ian Goldberg wrote: > > > > On Wed, Feb 15, 2006 at 01:15:03PM -0600, Twan Fox wrote: > > > Greetings, > > > > > > New to this list but using Trillian for a while, I have been getting a > > > > > little antsy about not being able to encrypt messages across multiple > > IM > > > clients. Having originally intended to use another encryption protocol > > to do > > > this (already supported on Gaim), I find myself redirected to use OTR > > for > > > various reasons. At any rate, my whole goal is to craft up a plugin > > which > > > impliments OTR encryption for Trillian (latest version being 3.1). I > > come > > > across lacking a few things, though. > > > > > > Due to the basics of plugin development for Trillian having been > > designed in > > > Visual Studio (it seems), that is likely the tool under which I am > > going to > > > develop the plugin. However, obtaining or building a VS-usable library > > for > > > libotr seems to be quite an excersize (for me, especially). I > > understand > > > that, at least in the case of Libgcrypt, .dll files have been built, > > but I > > > have yet to come across a dynamic (or static) library of libotr > > available > > > for Windows development. To me, ideally, I would like to build libotr > > as a > > > statically linked library within the plugin, to make it simple on > > > placing the final plugin within Trillian, but I haven't a notion where > > to > > > begin in porting the build environment over. > > > > > > Any assistance is gladly appreciated. > > > > Francesco "s0rr0w" Picasso reported he'd done this: > > > > http://lists.cypherpunks.ca/pipermail/otr-dev/2005-October/000428.html > > > > - Ian > > _______________________________________________ > > OTR-dev mailing list > > OTR-dev at lists.cypherpunks.ca > > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mr.s0rr0w at gmail.com Thu Feb 16 07:58:10 2006 From: mr.s0rr0w at gmail.com (s0rr0w) Date: Thu, 16 Feb 2006 13:58:10 +0100 Subject: [OTR-dev] Building an OTR plugin for Trillian 3.1 In-Reply-To: <63dc64100602151200q756deba7g6c88a9a5c161edff@mail.gmail.com> References: <63dc64100602151115p34dbb6e6w5d4b14357eef68fa@mail.gmail.com> <20060215192556.GL31096@smtp.paip.net> <63dc64100602151145g6941ab05he9f8572ecb56b15f@mail.gmail.com> <63dc64100602151200q756deba7g6c88a9a5c161edff@mail.gmail.com> Message-ID: <43F476E2.9020002@gmail.com> Twan Fox ha scritto: > Ok, well, I don't know what I did differently yesterday to today, but it > seems like I just figured out how to make a libotr 'head' build of a > VS.NETcompatable static library. >>>> Any assistance is gladly appreciated. >>> Francesco "s0rr0w" Picasso reported he'd done this: >>> >>> http://lists.cypherpunks.ca/pipermail/otr-dev/2005-October/000428.html >>> >>> - Ian hi all, I have not updated the project on sourcesafe, but I will do Twan: if you need help feel free to write directly to me, if argument is off-topic From evan.s at dreskin.net Fri Feb 17 13:57:37 2006 From: evan.s at dreskin.net (Evan Schoenberg) Date: Fri, 17 Feb 2006 13:57:37 -0500 Subject: [OTR-dev] gaim-OTR, AIM DirectIM, and messaging signals Message-ID: <1521E76B-181A-47E3-91B0-D790B0F726C9@dreskin.net> (Please reply-to-all, as I'm sending this to both relevant lists) AIM DirectIM can't work within an OTR-encrypted chat; the same is true of any other gaim plugin-based encryption scheme. 1) User sends message in Gaim 2) Gaim gives plugins an opportunity to modify the message; an encryption plugin such as gaim-otr encrypts the message if appropriate, returning the encrypted message 3) Gaim sends the encrypted message to the prpl 4) In the case of oscar within a DirectIM session, the message is normally post-processed, looking for tags, which reference ids from the gaim img store in the form where gaim_imgstore_get (2) will return the GaimStoredImage* for the image. The image's data, size, etc. are inserted into the message..... but the message is encoded, so such a tag isn't found, and images can not be sent. A similar situation exists on the receiving side, where the prpl processes the incoming message, looking for tags to convert to the gaim img store and their corresponding IDs but sees only the gibberish of an encrypted message. As I mentioned, this is not specific to the gaim-otr implementation but rather a result of how the signals are set up. One solution I've come up with is giving the prpl a chance to modify the outgoing message before it is sent to plugins via a signal, and similarly call the prpl for final post-processing of incoming messages after the first signal is sent when receiving a message. Thoughts? Cheers, Evan www.adiumx.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From siege at preoccupied.net Fri Feb 17 14:16:56 2006 From: siege at preoccupied.net (Christopher (siege) O'Brien) Date: Fri, 17 Feb 2006 14:16:56 -0500 Subject: [OTR-dev] Re: [Gaim-devel] gaim-OTR, AIM DirectIM, and messaging signals In-Reply-To: <1521E76B-181A-47E3-91B0-D790B0F726C9@dreskin.net> References: <1521E76B-181A-47E3-91B0-D790B0F726C9@dreskin.net> Message-ID: <1140203817.29615.4.camel@stella> On Fri, 2006-02-17 at 13:57 -0500, Evan Schoenberg wrote: > AIM DirectIM can't work within an OTR-encrypted chat; the same is true > of any other gaim plugin-based encryption scheme. The Sametime plugin has this problem as well, as it uses the same process as outlined in the previous email to determine if an outgoing message needs any embedded imaged to be built into a multipart MIME document. - siege -- Christopher (siege) O'Brien http://preoccupied.net/~siege/ From mail at scottellis.com.au Sun Feb 19 22:12:25 2006 From: mail at scottellis.com.au (Scott Ellis) Date: Mon, 20 Feb 2006 14:12:25 +1100 Subject: [OTR-dev] acoountname as 'ourname' in 'incorrect no-plugin' message Message-ID: <96e269140602191912o4e636f89u@mail.gmail.com> ok, this is the 'misbehaviour'... on one end (receiver), i set the sender contact to 'never' as the OTR policy on the other end (sender), i select 'start OTR' with the receiver contact on the reciever end i get the message: ?OTR?v2? 'OTR' has requested an Off-the-Record private conversation. However, you do not have a plugin to support that. See "http://www.cypherpunks.ca/otr/" for more information. it's incorrect on two counts - first, i do have the plugin...and secondly, it was not OTR that requested the session (the accountname is OTR) have i done something wrong? or, can something be done about this? Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From evan.s at dreskin.net Mon Feb 20 08:37:16 2006 From: evan.s at dreskin.net (Evan Schoenberg) Date: Mon, 20 Feb 2006 08:37:16 -0500 Subject: [OTR-dev] Re: [Gaim-devel] gaim-OTR, AIM DirectIM, and messaging signals In-Reply-To: <20060220060222.M10471@kingant.net> References: <1521E76B-181A-47E3-91B0-D790B0F726C9@dreskin.net> <20060220060222.M10471@kingant.net> Message-ID: On Feb 20, 2006, at 1:04 AM, Mark Doliner wrote: > That would be kind of a pain, but if you really want to fix it I > guess that's > the only way to do it. Personally I'd rather see us implement > AIM's built-in > encryption capabilities. That wouldn't solve the problem, but it > would > hopefully make it less of an issue? Eh, from what I've heard, AIM's built-in encryption is nothing to write home about nor possibly even to write gaim-devl about. IANAC, though. Either way, even if we implement AIM's solution, that doesn't mean that (a) people won't still want to use the less- configuration, documented-protocol, etc. OTR solution, (b) other, similar solutions won't come up in the future, and (c) Sametime and any other prpl that needs pre/post prpl-level message processing will be fixed. It may be some time before I have a chance to fix it, so if someone else wants to work on it feel free -- but I'll look into a clean, minimally invasive solution in the not too distant future. -Evan -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From mark at kingant.net Mon Feb 20 01:04:04 2006 From: mark at kingant.net (Mark Doliner) Date: Mon, 20 Feb 2006 01:04:04 -0500 Subject: [OTR-dev] Re: [Gaim-devel] gaim-OTR, AIM DirectIM, and messaging signals In-Reply-To: <1521E76B-181A-47E3-91B0-D790B0F726C9@dreskin.net> References: <1521E76B-181A-47E3-91B0-D790B0F726C9@dreskin.net> Message-ID: <20060220060222.M10471@kingant.net> On Fri, 17 Feb 2006 13:57:37 -0500, Evan Schoenberg wrote > (Please reply-to-all, as I'm sending this to both relevant lists) > > AIM DirectIM can't work within an OTR-encrypted chat; the same is > true of any other gaim plugin-based encryption scheme. > > 1) User sends message in Gaim > 2) Gaim gives plugins an opportunity to modify the message; an > encryption plugin such as gaim-otr encrypts the message if > appropriate, returning the encrypted message > 3) Gaim sends the encrypted message to the prpl > 4) In the case of oscar within a DirectIM session, the message is > normally post-processed, looking for tags, which reference ids > from the gaim img store in the form where > gaim_imgstore_get > (2) will return the GaimStoredImage* for the image. The image's > data, size, etc. are inserted into the message..... but the message > is encoded, so such a tag isn't found, and images can not be sent. > > A similar situation exists on the receiving side, where the prpl > processes the incoming message, looking for tags to convert to > the gaim img store and their corresponding IDs but sees only the > gibberish of an encrypted message. > > As I mentioned, this is not specific to the gaim-otr implementation > but rather a result of how the signals are set up. One solution > I've come up with is giving the prpl a chance to modify the > outgoing message before it is sent to plugins via a signal, and > similarly call the prpl for final post-processing of incoming > messages after the first signal is sent when receiving a message. > > Thoughts? > > Cheers, > Evan > www.adiumx.com That would be kind of a pain, but if you really want to fix it I guess that's the only way to do it. Personally I'd rather see us implement AIM's built-in encryption capabilities. That wouldn't solve the problem, but it would hopefully make it less of an issue? -Mark From eblanton at cs.ohiou.edu Mon Feb 20 12:11:48 2006 From: eblanton at cs.ohiou.edu (Ethan Blanton) Date: Mon, 20 Feb 2006 12:11:48 -0500 Subject: [OTR-dev] Re: [Gaim-devel] gaim-OTR, AIM DirectIM, and messaging signals In-Reply-To: References: <1521E76B-181A-47E3-91B0-D790B0F726C9@dreskin.net> <20060220060222.M10471@kingant.net> Message-ID: <20060220171148.GA3902@localhost.localdomain> Evan Schoenberg spake unto us the following wisdom: > On Feb 20, 2006, at 1:04 AM, Mark Doliner wrote: > >That would be kind of a pain, but if you really want to fix it I > >guess that's the only way to do it. Personally I'd rather see us > >implement AIM's built-in encryption capabilities. That wouldn't solve > >the problem, but it would hopefully make it less of an issue? > > Eh, from what I've heard, AIM's built-in encryption is nothing to > write home about nor possibly even to write gaim-devl about. IANAC, > though. Either way, even if we implement AIM's solution, that > doesn't mean that (a) people won't still want to use the less- > configuration, documented-protocol, etc. OTR solution, (b) other, > similar solutions won't come up in the future, and (c) Sametime and > any other prpl that needs pre/post prpl-level message processing will > be fixed. It's interesting that you say it's nothing to write home about ... what have you heard? My understanding is that it uses AOL-signed SSL-style certificates for authentication, although I don't know what it does for encryption past that and it's certainly possible that they did something stupid in their algorithms. Assuming that they do *any* sort of identity checking at all before issuing the certificate, it's at least equivalent to almost everything else out there (and practically better, since most people don't verify their keys at *all*, but that's not a technical point), and even if they don't but they register certificates to screen names, it's worth *something*. Ethan -- The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From ian at cypherpunks.ca Mon Feb 20 13:55:00 2006 From: ian at cypherpunks.ca (Ian Goldberg) Date: Mon, 20 Feb 2006 13:55:00 -0500 Subject: [OTR-dev] acoountname as 'ourname' in 'incorrect no-plugin' message In-Reply-To: <96e269140602191912o4e636f89u@mail.gmail.com> References: <96e269140602191912o4e636f89u@mail.gmail.com> Message-ID: <20060220185500.GW31096@smtp.paip.net> On Mon, Feb 20, 2006 at 02:12:25PM +1100, Scott Ellis wrote: > ok, this is the 'misbehaviour'... > > on one end (receiver), i set the sender contact to 'never' as the OTR policy > on the other end (sender), i select 'start OTR' with the receiver contact > > on the reciever end i get the message: > > ?OTR?v2? > 'OTR' has requested an Off-the-Record private conversation. However, you do > not have a plugin to support that. > See "http://www.cypherpunks.ca/otr/" for more information. > > it's incorrect on two counts - first, i do have the plugin... Well, yes, but you've disabled it for that contact. Maybe "you do not have an active plugin..." would be better? > and secondly, it was not OTR that requested the session (the > accountname is OTR) I'm not sure I understand here. It looks like you're passing the string "OTR" as the first parameter to otrl_proto_default_query_msg() when the user selects "start OTR" instead of passing the account name. - Ian From evan.s at dreskin.net Mon Feb 20 15:16:20 2006 From: evan.s at dreskin.net (Evan Schoenberg) Date: Mon, 20 Feb 2006 15:16:20 -0500 Subject: [OTR-dev] acoountname as 'ourname' in 'incorrect no-plugin' message In-Reply-To: <20060220185500.GW31096@smtp.paip.net> References: <96e269140602191912o4e636f89u@mail.gmail.com> <20060220185500.GW31096@smtp.paip.net> Message-ID: <36D9E120-656C-48BD-B031-4E3375F5BACD@dreskin.net> On Feb 20, 2006, at 1:55 PM, Ian Goldberg wrote: > Well, yes, but you've disabled it for that contact. Maybe "you do not > have an active plugin..." would be better? Is the goal to completely avoid processing text when Never is the policy? If not, what about reinterpreting that message as "Joe has request an Off-the-Record private conversation, but you have disabled Off-the-Record messaging to Joe. To allow OTR, change your policy for Joe." ? -Evan -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From ian at cypherpunks.ca Mon Feb 20 15:30:16 2006 From: ian at cypherpunks.ca (Ian Goldberg) Date: Mon, 20 Feb 2006 15:30:16 -0500 Subject: [OTR-dev] acoountname as 'ourname' in 'incorrect no-plugin' message In-Reply-To: <36D9E120-656C-48BD-B031-4E3375F5BACD@dreskin.net> References: <96e269140602191912o4e636f89u@mail.gmail.com> <20060220185500.GW31096@smtp.paip.net> <36D9E120-656C-48BD-B031-4E3375F5BACD@dreskin.net> Message-ID: <20060220203016.GZ31096@smtp.paip.net> On Mon, Feb 20, 2006 at 03:16:20PM -0500, Evan Schoenberg wrote: > > On Feb 20, 2006, at 1:55 PM, Ian Goldberg wrote: > > >Well, yes, but you've disabled it for that contact. Maybe "you do not > >have an active plugin..." would be better? > > Is the goal to completely avoid processing text when Never is the > policy? It has been, up until this point. > If not, what about reinterpreting that message as "Joe has > request an Off-the-Record private conversation, but you have disabled > Off-the-Record messaging to Joe. To allow OTR, change your policy > for Joe." ? That's a plausible suggestion; I'd be willing to consider it. Thanks, - Ian From evan.s at dreskin.net Mon Feb 20 15:52:18 2006 From: evan.s at dreskin.net (Evan Schoenberg) Date: Mon, 20 Feb 2006 15:52:18 -0500 Subject: [OTR-dev] Re: [Gaim-devel] gaim-OTR, AIM DirectIM, and messaging signals In-Reply-To: <20060220171148.GA3902@localhost.localdomain> References: <1521E76B-181A-47E3-91B0-D790B0F726C9@dreskin.net> <20060220060222.M10471@kingant.net> <20060220171148.GA3902@localhost.localdomain> Message-ID: <6612487F-120F-4C3C-B73C-B6430D906A2D@dreskin.net> On Feb 20, 2006, at 12:11 PM, Ethan Blanton wrote: > Evan Schoenberg spake unto us the following wisdom: >> On Feb 20, 2006, at 1:04 AM, Mark Doliner wrote: >>> That would be kind of a pain, but if you really want to fix it I >>> guess that's the only way to do it. Personally I'd rather see us >>> implement AIM's built-in encryption capabilities. That wouldn't >>> solve >>> the problem, but it would hopefully make it less of an issue? >> >> Eh, from what I've heard, AIM's built-in encryption is nothing to >> write home about nor possibly even to write gaim-devl about. IANAC, >> though. > > It's interesting that you say it's nothing to write home about ... > what have you heard? My understanding is that it uses AOL-signed > SSL-style certificates for authentication, although I don't know what > it does for encryption past that and it's certainly possible that they > did something stupid in their algorithms. Assuming that they do *any* > sort of identity checking at all before issuing the certificate, it's > at least equivalent to almost everything else out there (and > practically better, since most people don't verify their keys at > *all*, but that's not a technical point), and even if they don't but > they register certificates to screen names, it's worth *something*. That hadn't been my understanding, so I did a bit of research. It turns out I was basically wrong about AOL's official encryption, and I apologize for spreading misinformation. :) It turns out what I was thinking of is Trillian's SecureIM which has become a common form of AIM encryption. SecureIM providese no authentication or signing whatsoever. As a side note, it uses Blowfish-based encryption. The AOL-official encryption is an entirely different story. joust.kano.net, where Keith Lea has a good description of the protocol and how it works, is down, and but google's cache of the appropriate page [1] isn't. Brief summary is that it's end-to-end SSL encryption, not only of messages but also of file transfers, direct IM connections, and Get File connections. It also allows for secure chat rooms via a very strange mechanism of the chat room creator sharing a secret key with invitees (anybody can join the room, but only those invited can read the plaintext... with the amusing side effect that you could have multiple encrypted chats simultaneously in the same room). Users of this mechanism need an SSL cert... savvy users can generate their own and self-sign them or pay to have them signed, and AOL offers verisign-signed certificates for a key. I have no idea what the registration / verification mechanism is for the latter process. A side note about the AOL encryption: As detailed at [2], there is an aimencrypt.com website which explains to clueless users how to obtain a free signed certificate. Fantastically, it's free because aimencrypt bought one and gives it to users to download so they can have a cool lock by their name... just wow. -Evan [1] http://64.233.179.104/search?q=cache:jYfa2ow86SUJ:joust.kano.net/ wiki/oscar/moin.cgi/AimSecureIm+AimSecureIM&hl=en&gl=us&ct=clnk&cd=1 [2] http://fae.cs.columbia.edu/aimencrypt.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From ian at cypherpunks.ca Mon Feb 20 16:47:21 2006 From: ian at cypherpunks.ca (Ian Goldberg) Date: Mon, 20 Feb 2006 16:47:21 -0500 Subject: [OTR-dev] Re: [Gaim-devel] gaim-OTR, AIM DirectIM, and messaging signals In-Reply-To: <6612487F-120F-4C3C-B73C-B6430D906A2D@dreskin.net> References: <1521E76B-181A-47E3-91B0-D790B0F726C9@dreskin.net> <20060220060222.M10471@kingant.net> <20060220171148.GA3902@localhost.localdomain> <6612487F-120F-4C3C-B73C-B6430D906A2D@dreskin.net> Message-ID: <20060220214721.GB31096@smtp.paip.net> On Mon, Feb 20, 2006 at 03:52:18PM -0500, Evan Schoenberg wrote: > That hadn't been my understanding, so I did a bit of research. It > turns out I was basically wrong about AOL's official encryption, and > I apologize for spreading misinformation. :) > > It turns out what I was thinking of is Trillian's SecureIM which has > become a common form of AIM encryption. SecureIM providese no > authentication or signing whatsoever. As a side note, it uses > Blowfish-based encryption. That's correct. SecureIM uses unauthenticated Diffie-Hellman for key agreement, followed by Blowfish for message encryption, and no message authentication or integrity checking at all. > joust.kano.net, where Keith Lea has a good description of the > protocol and how it works, is down, and but google's cache of the > appropriate page [1] isn't. Brief summary is that it's end-to-end > SSL encryption, not only of messages but also of file transfers, > direct IM connections, and Get File connections. Looking at that link, it seems to me that normal IM communication isn't just "tunnel over SSL"; it's sent by individually wrapping each message with an RSA encryption and an RSA signature. > Users of this mechanism need an > SSL cert... savvy users can generate their own and self-sign them or > pay to have them signed, and AOL offers verisign-signed certificates > for a key. I have no idea what the registration / verification > mechanism is for the latter process. So there's no binding whatsoever between the cert and the screen name? In what sense is it a cert, then? > A side note about the AOL encryption: As detailed at [2], there is an > aimencrypt.com website which explains to clueless users how to obtain > a free signed certificate. Fantastically, it's free because > aimencrypt bought one and gives it to users to download so they can > have a cool lock by their name... just wow. Wow indeed. So there's definitely *no* binding. I'm not saying that's necessarily bad; it just means you need to do the same type of out-of-band verification of the key that OTR requires. But from what I can tell of the UI, there's no indication that you need to do this in AIM-Encrypt. And the wiki page would seem to suggest that self-signed certs work just fine. So why would aimencrypt.com offer a constant cert to everyone when they could just offer a little widget to generate a fresh self-signed one? I wonder how quickly someone could throw together a patch to the OSCAR-parsing module of ethereal (or something like that) that automatically decrypts messages encrypted to this shared aimencrypt.com cert. :-) - Ian From kbeckman at students.mcg.edu Mon Feb 20 22:44:55 2006 From: kbeckman at students.mcg.edu (Keith Beckman) Date: Mon, 20 Feb 2006 22:44:55 -0500 Subject: [OTR-dev] Command-Line OTR Proxy? Message-ID: <38886570-A403-4342-A14F-40D823D8CF12@students.mcg.edu> I've just installed OTR Proxy on Mac OS X 10.4.3, running on a PowerBook G4 500MHz. I've noted two things that would make it a much nicer program to run, in my opinion. The first is that the "quit" option doesn't work correctly. Rather than killing the proxy, it sits indefinitely with the file menu darkened and the proxy still running. It always requires a kill to shut the program down. The second is that it would be really nice to have the proxy be executable as a command-line app. That way I could just launch it into the background from the terminal, maybe defining an alternate oscar server (since AOL has been known to change that), and perhaps an alternate .otrproxyrc file (which would be a nice, tidy way to house settings). It's just a thought, but I don't think it ought to be too difficult to implement. I'd give it a shot, but I've never actually worked with C before . . . Thanks! Keith From mail at scottellis.com.au Tue Feb 21 04:08:37 2006 From: mail at scottellis.com.au (Scott Ellis) Date: Tue, 21 Feb 2006 20:08:37 +1100 Subject: [OTR-dev] acoountname as 'ourname' in 'incorrect no-plugin' message In-Reply-To: <20060220185500.GW31096@smtp.paip.net> References: <96e269140602191912o4e636f89u@mail.gmail.com> <20060220185500.GW31096@smtp.paip.net> Message-ID: <96e269140602210108o4fbcbbdcj@mail.gmail.com> > >> ok, this is the 'misbehaviour'... > >> > >> on one end (receiver), i set the sender contact to 'never' as the OTR > policy > >> on the other end (sender), i select 'start OTR' with the receiver > contact > >> > >> on the reciever end i get the message: > >> > >> ?OTR?v2? > >> 'OTR' has requested an Off-the-Record private conversation. However, > you do > >> not have a plugin to support that. > >> See "http://www.cypherpunks.ca/otr/" for more information. > >> > >> it's incorrect on two counts - first, i do have the plugin... > > > >Well, yes, but you've disabled it for that contact. Maybe "you do not > >have an active plugin..." would be better? Yes, something like that - although detecting that it's just the policy, and saying something like 'plugin is inactive for this contact' would be ideal. > > >> and secondly, it was not OTR that requested the session (the > >> accountname is OTR) > > > >I'm not sure I understand here. It looks like you're passing the string > >"OTR" as the first parameter to otrl_proto_default_query_msg() when the > >user selects "start OTR" instead of passing the account name. Yes that's what i pass in. In miranda there aren't different accounts - only different protocols. It is possible to have e.g. two MSN 'accounts' but you do that using a 'hack' - i.e. you copy the msn.dll plugin to msn2.dll or the like, and miranda treats it as a seperate protocol. So, in the plugin there is only one account - i called it OTR, since i didn't think it'd make a difference. What I meant to point out is, since the username is passed into that function also, shouldn't the username be used in this message? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at scottellis.com.au Tue Feb 21 09:27:59 2006 From: mail at scottellis.com.au (Scott Ellis) Date: Wed, 22 Feb 2006 01:27:59 +1100 Subject: [OTR-dev] 'manual' + whitespace start ake? Message-ID: <96e269140602210627j6f166685h@mail.gmail.com> i'm wondering, what would be the effect of adding the WHITESPACE_START_AKE flag into the MANUAL mode? i mean - in my testing it seems that opportunistic mode only starts OTR when both sides have it set - if one side is set to manual, then automatic initialisation of OTR does not occur. if both sides are in manual, user 1 can 'force' user 2 to start OTR...so, if a user chooses 'opportunistic', wouldn't it make sense to force users they talk to who are in manual mode to start OTR also? would adding that flag have that effect? Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From evan.s at dreskin.net Tue Feb 21 10:23:08 2006 From: evan.s at dreskin.net (Evan Schoenberg) Date: Tue, 21 Feb 2006 10:23:08 -0500 Subject: [OTR-dev] 'manual' + whitespace start ake? In-Reply-To: <96e269140602210627j6f166685h@mail.gmail.com> References: <96e269140602210627j6f166685h@mail.gmail.com> Message-ID: <08B263D2-8CE9-4A68-9FAE-56D2F4EE74EA@dreskin.net> Scott, You've come to the exact same conclusion I did with the same rationale. Adium's "manual" mode is actually defined as: /* OTRL_POLICY_MANUAL doesn't let us respond to other users' automatic attempts at encryption. * If either user has OTR set to Automatic, an OTR session should be begun; without this modified * mask, both users would have to be on automatic for OTR to begin automatically, even though one user * _manually_ attempting OTR will _automatically_ bring the other into OTR even if the setting is Manual. */ #define OTRL_POLICY_MANUAL_AND_REPOND_TO_WHITESPACE ( OTRL_POLICY_MANUAL | \ OTRL_POLICY_WHITESPACE_START_AKE | \ OTRL_POLICY_ERROR_START_AKE ) -Evan www.adiumx.com On Feb 21, 2006, at 9:27 AM, Scott Ellis wrote: > i'm wondering, what would be the effect of adding the > WHITESPACE_START_AKE flag into the MANUAL mode? > > i mean - in my testing it seems that opportunistic mode only starts > OTR when both sides have it set - if one side is set to manual, > then automatic initialisation of OTR does not occur. > > if both sides are in manual, user 1 can 'force' user 2 to start > OTR...so, if a user chooses 'opportunistic', wouldn't it make sense > to force users they talk to who are in manual mode to start OTR > also? would adding that flag have that effect? > > Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From mail at scottellis.com.au Tue Feb 21 19:03:00 2006 From: mail at scottellis.com.au (Scott Ellis) Date: Wed, 22 Feb 2006 11:03:00 +1100 Subject: [OTR-dev] 'manual' + whitespace start ake? In-Reply-To: <08B263D2-8CE9-4A68-9FAE-56D2F4EE74EA@dreskin.net> References: <96e269140602210627j6f166685h@mail.gmail.com> <08B263D2-8CE9-4A68-9FAE-56D2F4EE74EA@dreskin.net> Message-ID: <96e269140602211603l5d1afa19q@mail.gmail.com> Thanks Evan...but I tried it, and get a 'duplicate case' error in one of my switch statements... It turns out to be because 'send whitespace tag' and 'whitespace start ake' are both defined to be 0x08 - so they're actually both the same thing. This means, if I define manual the way you suggest, it is exactly the same as opportunistic - which is not what I want. So I guess the behaviour I'm after is not possible with the current source. On 22/02/06, Evan Schoenberg wrote: > > Scott, > > You've come to the exact same conclusion I did with the same rationale. > Adium's "manual" mode is actually defined as: > /* OTRL_POLICY_MANUAL doesn't let us respond to other users' automatic > attempts at encryption. > * If either user has OTR set to Automatic, an OTR session should be > begun; without this modified > * mask, both users would have to be on automatic for OTR to begin > automatically, even though one user > * _manually_ attempting OTR will _automatically_ bring the other into OTR > even if the setting is Manual. > */ > #define OTRL_POLICY_MANUAL_AND_REPOND_TO_WHITESPACE ( OTRL_POLICY_MANUAL | > \ > OTRL_POLICY_WHITESPACE_START_AKE | \ > OTRL_POLICY_ERROR_START_AKE ) > > > -Evan > www.adiumx.com > > On Feb 21, 2006, at 9:27 AM, Scott Ellis wrote: > > i'm wondering, what would be the effect of adding the > WHITESPACE_START_AKE flag into the MANUAL mode? > > i mean - in my testing it seems that opportunistic mode only starts OTR > when both sides have it set - if one side is set to manual, then automatic > initialisation of OTR does not occur. > > if both sides are in manual, user 1 can 'force' user 2 to start OTR...so, > if a user chooses 'opportunistic', wouldn't it make sense to force users > they talk to who are in manual mode to start OTR also? would adding that > flag have that effect? > > Scott > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at scottellis.com.au Tue Feb 21 19:59:25 2006 From: mail at scottellis.com.au (Scott Ellis) Date: Wed, 22 Feb 2006 11:59:25 +1100 Subject: [OTR-dev] 'manual' + whitespace start ake? In-Reply-To: <96e269140602211603l5d1afa19q@mail.gmail.com> References: <96e269140602210627j6f166685h@mail.gmail.com> <08B263D2-8CE9-4A68-9FAE-56D2F4EE74EA@dreskin.net> <96e269140602211603l5d1afa19q@mail.gmail.com> Message-ID: <96e269140602211659q7004b324m@mail.gmail.com> seems to work find with the flags in the source fixed On 22/02/06, Scott Ellis wrote: > > Thanks Evan...but I tried it, and get a 'duplicate case' error in one of > my switch statements... > > It turns out to be because 'send whitespace tag' and 'whitespace start > ake' are both defined to be 0x08 - so they're actually both the same thing. > This means, if I define manual the way you suggest, it is exactly the same > as opportunistic - which is not what I want. > > So I guess the behaviour I'm after is not possible with the current > source. > > > On 22/02/06, Evan Schoenberg wrote: > > > > Scott, > > > > You've come to the exact same conclusion I did with the same rationale. > > Adium's "manual" mode is actually defined as: > > /* OTRL_POLICY_MANUAL doesn't let us respond to other users' automatic > > attempts at encryption. > > * If either user has OTR set to Automatic, an OTR session should be > > begun; without this modified > > * mask, both users would have to be on automatic for OTR to begin > > automatically, even though one user > > * _manually_ attempting OTR will _automatically_ bring the other into > > OTR even if the setting is Manual. > > */ > > #define OTRL_POLICY_MANUAL_AND_REPOND_TO_WHITESPACE ( OTRL_POLICY_MANUAL > > | \ > > OTRL_POLICY_WHITESPACE_START_AKE | \ > > OTRL_POLICY_ERROR_START_AKE ) > > > > > > -Evan > > www.adiumx.com > > > > On Feb 21, 2006, at 9:27 AM, Scott Ellis wrote: > > > > i'm wondering, what would be the effect of adding the > > WHITESPACE_START_AKE flag into the MANUAL mode? > > > > i mean - in my testing it seems that opportunistic mode only starts OTR > > when both sides have it set - if one side is set to manual, then automatic > > initialisation of OTR does not occur. > > > > if both sides are in manual, user 1 can 'force' user 2 to start > > OTR...so, if a user chooses 'opportunistic', wouldn't it make sense to force > > users they talk to who are in manual mode to start OTR also? would adding > > that flag have that effect? > > > > Scott > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From evan.s at dreskin.net Tue Feb 21 22:52:50 2006 From: evan.s at dreskin.net (Evan Schoenberg) Date: Tue, 21 Feb 2006 22:52:50 -0500 Subject: [OTR-dev] 'manual' + whitespace start ake? In-Reply-To: <96e269140602211659q7004b324m@mail.gmail.com> References: <96e269140602210627j6f166685h@mail.gmail.com> <08B263D2-8CE9-4A68-9FAE-56D2F4EE74EA@dreskin.net> <96e269140602211603l5d1afa19q@mail.gmail.com> <96e269140602211659q7004b324m@mail.gmail.com> Message-ID: The flags problem _should_ be fixed in HEAD -- I emailed with Ian about it previously. -Evan On Feb 21, 2006, at 7:59 PM, Scott Ellis wrote: > seems to work find with the flags in the source fixed > > On 22/02/06, Scott Ellis wrote: > Thanks Evan...but I tried it, and get a 'duplicate case' error in > one of my switch statements... > > It turns out to be because 'send whitespace tag' and 'whitespace > start ake' are both defined to be 0x08 - so they're actually both > the same thing. This means, if I define manual the way you suggest, > it is exactly the same as opportunistic - which is not what I want. > > So I guess the behaviour I'm after is not possible with the current > source. > > > On 22/02/06, Evan Schoenberg wrote: > Scott, > > > You've come to the exact same conclusion I did with the same > rationale. Adium's "manual" mode is actually defined as: > /* OTRL_POLICY_MANUAL doesn't let us respond to other users' > automatic attempts at encryption. > * If either user has OTR set to Automatic, an OTR session should > be begun; without this modified > * mask, both users would have to be on automatic for OTR to begin > automatically, even though one user > * _manually_ attempting OTR will _automatically_ bring the other > into OTR even if the setting is Manual. > */ > #define OTRL_POLICY_MANUAL_AND_REPOND_TO_WHITESPACE > ( OTRL_POLICY_MANUAL | \ > OTRL_POLICY_WHITESPACE_START_AKE | \ > OTRL_POLICY_ERROR_START_AKE ) > > > -Evan > www.adiumx.com > > On Feb 21, 2006, at 9:27 AM, Scott Ellis wrote: > >> i'm wondering, what would be the effect of adding the >> WHITESPACE_START_AKE flag into the MANUAL mode? >> >> i mean - in my testing it seems that opportunistic mode only >> starts OTR when both sides have it set - if one side is set to >> manual, then automatic initialisation of OTR does not occur. >> >> if both sides are in manual, user 1 can 'force' user 2 to start >> OTR...so, if a user chooses 'opportunistic', wouldn't it make >> sense to force users they talk to who are in manual mode to start >> OTR also? would adding that flag have that effect? >> >> Scott > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From ian at cypherpunks.ca Wed Feb 22 09:50:15 2006 From: ian at cypherpunks.ca (Ian Goldberg) Date: Wed, 22 Feb 2006 09:50:15 -0500 Subject: [OTR-dev] acoountname as 'ourname' in 'incorrect no-plugin' message In-Reply-To: <96e269140602210108o4fbcbbdcj@mail.gmail.com> References: <96e269140602191912o4e636f89u@mail.gmail.com> <20060220185500.GW31096@smtp.paip.net> <96e269140602210108o4fbcbbdcj@mail.gmail.com> Message-ID: <20060222145015.GI31096@smtp.paip.net> On Tue, Feb 21, 2006 at 08:08:37PM +1100, Scott Ellis wrote: > > >I'm not sure I understand here. It looks like you're passing the string > > >"OTR" as the first parameter to otrl_proto_default_query_msg() when the > > >user selects "start OTR" instead of passing the account name. > > > Yes that's what i pass in. In miranda there aren't different accounts - only > different protocols. It is possible to have e.g. two MSN 'accounts' but you > do that using a 'hack' - i.e. you copy the msn.dll plugin to msn2.dll or the > like, and miranda treats it as a seperate protocol. Wow. That *is* a hack. Surely there's a way to extract your account name, though? > So, in the plugin there > is only one account - i called it OTR, since i didn't think it'd make a > difference. What I meant to point out is, since the username is passed into > that function also, shouldn't the username be used in this message? The remote username? That's not passed in: /* Return a pointer to a newly-allocated OTR query message, customized * with our name. The caller should free() the result when he's done * with it. */ char *otrl_proto_default_query_msg(const char *ourname, OtrlPolicy policy); - Ian From ian at cypherpunks.ca Wed Feb 22 09:55:08 2006 From: ian at cypherpunks.ca (Ian Goldberg) Date: Wed, 22 Feb 2006 09:55:08 -0500 Subject: [OTR-dev] 'manual' + whitespace start ake? In-Reply-To: References: <96e269140602210627j6f166685h@mail.gmail.com> <08B263D2-8CE9-4A68-9FAE-56D2F4EE74EA@dreskin.net> <96e269140602211603l5d1afa19q@mail.gmail.com> <96e269140602211659q7004b324m@mail.gmail.com> Message-ID: <20060222145508.GJ31096@smtp.paip.net> On Tue, Feb 21, 2006 at 10:52:50PM -0500, Evan Schoenberg wrote: > The flags problem _should_ be fixed in HEAD -- I emailed with Ian > about it previously. It is, in fact. The fix was checked in in November. - Ian From eblanton at cs.ohiou.edu Mon Feb 20 22:35:29 2006 From: eblanton at cs.ohiou.edu (Ethan Blanton) Date: Mon, 20 Feb 2006 22:35:29 -0500 Subject: [OTR-dev] Re: [Gaim-devel] gaim-OTR, AIM DirectIM, and messaging signals In-Reply-To: <20060220214721.GB31096@smtp.paip.net> References: <1521E76B-181A-47E3-91B0-D790B0F726C9@dreskin.net> <20060220060222.M10471@kingant.net> <20060220171148.GA3902@localhost.localdomain> <6612487F-120F-4C3C-B73C-B6430D906A2D@dreskin.net> <20060220214721.GB31096@smtp.paip.net> Message-ID: <20060221033528.GB3902@localhost.localdomain> Ian Goldberg spake unto us the following wisdom: > > Users of this mechanism need an > > SSL cert... savvy users can generate their own and self-sign them or > > pay to have them signed, and AOL offers verisign-signed certificates > > for a key. I have no idea what the registration / verification > > mechanism is for the latter process. > > So there's no binding whatsoever between the cert and the screen name? > In what sense is it a cert, then? Ideally the provided-by-AOL certifications would certify something about the identity of the owner; given their staunch position on not identifying the owners of screen names, this may not be the case. > And the wiki page would seem to suggest that self-signed certs work just > fine. So why would aimencrypt.com offer a constant cert to everyone > when they could just offer a little widget to generate a fresh > self-signed one? Not that this would provide a whole lot more (effective) security ... because they could just keep and distribute copies of the private keys. ;-) Ethan -- The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From ian at cypherpunks.ca Wed Feb 22 12:38:48 2006 From: ian at cypherpunks.ca (Ian Goldberg) Date: Wed, 22 Feb 2006 12:38:48 -0500 Subject: [OTR-dev] Re: [Gaim-devel] gaim-OTR, AIM DirectIM, and messaging signals In-Reply-To: <20060221033528.GB3902@localhost.localdomain> References: <1521E76B-181A-47E3-91B0-D790B0F726C9@dreskin.net> <20060220060222.M10471@kingant.net> <20060220171148.GA3902@localhost.localdomain> <6612487F-120F-4C3C-B73C-B6430D906A2D@dreskin.net> <20060220214721.GB31096@smtp.paip.net> <20060221033528.GB3902@localhost.localdomain> Message-ID: <20060222173848.GO31096@smtp.paip.net> On Mon, Feb 20, 2006 at 10:35:29PM -0500, Ethan Blanton wrote: > > And the wiki page would seem to suggest that self-signed certs work just > > fine. So why would aimencrypt.com offer a constant cert to everyone > > when they could just offer a little widget to generate a fresh > > self-signed one? > > Not that this would provide a whole lot more (effective) security ... > because they could just keep and distribute copies of the private > keys. ;-) I would *hope* they would do something more secure, involving client-side generation, but considering what they do now... :-p - Ian From ian at cypherpunks.ca Wed Feb 22 12:41:02 2006 From: ian at cypherpunks.ca (Ian Goldberg) Date: Wed, 22 Feb 2006 12:41:02 -0500 Subject: [OTR-dev] Command-Line OTR Proxy? In-Reply-To: <38886570-A403-4342-A14F-40D823D8CF12@students.mcg.edu> References: <38886570-A403-4342-A14F-40D823D8CF12@students.mcg.edu> Message-ID: <20060222174102.GP31096@smtp.paip.net> On Mon, Feb 20, 2006 at 10:44:55PM -0500, Keith Beckman wrote: > I've just installed OTR Proxy on Mac OS X 10.4.3, running on a > PowerBook G4 500MHz. I've noted two things that would make it a much > nicer program to run, in my opinion. The first is that the "quit" > option doesn't work correctly. Rather than killing the proxy, it sits > indefinitely with the file menu darkened and the proxy still running. > It always requires a kill to shut the program down. Huh. Is this a known problem? Do other OSX people see this? > The second is that it would be really nice to have the proxy be > executable as a command-line app. That way I could just launch it > into the background from the terminal, maybe defining an alternate > oscar server (since AOL has been known to change that), and perhaps > an alternate .otrproxyrc file (which would be a nice, tidy way to > house settings). It's just a thought, but I don't think it ought to > be too difficult to implement. I'd give it a shot, but I've never > actually worked with C before . . . The proxy was written with seperate backend and UI components, for exactly this reason. It just needs someone with the time/ability to plug in a text-based (ncurses?) UI. - Ian From me at nikita.ca Wed Feb 22 15:01:06 2006 From: me at nikita.ca (Nikita Borisov) Date: Wed, 22 Feb 2006 14:01:06 -0600 Subject: [OTR-dev] Command-Line OTR Proxy? In-Reply-To: <20060222174102.GP31096@smtp.paip.net> References: <38886570-A403-4342-A14F-40D823D8CF12@students.mcg.edu> <20060222174102.GP31096@smtp.paip.net> Message-ID: <16f0378d0602221201h5d2f629dl3af058bd1e34b8a@mail.gmail.com> On 2/22/06, Ian Goldberg wrote: > On Mon, Feb 20, 2006 at 10:44:55PM -0500, Keith Beckman wrote: > > I've just installed OTR Proxy on Mac OS X 10.4.3, running on a > > PowerBook G4 500MHz. I've noted two things that would make it a much > > nicer program to run, in my opinion. The first is that the "quit" > > option doesn't work correctly. Rather than killing the proxy, it sits > > indefinitely with the file menu darkened and the proxy still running. > > It always requires a kill to shut the program down. > > Huh. Is this a known problem? Do other OSX people see this? This is a known problem. There are actually two quit menus in OTR Proxy: the one in the application menu ("OTR Proxy"), which will actually let you quit the proxy, and the one in the "File" menu, which will have the behaviour your describe. It has to do with some particulars of wxMac and how it tries to hack the wxWidgets way of creating menus into the Apple interface. This is something that I'd like to fix for the 1.0 version of OTR Proxy, but I don't know when I'll next have some time to look at it. If another OS X developer wants to take a stab at it, that would be great. - Nikita From mail at scottellis.com.au Wed Feb 22 19:16:02 2006 From: mail at scottellis.com.au (Scott Ellis) Date: Thu, 23 Feb 2006 11:16:02 +1100 Subject: [OTR-dev] acoountname as 'ourname' in 'incorrect no-plugin' message In-Reply-To: <20060222145015.GI31096@smtp.paip.net> References: <96e269140602191912o4e636f89u@mail.gmail.com> <20060220185500.GW31096@smtp.paip.net> <96e269140602210108o4fbcbbdcj@mail.gmail.com> <20060222145015.GI31096@smtp.paip.net> Message-ID: <96e269140602221616g2d076287h@mail.gmail.com> On 23/02/06, Ian Goldberg wrote: > > On Tue, Feb 21, 2006 at 08:08:37PM +1100, Scott Ellis wrote: > > > >I'm not sure I understand here. It looks like you're passing the > string > > > >"OTR" as the first parameter to otrl_proto_default_query_msg() when > the > > > >user selects "start OTR" instead of passing the account name. > > > > > > Yes that's what i pass in. In miranda there aren't different accounts - > only > > different protocols. It is possible to have e.g. two MSN 'accounts' but > you > > do that using a 'hack' - i.e. you copy the msn.dll plugin to msn2.dll or > the > > like, and miranda treats it as a seperate protocol. > > Wow. That *is* a hack. Surely there's a way to extract your account > name, though? There really isn't the concept of an account name in miranda...I can get the protocol name, or the protocol unique identifier (e.g. UIN) which may not be human readable...or, which is about the closest thing, the name of the user's database file - but that is often 'default' or something like that. I guess what I'm suggesting is that the library do some processing of the query message even when the policy is 'never'. > So, in the plugin there > > is only one account - i called it OTR, since i didn't think it'd make a > > difference. What I meant to point out is, since the username is passed > into > > that function also, shouldn't the username be used in this message? > > The remote username? That's not passed in: > > /* Return a pointer to a newly-allocated OTR query message, customized > * with our name. The caller should free() the result when he's done > * with it. */ > char *otrl_proto_default_query_msg(const char *ourname, OtrlPolicy > policy); Sorry, I mean't the username is passed into the 'receieve' function, on the receiver side - i misunderstood your last post regarding that. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at scottellis.com.au Wed Feb 22 19:17:05 2006 From: mail at scottellis.com.au (Scott Ellis) Date: Thu, 23 Feb 2006 11:17:05 +1100 Subject: [OTR-dev] 'manual' + whitespace start ake? In-Reply-To: <20060222145508.GJ31096@smtp.paip.net> References: <96e269140602210627j6f166685h@mail.gmail.com> <08B263D2-8CE9-4A68-9FAE-56D2F4EE74EA@dreskin.net> <96e269140602211603l5d1afa19q@mail.gmail.com> <96e269140602211659q7004b324m@mail.gmail.com> <20060222145508.GJ31096@smtp.paip.net> Message-ID: <96e269140602221617y1b1d1bf0w@mail.gmail.com> guess i ought to get the cvs version of the source, huh? :) i've been working from the archive on the website. sorry - i know better. On 23/02/06, Ian Goldberg wrote: > > On Tue, Feb 21, 2006 at 10:52:50PM -0500, Evan Schoenberg wrote: > > The flags problem _should_ be fixed in HEAD -- I emailed with Ian > > about it previously. > > It is, in fact. The fix was checked in in November. > > - Ian > _______________________________________________ > OTR-dev mailing list > OTR-dev at lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ian at cypherpunks.ca Wed Feb 22 19:34:51 2006 From: ian at cypherpunks.ca (Ian Goldberg) Date: Wed, 22 Feb 2006 19:34:51 -0500 Subject: [OTR-dev] acoountname as 'ourname' in 'incorrect no-plugin' message In-Reply-To: <96e269140602221616g2d076287h@mail.gmail.com> References: <96e269140602191912o4e636f89u@mail.gmail.com> <20060220185500.GW31096@smtp.paip.net> <96e269140602210108o4fbcbbdcj@mail.gmail.com> <20060222145015.GI31096@smtp.paip.net> <96e269140602221616g2d076287h@mail.gmail.com> Message-ID: <20060223003451.GF31096@smtp.paip.net> On Thu, Feb 23, 2006 at 11:16:02AM +1100, Scott Ellis wrote: > > Wow. That *is* a hack. Surely there's a way to extract your account > > name, though? > > There really isn't the concept of an account name in miranda...I can get the > protocol name, or the protocol unique identifier (e.g. UIN) which may not be > human readable...or, which is about the closest thing, the name of the > user's database file - but that is often 'default' or something like that. In what protocols is the "unique identifier" not human-readable? Is this not the string that someone else would type in to their IM client in order to send you a message? If not, I'd think there's got to be a way to determine what that string is. > I guess what I'm suggesting is that the library do some processing of the > query message even when the policy is 'never'. > > Sorry, I mean't the username is passed into the 'receieve' function, on the > receiver side - i misunderstood your last post regarding that. Ah, but that message (generated by the sender) needs to be readable and make sense to someone that really *doesn't* have an OTR plugin. So you can't rely on the receiver to fill in the sender's name properly. - Ian From mail at scottellis.com.au Wed Feb 22 20:34:46 2006 From: mail at scottellis.com.au (Scott Ellis) Date: Thu, 23 Feb 2006 12:34:46 +1100 Subject: [OTR-dev] acoountname as 'ourname' in 'incorrect no-plugin' message In-Reply-To: <20060223003451.GF31096@smtp.paip.net> References: <96e269140602191912o4e636f89u@mail.gmail.com> <20060220185500.GW31096@smtp.paip.net> <96e269140602210108o4fbcbbdcj@mail.gmail.com> <20060222145015.GI31096@smtp.paip.net> <96e269140602221616g2d076287h@mail.gmail.com> <20060223003451.GF31096@smtp.paip.net> Message-ID: <96e269140602221734j2a51dda7g@mail.gmail.com> On 23/02/06, Ian Goldberg wrote: > > On Thu, Feb 23, 2006 at 11:16:02AM +1100, Scott Ellis wrote: > > > Wow. That *is* a hack. Surely there's a way to extract your account > > > name, though? > > > > There really isn't the concept of an account name in miranda...I can get > the > > protocol name, or the protocol unique identifier (e.g. UIN) which may > not be > > human readable...or, which is about the closest thing, the name of the > > user's database file - but that is often 'default' or something like > that. > > In what protocols is the "unique identifier" not human-readable? Is > this not the string that someone else would type in to their IM client > in order to send you a message? If not, I'd think there's got to be a > way to determine what that string is. e.g ICQ - the UIN is just a number - readable but not meaningful to me. The nickname they're given on the receiving end (if any) is not necessarily known to the sender > I guess what I'm suggesting is that the library do some processing of the > > query message even when the policy is 'never'. > > > > Sorry, I mean't the username is passed into the 'receieve' function, on > the > > receiver side - i misunderstood your last post regarding that. > > Ah, but that message (generated by the sender) needs to be readable and > make sense to someone that really *doesn't* have an OTR plugin. So you > can't rely on the receiver to fill in the sender's name properly. yes I realise that - but it's prefixed with the ?OTR? thing - so if there does happen to be an otr plugin on the receiving end, and if the message had some sort of recognisable standard content (e.g. i've modified the lib to remove html tags, so straight strcmp wouldn't work) then the receiver could do something more useful with it - and also fill in the nickname of the sender -------------- next part -------------- An HTML attachment was scrubbed... URL: From evan.s at dreskin.net Thu Feb 23 09:22:19 2006 From: evan.s at dreskin.net (Evan Schoenberg) Date: Thu, 23 Feb 2006 09:22:19 -0500 Subject: [OTR-dev] acoountname as 'ourname' in 'incorrect no-plugin' message In-Reply-To: <96e269140602221734j2a51dda7g@mail.gmail.com> References: <96e269140602191912o4e636f89u@mail.gmail.com> <20060220185500.GW31096@smtp.paip.net> <96e269140602210108o4fbcbbdcj@mail.gmail.com> <20060222145015.GI31096@smtp.paip.net> <96e269140602221616g2d076287h@mail.gmail.com> <20060223003451.GF31096@smtp.paip.net> <96e269140602221734j2a51dda7g@mail.gmail.com> Message-ID: <14A38819-8376-48F1-88B2-D4C9200BA09D@dreskin.net> On Feb 22, 2006, at 8:34 PM, Scott Ellis wrote: > e.g ICQ - the UIN is just a number - readable but not meaningful to > me. The nickname they're given on the receiving end (if any) is not > necessarily known to the sender Readable and completely meaningful. It's the only identifying characteristic for an ICQ contact. Among other things, you can look up the person's name in the web directory, presumably you can do a Get Info request in Miranda to learn more about the contact, etc. -Evan -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From ian at cypherpunks.ca Thu Feb 23 09:49:26 2006 From: ian at cypherpunks.ca (Ian Goldberg) Date: Thu, 23 Feb 2006 09:49:26 -0500 Subject: [OTR-dev] acoountname as 'ourname' in 'incorrect no-plugin' message In-Reply-To: <96e269140602221734j2a51dda7g@mail.gmail.com> References: <96e269140602191912o4e636f89u@mail.gmail.com> <20060220185500.GW31096@smtp.paip.net> <96e269140602210108o4fbcbbdcj@mail.gmail.com> <20060222145015.GI31096@smtp.paip.net> <96e269140602221616g2d076287h@mail.gmail.com> <20060223003451.GF31096@smtp.paip.net> <96e269140602221734j2a51dda7g@mail.gmail.com> Message-ID: <20060223144926.GL31096@smtp.paip.net> On Thu, Feb 23, 2006 at 12:34:46PM +1100, Scott Ellis wrote: > > In what protocols is the "unique identifier" not human-readable? Is > > this not the string that someone else would type in to their IM client > > in order to send you a message? If not, I'd think there's got to be a > > way to determine what that string is. > > e.g ICQ - the UIN is just a number - readable but not meaningful to me. The > nickname they're given on the receiving end (if any) is not necessarily > known to the sender That's certainly true. But the account name is certainly better for a non-OTR person to see than something else. > > Ah, but that message (generated by the sender) needs to be readable and > > make sense to someone that really *doesn't* have an OTR plugin. So you > > can't rely on the receiver to fill in the sender's name properly. > > yes I realise that - but it's prefixed with the ?OTR? thing - so if there > does happen to be an otr plugin on the receiving end, and if the message had > some sort of recognisable standard content (e.g. i've modified the lib to > remove html tags, so straight strcmp wouldn't work) then the receiver could > do something more useful with it - and also fill in the nickname of the > sender You don't need standard content: the "?OTR?" is enough to indicate what's going on, *if* the user has an active OTR plugin that just happens to be set to "Never" for this contact. How common is that, though? In what situations do I want OTR *not* to start, *even if* the other guy pushes the "Start OTR" button? Does this come up a lot for other people? Thanks, - Ian From deryni at eden.rutgers.edu Thu Feb 23 22:33:20 2006 From: deryni at eden.rutgers.edu (Etan Reisner) Date: Thu, 23 Feb 2006 22:33:20 -0500 (EST) Subject: [OTR-dev] Re: [Gaim-devel] gaim-OTR, AIM DirectIM, and messaging signals In-Reply-To: <1521E76B-181A-47E3-91B0-D790B0F726C9@dreskin.net> References: <1521E76B-181A-47E3-91B0-D790B0F726C9@dreskin.net> Message-ID: On Fri, 17 Feb 2006, Evan Schoenberg wrote: > (Please reply-to-all, as I'm sending this to both relevant lists) > > AIM DirectIM can't work within an OTR-encrypted chat; the same is true of any > other gaim plugin-based encryption scheme. > > 1) User sends message in Gaim > 2) Gaim gives plugins an opportunity to modify the message; an encryption > plugin such as gaim-otr encrypts the message if appropriate, returning the > encrypted message > 3) Gaim sends the encrypted message to the prpl > 4) In the case of oscar within a DirectIM session, the message is normally > post-processed, looking for tags, which reference ids from the gaim img > store in the form where gaim_imgstore_get(2) will return the > GaimStoredImage* for the image. The image's data, size, etc. are inserted > into the message..... but the message is encoded, so such a tag isn't found, > and images can not be sent. > > A similar situation exists on the receiving side, where the prpl processes > the incoming message, looking for tags to convert to the gaim img store > and their corresponding IDs but sees only the gibberish of an encrypted > message. > > As I mentioned, this is not specific to the gaim-otr implementation but > rather a result of how the signals are set up. One solution I've come up > with is giving the prpl a chance to modify the outgoing message before it is > sent to plugins via a signal, and similarly call the prpl for final > post-processing of incoming messages after the first signal is sent when > receiving a message. > > Thoughts? > > Cheers, > Evan > www.adiumx.com I only partly understand the issue here, and I have next to know undertanding of the underlying encryption stuff, but couldn't a prpl that needs to do this processing just use the same signals that the encryption plugins use? And use the signal priority stuff to ensure that they come first, to facilitate this we can change the handful of GAIM_PRIORITY defines to be an enum with default levels for PRPL/ENCRYPTION/etc. Would that not solve at least some of the problems? Or is there something I'm missing? Does the prpl processing do funny things to the message that the plugins would have to know about to deal with or something? Would the prpls need to keep track of messages between the signal and the normal mechanism somehow? (Would we need to start tagging messages with per-conversation ids to make this work more easily?) -Etan From alex323 at gmail.com Fri Feb 24 15:05:28 2006 From: alex323 at gmail.com (Alex) Date: Fri, 24 Feb 2006 15:05:28 -0500 Subject: [OTR-dev] libotr API documentation Message-ID: <43FF6708.6050809@gmail.com> Hey. Does libotr have any API documentation that I could take a look at? I am coding an application that uses the library, and am looking at gaim-otr as my guide for now. If you want, I can write up a doc when I am done coding my application. - Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: OpenPGP digital signature URL: From ian at cypherpunks.ca Fri Feb 24 15:31:10 2006 From: ian at cypherpunks.ca (Ian Goldberg) Date: Fri, 24 Feb 2006 15:31:10 -0500 Subject: [OTR-dev] libotr API documentation In-Reply-To: <43FF6708.6050809@gmail.com> References: <43FF6708.6050809@gmail.com> Message-ID: <20060224203110.GB31096@smtp.paip.net> On Fri, Feb 24, 2006 at 03:05:28PM -0500, Alex wrote: > Hey. Does libotr have any API documentation that I could take a look at? > I am coding an application that uses the library, and am looking at > gaim-otr as my guide for now. If you want, I can write up a doc when I > am done coding my application. Right now, it's just what's in libotr/README. If you'd like to write up better documentation, we'd love you to do it! :-) - Ian From evan.s at dreskin.net Sat Feb 25 18:28:59 2006 From: evan.s at dreskin.net (Evan Schoenberg) Date: Sat, 25 Feb 2006 18:28:59 -0500 Subject: [OTR-dev] Re: [Gaim-devel] gaim-OTR, AIM DirectIM, and messaging signals In-Reply-To: References: <1521E76B-181A-47E3-91B0-D790B0F726C9@dreskin.net> Message-ID: On Feb 23, 2006, at 10:33 PM, Etan Reisner wrote: > I only partly understand the issue here, and I have next to know > undertanding of the underlying encryption stuff, but couldn't a > prpl that needs to do this processing just use the same signals > that the encryption plugins use? And use the signal priority stuff > to ensure that they come first, to facilitate this we can change > the handful of GAIM_PRIORITY defines to be an enum with default > levels for PRPL/ENCRYPTION/etc. Would that not solve at least some > of the problems? Or is there something I'm missing? Does the prpl > processing do funny things to the message that the plugins would > have to know about to deal with or something? Would the prpls need > to keep track of messages between the signal and the normal > mechanism somehow? (Would we need to start tagging messages with > per-conversation ids to make this work more easily?) > > -Etan So long as the message signal allows access to the GaimConversation for the message (which it does IIRC), nothing needs to be added -- and I think this would work nicely, indeed, with the added bonus of minimal new code needing to be written. I just noticed that the 'sub away formatters' in AIM -- %n for name, % d for date, etc. -- are also broken in OTR chats for the same reason; gaim_str_sub_away_formatters() should be done in such a signal handler even outside of directIMs. -Evan -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From mark at kingant.net Sat Feb 25 18:12:24 2006 From: mark at kingant.net (Mark Doliner) Date: Sat, 25 Feb 2006 18:12:24 -0500 Subject: [OTR-dev] Re: [Gaim-devel] gaim-OTR, AIM DirectIM, and messaging signals In-Reply-To: References: <1521E76B-181A-47E3-91B0-D790B0F726C9@dreskin.net> Message-ID: <20060225231205.M58983@kingant.net> On Thu, 23 Feb 2006 22:33:20 -0500 (EST), Etan Reisner wrote > On Fri, 17 Feb 2006, Evan Schoenberg wrote: > > (Please reply-to-all, as I'm sending this to both relevant lists) > > > > AIM DirectIM can't work within an OTR-encrypted chat; the same is true of any > > other gaim plugin-based encryption scheme. > > > > 1) User sends message in Gaim > > 2) Gaim gives plugins an opportunity to modify the message; an encryption > > plugin such as gaim-otr encrypts the message if appropriate, returning the > > encrypted message > > 3) Gaim sends the encrypted message to the prpl > > 4) In the case of oscar within a DirectIM session, the message is normally > > post-processed, looking for tags, which reference ids from the gaim img > > store in the form where gaim_imgstore_get(2) will return the > > GaimStoredImage* for the image. The image's data, size, etc. are inserted > > into the message..... but the message is encoded, so such a tag isn't found, > > and images can not be sent. > > > > A similar situation exists on the receiving side, where the prpl processes > > the incoming message, looking for tags to convert to the gaim img store > > and their corresponding IDs but sees only the gibberish of an encrypted > > message. > > > > As I mentioned, this is not specific to the gaim-otr implementation but > > rather a result of how the signals are set up. One solution I've come up > > with is giving the prpl a chance to modify the outgoing message before it is > > sent to plugins via a signal, and similarly call the prpl for final > > post-processing of incoming messages after the first signal is sent when > > receiving a message. > > > > Thoughts? > > > > Cheers, > > Evan > > www.adiumx.com > > I only partly understand the issue here, and I have next to know > undertanding of the underlying encryption stuff, but couldn't a prpl > that needs to do this processing just use the same signals that the > encryption plugins use? And use the signal priority stuff to ensure > that they come first, to facilitate this we can change the handful > of GAIM_PRIORITY defines to be an enum with default levels for > PRPL/ENCRYPTION/etc. Would that not solve at least some of the > problems? Or is there something I'm missing? Does the prpl > processing do funny things to the message that the plugins would > have to know about to deal with or something? Would the prpls need > to keep track of messages between the signal and the normal > mechanism somehow? (Would we need to start tagging messages with per- > conversation ids to make this work more easily?) > > -Etan It sounds like that would work, and would be cleaner -Mark From evan.s at dreskin.net Mon Feb 27 13:40:20 2006 From: evan.s at dreskin.net (Evan Schoenberg) Date: Mon, 27 Feb 2006 13:40:20 -0500 Subject: [OTR-dev] Decrypting messages from an old OTR conversation Message-ID: I have a user bugging me about this, and I'm not sure how to respond. The problem: some services support serverside offline messaging. Yahoo and ICQ, for example. If Bob is in an encrypted conversation with Alice, and Alice signs offline, the service still allows Bob to message Alice, storing the (encrypted) message on the server for delivery when Alice next signs online. Bob knows that Alice has the information for decrypting his message, since they've been communicating previously... So Alice signs on a day later... but she can't read the message, since the conversation has since ended. She receives: The encrypted message received from Bob is unreadable, as you are not currently communicating privately. Any thoughts? -Evan -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From paul at cypherpunks.ca Mon Feb 27 14:08:38 2006 From: paul at cypherpunks.ca (Paul Wouters) Date: Mon, 27 Feb 2006 20:08:38 +0100 (CET) Subject: [OTR-dev] Decrypting messages from an old OTR conversation In-Reply-To: References: Message-ID: On Mon, 27 Feb 2006, Evan Schoenberg wrote: > The problem: some services support serverside offline messaging. Yahoo and > ICQ, for example. If Bob is in an encrypted conversation with Alice, and > Alice signs offline, the service still allows Bob to message Alice, storing > the (encrypted) message on the server for delivery when Alice next signs > online. Bob knows that Alice has the information for decrypting his message, > since they've been communicating previously... > > So Alice signs on a day later... but she can't read the message, since the > conversation has since ended. She receives: > The encrypted message received from Bob is unreadable, as you are not > currently communicating privately. When signing off, the client should close the OTR connection to the "finished" state. Paul -- "Do it today, tomorrow it will be illegal" --- Source unknown