From mark at kingant.net Tue Mar 6 01:44:14 2007 From: mark at kingant.net (Mark Doliner) Date: Tue, 6 Mar 2007 01:44:14 -0500 Subject: [OTR-dev] Lost OTR keys when upgrading from Gaim beta 5 to beta 6 Message-ID: <20070306063934.M80839@kingant.net> An Ubuntu user filed a bug[1] about some problems he encountered when upgrading from Gaim 2.0.0 beta 5 to Gaim 2.0.0 beta 6. The problems are related to the split of prpl-oscar into prpl-aim and prpl-icq. "The most serious problem I encountered was the fact, that ALL my icq ("oscar") OTR-keys and fingerprints were no longer found by gaim until I manually renamed all references in the config." I'm not familiar with the OTR plugin and don't know how yous guys store OTR keys and fingerprints, but you might need to rename your settings if the user is running Gaim 2.0.0 beta 6 or higher. If this has already been fixed, or is not a real problem then please ignore me. Thanks, Mark [1] https://launchpad.net/ubuntu/+source/gaim/+bug/88647 From ian at cypherpunks.ca Tue Mar 6 08:43:59 2007 From: ian at cypherpunks.ca (Ian Goldberg) Date: Tue, 6 Mar 2007 08:43:59 -0500 Subject: [OTR-dev] Lost OTR keys when upgrading from Gaim beta 5 to beta 6 In-Reply-To: <20070306063934.M80839@kingant.net> References: <20070306063934.M80839@kingant.net> Message-ID: <20070306134359.GB22164@thunk.cs.uwaterloo.ca> On Tue, Mar 06, 2007 at 01:44:14AM -0500, Mark Doliner wrote: > An Ubuntu user filed a bug[1] about some problems he encountered when > upgrading from Gaim 2.0.0 beta 5 to Gaim 2.0.0 beta 6. The problems are > related to the split of prpl-oscar into prpl-aim and prpl-icq. > > "The most serious problem I encountered was the fact, that ALL my icq > ("oscar") OTR-keys and fingerprints were no longer found by gaim until I > manually renamed all references in the config." > > I'm not familiar with the OTR plugin and don't know how yous guys store OTR > keys and fingerprints, but you might need to rename your settings if the user > is running Gaim 2.0.0 beta 6 or higher. If this has already been fixed, or is > not a real problem then please ignore me. We've heard this before, but I think it's not a real problem; it's a one-time PITA for existing users, and putting in code to automatically try to compensate is likely to introduce more bugs than it's worth. Not only that, but the gaim2 beta series has proven to be a highly moving target, and I'd prefer to see it settle down before dealing with a minor issue involving a particular beta transition. - Ian From ian at cypherpunks.ca Wed Mar 7 17:07:07 2007 From: ian at cypherpunks.ca (Ian Goldberg) Date: Wed, 7 Mar 2007 17:07:07 -0500 Subject: [OTR-dev] Linking libgcrypt statically into gaim-otr.so Message-ID: <20070307220707.GI8965@thunk.cs.uwaterloo.ca> I figured out how to do this on Linux. I have no idea how to do it on other systems, or how to get libtool to do this on its own (possibly not possible). The problem, again: other gaim plugins, such as Jabber or ldap, use libgcrypt (often in the guise of TLS). libgcrypt uses global variables, and assumes that it will only have one caller per address space. The various plugins initialize libgcrypt's global variables, and stomp all over each other's (and gaim-otr's) initializations. Badness ensues. The "right" solution is for libgcrypt to stop using global variables, and to pass handles around. Back-compatibility can be easily arranged by having the current routines do something like: gcry_foo(int bar, char *baz) { gcry_foo_r(&global_handle, bar, baz); } but callers "in the know" could call gcry_foo_r directly with a private handle. But until that happens, here's a workaround for gaim-otr to link libgcrypt statically. It's actually pretty tricky, since it seems calls from one .o to another in a .so file are always looked up dynamically, so if another copy of libgcrypt exists in the address space, you'll still get that one. So you have to put everything in a single .o, make the libgcrypt symbols local, and turn the result into a .so. Here's Makefile.static (for gaim-otr): .libs/gaim-otr.so: FORCE # Build everything from the standard Makefile make # Link everything, including libotr and libgcrypt, together into # a single .o file ld -r .libs/otr-plugin.o .libs/ui.o .libs/dialogs.o .libs/gtk-ui.o .libs/gtk-dialog.o /usr/lib/libotr.a /usr/lib/libgcrypt.a /usr/lib/libgpg-error.a -o .libs/gaim-otr-shared.o # Make all the libgcrypt references local to that .o file objcopy -w -L '*gcry*' .libs/gaim-otr-shared.o .libs/gaim-otr-static.o # Turn the .o into a .so gcc -shared .libs/gaim-otr-static.o -Wl,-soname -Wl,gaim-otr.so -o .libs/gaim-otr.so FORCE: - Ian From mail at scottellis.com.au Thu Mar 22 11:55:23 2007 From: mail at scottellis.com.au (Scott Ellis) Date: Fri, 23 Mar 2007 02:55:23 +1100 Subject: [OTR-dev] html in otr messages Message-ID: <96e269140703220855k6eadbe74h3991eb24e5e93cf3@mail.gmail.com> From ian at cypherpunks.ca Thu Mar 22 14:17:00 2007 From: ian at cypherpunks.ca (Ian Goldberg) Date: Thu, 22 Mar 2007 14:17:00 -0400 Subject: [OTR-dev] html in otr messages In-Reply-To: <96e269140703220855k6eadbe74h3991eb24e5e93cf3@mail.gmail.com> References: <96e269140703220855k6eadbe74h3991eb24e5e93cf3@mail.gmail.com> Message-ID: <20070322181700.GF23856@thunk.cs.uwaterloo.ca> On Fri, Mar 23, 2007 at 02:55:23AM +1100, Scott Ellis wrote: > >From Wintermute on the Miranda forum: > > "Hm .. ok .. the friend made a statement and asked me to post it for him (as > he isn't registered here and to lazy to do so): > > "Quote: > I had a lengthy email conversation with Ian Goldberg, one of the authors of > OTR, libotr and the gaim-otr plugin. If you read the OTR spec carefully, you > will see that it specifies optional HTML-formating in the plaintext. As > OTR-messages are merely encapsulated using Jabber (or other) protocols, Ian > thinks (as do I after thinking about it) that the OTR specs supersede the > standards of "lower level" protocols such as XMPP. It is the job of an OTR > plugin to process the HTML tags in the plaintext, if they are not used by > the client it's the plugins job to strip them. > If you don't see it that way, I suggest you contact the otr-dev > mailinglist." > > I think of it quite the opposite way - OTR simply encapsulates protocol > messages > > OTR would have quite a job to do trying to detect whether the client > supports HTML in Miranda - there are so many messaging modules etc. And > they're likely to change at any time - it would make maintainence difficult. > I don't think tracking the client's capabilities is the plugin's job. You're right; I think that whatever calls the OTR plugin should be able to understand what the plugin outputs. In gaim, there's no problem, since gaim understands the format of OTR plaintext messages already. Miranda hasn't (yet?) implemented tag-handling in most of its protocol plugins, fine. So the Miranda AIM plugin, for example, has to explicitly strip the tags, instead of parsing them. You could have the Miranda OTR plugin optionally do that instead; the protocol plugin could pass a parameter that says "strip the HTML tags from the plaintext before giving it back to me". Or just have a function in the OTR plugin to do that (steal it from the AIM plugin) that the protocol plugins can call. > And I think the client should output the same *intended message* whether or > not OTR is installed - after decription, OTR messages from gaim OTR contain > formatting html, whereas without OTR gaim outputs no formatting html. Not true: see my otr-users message. gaim sends *both* the formatted and non-formatted versions in Jabber. > This > means transmitting more information than usual - which, although very > unlikely, may not be something that the user wants. There's no more information in the OTR version than in the original Jabber message. Miranda was just ignoring the more information-rich part of the Jabber message. > Removing the tags means I would have to reimlement something already > implemented by at least the AIM protocol plugin. Processing the codes > 'properly' for the client could involve conversion from e.g. html to > bbcodes, if the client supports those - which would mean differences in the > nature of OTR plugins for different clients. Or further, if the OTR spec > specifies handling of HTML, then the otr library should be able to handle it > - but again that's a reimplementation of stuff that the protocol can already > do. The OTR library gives you a plaintext message, in utf-8 encoding, that is allowed to have HTML tags in it. If you need something different for your application, you'll need to convert it. For example, if your application decides it needs to convert the HTML tags to bbcodes, either it, or its OTR plugin, will need to do that; libotr won't do it by default. [Of course, if there's a really common conversion that lots of different clients need, we could consider just bundling it with the library.] > Also - and I really don't mean to criticize - but the protocol specs for > things like jabber and other open protocols, with their RFC's and comittees > etc etc, tend to be thought out pretty well. The reasons for disallowing > things like 'mixed contect' (from the jabber RFC) are usually pretty good. > For example, if I want to send the text blue to a friend, I can > do so over jabber (because it is encoded and decoded by the protocol so as > to not create 'mixed content') and expect him to get the message as I typed > it, if the client performs to the spec. With OTR, if it's removing tags on > clients that do not support markup, how does it tell the difference between > formatting tags and what the user has typed? At a minimum it would somehow > have to encode tags in message text and formatting tags differently - or you > have restricted what messages users can and can't send. OTR expects your plaintext input to be HTML-encoded. Which means if there's a literal "<" in your plaintext message, you should convert it to "<" before giving it to OTR. That's certainly what Jabber does: even without OTR, "<"s in messages get converted to "<" on the wire. So if you send "blue" (a message intending to start with a literal "<") to your buddy, your end will convert it to "<font>blue</font>" (whether or not you're using OTR), then if you're using OTR, you'll pass *that* to the OTR plugin, which will encrypt it. Your buddy's client will decrypt it back to "<font>blue</font>" and display it to him as "blue". Out of curiosity, why doesn't Miranda just parse the HTML tags for all protocols that support them? - Ian From rabbi at abditum.com Thu Mar 22 14:26:19 2007 From: rabbi at abditum.com (Len Sassaman) Date: Thu, 22 Mar 2007 10:26:19 -0800 (PST) Subject: [OTR-dev] gaim-otr art In-Reply-To: References: <20061027010201.30794.32036.Mailman@brandeis.paip.net> <1161912165.12700.13.camel@asshair> <1162017307.5285.2.camel@asshair> Message-ID: On Sat, 28 Oct 2006, Paul Wouters wrote: > buttons are very carefully chosen. Grey means "we don't know for sure > who this is", multiple grey people mean "others you dont know might read > this". The one yellow coloured person means "only this known verified > person can read this". Those images can not be replaced by other imagery > without discussion on whether the new images still clearly convey that > message. Hi Paul, Pardon me if this is answered somewhere in the archives; I couldn't find it. Were these icon decisions made based on any prior HCI work in this area, or was this a design decision of the OTR time? If the former, could you point me at it? (If the latter, could you point me at the best summary of the rationale behind it, and any alternatives considered?) Thanks, Len From paul at cypherpunks.ca Thu Mar 22 22:39:44 2007 From: paul at cypherpunks.ca (Paul Wouters) Date: Fri, 23 Mar 2007 03:39:44 +0100 (CET) Subject: [OTR-dev] gaim-otr art In-Reply-To: References: <20061027010201.30794.32036.Mailman@brandeis.paip.net> <1161912165.12700.13.camel@asshair> <1162017307.5285.2.camel@asshair> Message-ID: On Thu, 22 Mar 2007, Len Sassaman wrote: > Pardon me if this is answered somewhere in the archives; I couldn't find > it. Were these icon decisions made based on any prior HCI work in this > area, or was this a design decision of the OTR time? If the former, could > you point me at it? (If the latter, could you point me at the best > summary of the rationale behind it, and any alternatives considered?) Most of the discussion happened on the list, as far as I remember. Some might have come from face to face meetings. In the end, I think Kat and Ian made the final decisions on the icons. What keeps reoccuring though is people asking for a padlock, and other people saying the padlock just cannot convey the message. Paul From mail at scottellis.com.au Thu Mar 22 23:20:06 2007 From: mail at scottellis.com.au (Scott Ellis) Date: Fri, 23 Mar 2007 14:20:06 +1100 Subject: [OTR-dev] html in otr messages In-Reply-To: <20070322181700.GF23856@thunk.cs.uwaterloo.ca> References: <96e269140703220855k6eadbe74h3991eb24e5e93cf3@mail.gmail.com> <20070322181700.GF23856@thunk.cs.uwaterloo.ca> Message-ID: <96e269140703222020y57105700r26296b6051fc86b4@mail.gmail.com> First I'll explain how encryption works in Miranda, then I'll address a couple of your points. Miranda has a 'message chain'. When a message is received, it gets converted on the network level by the protocol into a standard internal format. Then it is passed through the message chain, and back to the protocol before being displayed to the user. When sending, it also goes through the chain but in reverse. Any plugin can register as a 'filter' which means, for the contacts it specifies, it will receive the messages that go through the message chain and it can do with them what it wants. There are several predefined types of filters - encryption, translation, etc - and the type controls the order of the 'chain' - so that e.g. decryption is done before translation. Any properly designed mirnada protocol plugin will do any processing of text within recv'd messages after the chain has been called, and within sent message before the chain is called - like AIM does. Protocols can optionally install their own filters to do processing at other points in the chain. IMO this is the correct way to do this - it allows for proper interoperation of different plugins that affect the contents of messages - and it allows plugins to concentrate on their job, e.g. ecryption, without worrying about any protocol issues. It allows for different encryption plugins to be used with a standard interface - the protocol does not need to know anything about the encryption, and visa versa. But it does mean that encryption plugins are just that - and not protocols that can specify their own rules about message content in the plaintext. The protocol has a right to expect valid protocol messages after decryption. I could just pass the message on to the user directly without continuing through the message chain, but then the message would not be processed by other filters registered for that contact. Miranda doesn't do tag stripping or parsing, because only AIM supports tags in messages. Alright, in a way Jabber does too - but the protocol itself, not the miranda jabber plugin, provides a way to ignore them. Most protocols do not support html in messages. As is proper, it is the protocol's job to convert messages between the network encoding and the internal encoding. Since this is being done already by protocols, and happens automatically in miranda even for OTR encrypted messages, it really should not be re-implemented in the OTR plugin. Why do you allow markup in otr messages? OTR doesn't need it. I'm arguing that the spec should be changed in this respect - I think OTR messages should be allowed to contain anything valid on the underlying protocol, and nothing else. That means OTR can stick to the job of encryption, in any client. I'm not arguing because I'm too lazy to make changes to the plugin - in fact I'm planning a 'html stripper' plugin to get rid of this problem in miranda, and as you say by pinching the code from AIM it's a very small job - but that is not directly related to this discussion. I'm arguing because I think the way the OTR plugin in miranda works now is correct, and OTR should, for the sake of developers for any client, stick to encryption and keep things simple, and not try to call itself a 'protocol' and deal with the encoding issues that entails. Currently, if you look at the code, the miranda OTR plugin and the gaim one are very similar in functionality - neither does parsing of HTML tags, or URL encoding. If the spec was changed to remove the 'optional html markup', then all that needs to be done is for gaim otr to do the encryption/decryption after/before the protocol has made the message valid according to it's own rules - all protocols in all clients must by definition contain the code to do that already. If markup is allowed just because this is difficult to do in gaim, then it's the fault of the way gaim works, and neither the OTR spec nor any OTR plugins should have to shoulder the burden of working around that. On 3/23/07, Ian Goldberg wrote: > > On Fri, Mar 23, 2007 at 02:55:23AM +1100, Scott Ellis wrote: > > >From Wintermute on the Miranda forum: > > > > "Hm .. ok .. the friend made a statement and asked me to post it for him > (as > > he isn't registered here and to lazy to do so): > > > > "Quote: > > I had a lengthy email conversation with Ian Goldberg, one of the authors > of > > OTR, libotr and the gaim-otr plugin. If you read the OTR spec carefully, > you > > will see that it specifies optional HTML-formating in the plaintext. As > > OTR-messages are merely encapsulated using Jabber (or other) protocols, > Ian > > thinks (as do I after thinking about it) that the OTR specs supersede > the > > standards of "lower level" protocols such as XMPP. It is the job of an > OTR > > plugin to process the HTML tags in the plaintext, if they are not used > by > > the client it's the plugins job to strip them. > > If you don't see it that way, I suggest you contact the otr-dev > > mailinglist." > > > > I think of it quite the opposite way - OTR simply encapsulates protocol > > messages > > > > OTR would have quite a job to do trying to detect whether the client > > supports HTML in Miranda - there are so many messaging modules etc. And > > they're likely to change at any time - it would make maintainence > difficult. > > I don't think tracking the client's capabilities is the plugin's job. > > You're right; I think that whatever calls the OTR plugin should be able > to understand what the plugin outputs. In gaim, there's no problem, > since gaim understands the format of OTR plaintext messages already. > Miranda hasn't (yet?) implemented tag-handling in most of its protocol > plugins, fine. So the Miranda AIM plugin, for example, has to > explicitly strip the tags, instead of parsing them. You could have the > Miranda OTR plugin optionally do that instead; the protocol plugin could > pass a parameter that says "strip the HTML tags from the plaintext > before giving it back to me". Or just have a function in the OTR plugin > to do that (steal it from the AIM plugin) that the protocol plugins can > call. Miranda won't implement tag handling in most of it's protocols, because the specs do not allow for them. Yes, it's easy to copy the code from aim - but I would like to avoid having two copies of the same code in the same application (unless the user can choose to do so, or choose not to without losing functionality - e.g. by installing an optional 'html stripper' plugin) - AIM obviously still needs it for clients without OTR, so it can't simply be moved. Having OTR-specific flags means the protocols need to know something about the encryption that they otherwise would not. To keep the interface standard, other encryption plugins would need to handle such flags as well. And AIM does parse the tags - it will optionally convert them to bbcodes. It's not scalable - to keep OTR message sessions otherwise equivalent to non-otr ones, the OTR plugin would have to to re-implement all similar functionality from all protocol plugins, if and when that functionality exists. > And I think the client should output the same *intended message* whether > or > > not OTR is installed - after decription, OTR messages from gaim OTR > contain > > formatting html, whereas without OTR gaim outputs no formatting html. > > Not true: see my otr-users message. gaim sends *both* the formatted and > non-formatted versions in Jabber. > This > > means transmitting more information than usual - which, although very > > unlikely, may not be something that the user wants. > > There's no more information in the OTR version than in the original > Jabber message. Miranda was just ignoring the more information-rich > part of the Jabber message. Yes, I didn't realise this about Jabber. What about other protocols like ICQ and Yahoo? > Removing the tags means I would have to reimlement something already > > implemented by at least the AIM protocol plugin. Processing the codes > > 'properly' for the client could involve conversion from e.g. html to > > bbcodes, if the client supports those - which would mean differences in > the > > nature of OTR plugins for different clients. Or further, if the OTR spec > > specifies handling of HTML, then the otr library should be able to > handle it > > - but again that's a reimplementation of stuff that the protocol can > already > > do. > > The OTR library gives you a plaintext message, in utf-8 encoding, that > is allowed to have HTML tags in it. If you need something different for > your application, you'll need to convert it. For example, if your > application decides it needs to convert the HTML tags to bbcodes, either > it, or its OTR plugin, will need to do that; libotr won't do it by > default. [Of course, if there's a really common conversion that lots of > different clients need, we could consider just bundling it with the > library.] Yes, with the spec the way it is, that's true. But why is markup specifically allowed? My main point is that if it were not, then I wouldn't have to do that conversion. The secondary point here is that the OTR library should encapsulate the protocol, if it's considered a protocol, in it's entirety - not everything except one little bit. If the OTR library just does encryption/decryption, then, IMO, OTR would be better defined as an encryption layer on top of other protocols. > Also - and I really don't mean to criticize - but the protocol specs for > > things like jabber and other open protocols, with their RFC's and > comittees > > etc etc, tend to be thought out pretty well. The reasons for disallowing > > things like 'mixed contect' (from the jabber RFC) are usually pretty > good. > > For example, if I want to send the text blue to a friend, I > can > > do so over jabber (because it is encoded and decoded by the protocol so > as > > to not create 'mixed content') and expect him to get the message as I > typed > > it, if the client performs to the spec. With OTR, if it's removing tags > on > > clients that do not support markup, how does it tell the difference > between > > formatting tags and what the user has typed? At a minimum it would > somehow > > have to encode tags in message text and formatting tags differently - or > you > > have restricted what messages users can and can't send. > > OTR expects your plaintext input to be HTML-encoded. Which means if > there's a literal "<" in your plaintext message, you should convert it > to "<" before giving it to OTR. That's certainly what Jabber does: > even without OTR, "<"s in messages get converted to "<" on the wire. > So if you send "blue" (a message intending to start > with a literal "<") to your buddy, your end will convert it to > "<font>blue</font>" (whether or not you're using OTR), then > if you're using OTR, you'll pass *that* to the OTR plugin, which will > encrypt it. Your buddy's client will decrypt it back to > "<font>blue</font>" and display it to him as > "blue". Hm - i didn't see anything in the spec saying the plaintext must be URL encoded. I assume you mean that html entities typed in by the user are URL encoded and formatting tags are not? 'Cause that's what gaim otr is sending. If jabber is doing the URL encoding in gaim with OTR, then it does get two goes at the message (URL encoding before encryption, and then again to send the encrypted message), and so it should get two goes at recv'd messages too, if just for the sake of symetry. Which means it's not difficult to let protocols do the job of making otr messages conform to the protocol rules under gaim. But I suspect that in gaim, URL encoding/decoding is actually done by the UI. In miranda, this would mean having another block of code to do a job that is already handled by the jabber protocol plugin. And, for properly designed miranda protocol plugins that will do such text manipulation at the proper point in the message chain, for e.g. compatibility with other encryption plugins, it will mean that OTR messages would be double-URL-encoded - ugh - or OTR would have to know which protocols already do it, and it would need this knowledge to be maintained either by code changes or API changes. Is it very hard to add a hook in gaim, so that OTR can affect messages just before or just after they are sent/recv'd in the network layer? Option 1 benefits (obviously my preferred option) - remove optional html markup from otr spec and change gaim architecture ----- looser coupling/no connection between otr spec and client capabilities - smaller scope of responsibilities for otr plugins - easier to implement in a wider range of clients no doubling-up of code no continued maintenance of miranda otr plugin, possibly other client plugins gaim gets the benefit of added functionality that can be used accross a range of plugins conformance to miranda's existing encryption plugin standards no miranda changes required after the work is done, no negative side-effects ...vs Option 2 benefits - make miranda OTR compliant with current OTR spec: ------ relatively easy to implement so that it works for now, by only changing the miranda plugin no gaim changes required The third option of modifying all miranda's message window plugins (and extensions such as ieview), the miranda messageing API, and probably all protocols, to allow for html markup and to do URL encoding/decoding isn't very practical - the benefit would only be to aim, otr, and jabber at present. Sorry for being so long-winded about this. We're obviously both going to be biased by the environment in which we're working - but shouldn't the end result, in terms of simplicity, 'purity', maintainability, and user experience, be more important than the ease of getting there? As it stands there's no way to implement OTR in Miranda without negative side effects - but it's possible, with more effort, to make everything compliant with no (lasting) negative side effects, and even gain a few positive ones. Am I missing something? -------------- next part -------------- An HTML attachment was scrubbed... URL: From stpeter at jabber.org Mon Mar 26 11:55:03 2007 From: stpeter at jabber.org (Peter Saint-Andre) Date: Mon, 26 Mar 2007 09:55:03 -0600 Subject: [OTR-dev] html in otr messages In-Reply-To: <20070322181700.GF23856@thunk.cs.uwaterloo.ca> References: <96e269140703220855k6eadbe74h3991eb24e5e93cf3@mail.gmail.com> <20070322181700.GF23856@thunk.cs.uwaterloo.ca> Message-ID: <4607ECD7.2080507@jabber.org> Ian Goldberg wrote: > On Fri, Mar 23, 2007 at 02:55:23AM +1100, Scott Ellis wrote: >> >From Wintermute on the Miranda forum: >> I had a lengthy email conversation with Ian Goldberg, one of the authors of >> OTR, libotr and the gaim-otr plugin. If you read the OTR spec carefully, you >> will see that it specifies optional HTML-formating in the plaintext. As >> OTR-messages are merely encapsulated using Jabber (or other) protocols, Ian >> thinks (as do I after thinking about it) that the OTR specs supersede the >> standards of "lower level" protocols such as XMPP. It is the job of an OTR >> plugin to process the HTML tags in the plaintext, if they are not used by >> the client it's the plugins job to strip them. >> If you don't see it that way, I suggest you contact the otr-dev >> mailinglist." >> >> I think of it quite the opposite way - OTR simply encapsulates protocol >> messages >> >> OTR would have quite a job to do trying to detect whether the client >> supports HTML in Miranda - there are so many messaging modules etc. And >> they're likely to change at any time - it would make maintainence difficult. >> I don't think tracking the client's capabilities is the plugin's job. > > You're right; I think that whatever calls the OTR plugin should be able > to understand what the plugin outputs. Does this apply only to [X]HTML formatting? The reason I ask is that people put other kinds of extensions in Jabber messages, and in fact we have packet types other than ( and ). People would like to encrypt the entire packet for all XMPP packet types, not just the plaintext (or XHTML-formatted) message body, but we have not figured out how to do that in OTR, which is one reason why we are pursuing other approaches to end-to-end encryption: http://www.xmpp.org/extensions/xep-0116.html Peter -- Peter Saint-Andre XMPP Standards Foundation http://www.xmpp.org/xsf/people/stpeter.shtml -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 7358 bytes Desc: S/MIME Cryptographic Signature URL: From ogoffart at kde.org Fri Mar 30 09:28:49 2007 From: ogoffart at kde.org (Olivier Goffart) Date: Fri, 30 Mar 2007 15:28:49 +0200 Subject: [OTR-dev] mod_otr: man in the middle implementation for ejabberd Message-ID: <200703301528.54920.ogoffart@kde.org> Hello, I have developed a module for ejabberd (A widely used Jabber server) that do the man in the middle attack on OTR messages. I made this module to show that it is not possible to make e2e encryption user friendly. (for those who want an easy-to-use enabled-by-default e2e encryption) Lamda user (who doesn't really care about security) will not check fingerprint. So now, check your fingerprints :-) mod_otr: http://ejabberd.jabber.ru/mod_otr announcement: http://blog.bepointbe.be/index.php/2007/03/29/20-mod_otr -- Olivier -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From paul at cypherpunks.ca Sat Mar 31 14:38:19 2007 From: paul at cypherpunks.ca (Paul Wouters) Date: Sat, 31 Mar 2007 20:38:19 +0200 (CEST) Subject: [OTR-dev] mod_otr: man in the middle implementation for ejabberd In-Reply-To: <200703301528.54920.ogoffart@kde.org> References: <200703301528.54920.ogoffart@kde.org> Message-ID: On Fri, 30 Mar 2007, Olivier Goffart wrote: > I have developed a module for ejabberd (A widely used Jabber server) that do > the man in the middle attack on OTR messages. Excellent! > I made this module to show that it is not possible to make e2e encryption user > friendly. I would call OTR pretty userfriendly.... > So now, check your fingerprints :-) > mod_otr: http://ejabberd.jabber.ru/mod_otr I'll have to play with this! Paul -- Building and integrating Virtual Private Networks with Openswan: http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155 From ian at cypherpunks.ca Sat Mar 31 19:04:24 2007 From: ian at cypherpunks.ca (Ian Goldberg) Date: Sat, 31 Mar 2007 19:04:24 -0400 Subject: [OTR-dev] mod_otr: man in the middle implementation for ejabberd In-Reply-To: <200703301528.54920.ogoffart@kde.org> References: <200703301528.54920.ogoffart@kde.org> Message-ID: <20070331230424.GE5791@yoink.cs.uwaterloo.ca> On Fri, Mar 30, 2007 at 03:28:49PM +0200, Olivier Goffart wrote: > Hello, > > I have developed a module for ejabberd (A widely used Jabber server) that do > the man in the middle attack on OTR messages. Cool! I remember a long time ago people were talking about doing this for Trillian's SecureIM (which has no way at all to authenticate users), but I think (at least at the time) Trillian's SecureIM only worked on AIM, not Jabber. > I made this module to show that it is not possible to make e2e encryption user > friendly. (for those who want an easy-to-use enabled-by-default e2e > encryption) > Lamda user (who doesn't really care about security) will not check > fingerprint. But also remember that even if OTR is turned on by default, and Lambda user doesn't know anything about checking fingerprints, he's no worse off than if OTR weren't there to begin with, and is better off against at least some kinds of attackers. > So now, check your fingerprints :-) Yes, please do. :-) - Ian From donny.viszneki at gmail.com Sat Mar 31 19:44:36 2007 From: donny.viszneki at gmail.com (Donny Viszneki) Date: Sat, 31 Mar 2007 19:44:36 -0400 Subject: [OTR-dev] mod_otr: man in the middle implementation for ejabberd In-Reply-To: References: <200703301528.54920.ogoffart@kde.org> Message-ID: <44acbb800703311644u6addd811n7924e8e22fa62432@mail.gmail.com> On 3/31/07, Paul Wouters wrote: > On Fri, 30 Mar 2007, Olivier Goffart wrote: > > I made this module to show that it is not possible to make e2e encryption user > > friendly. > I would call OTR pretty userfriendly.... Please distinguish between user-friendly and idiot-friendly. If "it is not possible to make e2e encryption user-friendly" because you choose to lump complete morons in with the rest of the computer-using world, how far are you from saying that password authentication isn't safe? (Think about it -- even some of the most inane phishing scams can see quite a bit of success.) However, I do acknowledge that the idea of the fingerprint is not one that has experienced a great deal of penetration into the collective of mainstream computer users. I don't think this is the same as being user-unfriendly. However in my personal experience, many mainstream users are impatient when it comes to learning new ideas, and therefore it may be best to attack the problem of mainstream penetration head-on. I have a strange idea of how to do that which I'm sure others have thought of, but I have been sitting on it for the better part of a decade and so I figure I might as well throw it out there now that the discussion has begun: I have been rolling around an idea in my mind for a long time to improve the utility of fingerprint/checksum mechanisms by making fingerprints more memorable. What if the output of a hash weren't such tightly packed, seemingly random data? What if you plugged fingerprints into a dictionary file and got out a couple of words instead? What if you plugged it into a clipart library? Or the library of congress? Your encryption fingerprint could be the face of George Washington, five red-and-white striped ponies, or a line from a poem by Edgar Allen Poe. The more coherent and meaningful fingerprints/checksums are, the more memorable they are, and IMHO that makes them more useful. One challenge would be getting everyone to agree on what fingerprinting mechanism / service to use. A much more interesting challenge though would be studying what characteristics make a "humanistic fingerprinting" mechanism most effective. With the basic idea out of the way, here are a few elaborations: Using familiar graphical transformations such as recoloring, contorting, flipping, or tiling, you can increase the total output potential of any graphical media library perahps a hundred fold. Maybe the hash of the file you're looking for can be represented as a multi-colored and tiled (like a Warhol) George Bush Sr. Or maybe it is the upside-down silouette of a pine tree masked over the colors of the rainbow. Another idea would be to use a "generative" mechanism which would constitute its own humanistic representation algorithmically without requiring a multimedia library to draw from. It might produce anything from something reminiscent of modern art, to techno music authored by a psyconaut nearing the end of a four-day trip, or even the rorschac you might get during a psychological evaluation: but it does have the advantage of potentially being implemented with a small footprint and wouldn't require access to an enormous media library to draw upon. As mentioned earlier, I'm sure a lot of research could be invested in determining which techniques produce the most effective output. I have more to say on the subject but I just spent 6 minutes typing that I really should be spending working! If anyone has any comments feel free to email me. I really think that making fingerprinting a visual experience would garner more attention from the mainstream as well as developers for mainstream applications (I'd love to see the tiled shape of a turtle like a work by Escher the next time a "Could not verify SSL certificate" dialog pops up in Firefox ;)