From ian at cypherpunks.ca Sun Aug 2 17:11:11 2009 From: ian at cypherpunks.ca (Ian Goldberg) Date: Sun, 2 Aug 2009 17:11:11 -0400 Subject: [OTR-dev] Pidgin + Yahoo not support SMP? In-Reply-To: <20090731022657.95C11B0058@smtp.hushmail.com> References: <20090731022657.95C11B0058@smtp.hushmail.com> Message-ID: <20090802211111.GF5887@yoink.cs.uwaterloo.ca> On Thu, Jul 30, 2009 at 07:26:57PM -0700, chris-tuchs at hushmail.com wrote: > I just ran a pidgin to pidgin via yahoo test of SMP. It doesn't > seem to work with the MSS set to 799 or to 640 using the method I > described in my previous email. Alice and Bob have a private > (authenticated) conversation. Alice and Bob are able to send each > other 2000 character IMs which OTR seems to encrypt, fragment, > reassemble, and decrypt correctly. Alice does "Authenticate buddy" > and uses "Type the word secret" as the question and "secret" as the > answer. Bob enters secret when prompted, presses the authenticate > button. Both Alice and Bob see a progress bar dialog box that > remains stalled. I have not run the test in a 3-men-in-the-middle > configuration so I have no data on the actual messages sent and > received. You'd only need a single MITM to test pidgin<->pidgin. I'd appreciate it if you could tell me which messages aren't getting through. Thanks, - Ian From chris-tuchs at hushmail.com Thu Aug 6 00:21:05 2009 From: chris-tuchs at hushmail.com (chris-tuchs at hushmail.com) Date: Wed, 05 Aug 2009 21:21:05 -0700 Subject: [OTR-dev] Pidgin + Yahoo not support SMP? Message-ID: <20090806042106.0BB7420042@smtp.hushmail.com> I just tested SMP interoperation between the GreenLife implementation of OTR and the Pidgin implementation. With one issue, I am able to complete the SMP protocol in both directions. However the issue I encountered may explain the problems with Pidgin <--yahoo--> Pidgin SMP problems I have experienced. Yahoo does not maintain order of IM's in every case. Below is a message coming from Pidgin via Yahoo to the official Yahoo IM client, which doesn't have OTR. I was doing Avy1(OTR) <--SL--> Avy2(no OTR) <--cut-n-paste--> User1(yahoo no OTR) <--yahoo--> User2(pidgin with OTR). I arbitrarily cut the lines off at 64 characters cause all that matters really is demonstrating the out of order delivery. ?OTR,00002,00004,OCTiVspdIkxpqKlACVXDfCp/lFiI345aBsx60GgPF/vL1XP ?OTR,00001,00004,?OTR:AAIDAQAAAAMAAAAEAAAAwEIH2lnX+NPoHtYYXuDIvf ?OTR,00004,00004,Z+vhQwKssDnBB18z1nFURGZz3k2I2jaOqJek3U8/XkDlVd7 ?OTR,00003,00004,84StZgo+6T/vqtG+9OD4x3tHO1DirnzOih3A2Zg/j+I8CeG This is unfortunately a problem I also see in Second Life -- the IM system does not maintain order of fragments under some situations. Also when I send long messages (256KByte) Second Life is arbitrarily dropping some fragments. I am not sure what the 'right' solution is, but the existing message fragmentation re-assembly code in the released source does not handle out of order fragments or missing fragments. Is there more recent code which handles some of these problems? To be clear, SMP does work in GreenLife now, when SL doesn't drop or re-order fragments. I assume SMP would work Pidgin to Pidgin over Yahoo if Yahoo didn't reorder the fragments, but I have not tested that. Chris From chris-tuchs at hushmail.com Thu Aug 6 00:50:41 2009 From: chris-tuchs at hushmail.com (chris-tuchs at hushmail.com) Date: Wed, 05 Aug 2009 21:50:41 -0700 Subject: [OTR-dev] OTR, keyservers, MITM, etc. Message-ID: <20090806045041.27272B8063@smtp.hushmail.com> I would like to start a discussion of using OTR in conjunction with some form of keyservers and/or automatic detection of MITM. I have a particular protocol to discuss, but am interested in related ideas. Is this a good list to use, or can you suggest a better one? Chris From alex323 at gmail.com Thu Aug 6 00:56:48 2009 From: alex323 at gmail.com (Alex) Date: Thu, 6 Aug 2009 00:56:48 -0400 Subject: [OTR-dev] OTR, keyservers, MITM, etc. In-Reply-To: <20090806045041.27272B8063@smtp.hushmail.com> References: <20090806045041.27272B8063@smtp.hushmail.com> Message-ID: <20090806005648.65d8ee5e@gmail.com> On Wed, 05 Aug 2009 21:50:41 -0700 chris-tuchs at hushmail.com wrote: > I would like to start a discussion of using OTR in conjunction with > some form of keyservers and/or automatic detection of MITM. I have > a particular protocol to discuss, but am interested in related > ideas. > Is this a good list to use, or can you suggest a better one? > A web of trust would be grand. -- Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From gdt at ir.bbn.com Thu Aug 6 08:26:11 2009 From: gdt at ir.bbn.com (Greg Troxel) Date: Thu, 06 Aug 2009 08:26:11 -0400 Subject: [OTR-dev] OTR, keyservers, MITM, etc. In-Reply-To: <20090806045041.27272B8063@smtp.hushmail.com> (chris-tuchs@hushmail.com's message of "Wed, 05 Aug 2009 21:50:41 -0700") References: <20090806045041.27272B8063@smtp.hushmail.com> Message-ID: chris-tuchs at hushmail.com writes: > I would like to start a discussion of using OTR in conjunction with > some form of keyservers and/or automatic detection of MITM. I have > a particular protocol to discuss, but am interested in related > ideas. > Is this a good list to use, or can you suggest a better one? I have long thought that the right thing is to use openpgp-format keys for OTR, with the notion that someone would have an OTR signature key and sign that with their real openpgp key. Then once authentication is done for pgp it will work for OTR (or if the reason is OTR, you'll get PGP out of it). I suppose one could also have integration with S/MIME certs, but in my experience (outside of US government use) those tend to be certs from PKI certificate sellers that I can't figure out why I should believe. So I wouldn't argue against s/mime, but I wouldn't bother either. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 193 bytes Desc: not available URL: From ian at cypherpunks.ca Sun Aug 9 18:23:28 2009 From: ian at cypherpunks.ca (Ian Goldberg) Date: Sun, 9 Aug 2009 18:23:28 -0400 Subject: [OTR-dev] Pidgin + Yahoo not support SMP? In-Reply-To: <20090806042106.0BB7420042@smtp.hushmail.com> References: <20090806042106.0BB7420042@smtp.hushmail.com> Message-ID: <20090809222328.GF10974@yoink.cs.uwaterloo.ca> On Wed, Aug 05, 2009 at 09:21:05PM -0700, chris-tuchs at hushmail.com wrote: > I just tested SMP interoperation between the GreenLife > implementation > of OTR and the Pidgin implementation. With one issue, I am able to > complete the SMP protocol in both directions. However the issue I > encountered may explain the problems with Pidgin <--yahoo--> Pidgin > SMP problems I have experienced. Yahoo does not maintain order of > IM's in every case. Below is a message coming from Pidgin via Yahoo > to the official Yahoo IM client, which doesn't have OTR. I was > doing > Avy1(OTR) <--SL--> Avy2(no OTR) <--cut-n-paste--> User1(yahoo no > OTR) > <--yahoo--> User2(pidgin with OTR). I arbitrarily cut the lines off > at 64 characters cause all that matters really is demonstrating the > out of order delivery. > > ?OTR,00002,00004,OCTiVspdIkxpqKlACVXDfCp/lFiI345aBsx60GgPF/vL1XP > ?OTR,00001,00004,?OTR:AAIDAQAAAAMAAAAEAAAAwEIH2lnX+NPoHtYYXuDIvf > ?OTR,00004,00004,Z+vhQwKssDnBB18z1nFURGZz3k2I2jaOqJek3U8/XkDlVd7 > ?OTR,00003,00004,84StZgo+6T/vqtG+9OD4x3tHO1DirnzOih3A2Zg/j+I8CeG > > This is unfortunately a problem I also see in Second Life -- the IM > system does not maintain order of fragments under some situations. > Also when I send long messages (256KByte) Second Life is arbitrarily > dropping some fragments. > > I am not sure what the 'right' solution is, but the existing message > fragmentation re-assembly code in the released source does not > handle > out of order fragments or missing fragments. Is there more recent > code which handles some of these problems? > > To be clear, SMP does work in GreenLife now, when SL doesn't drop > or re-order fragments. I assume SMP would work Pidgin to Pidgin > over Yahoo if Yahoo didn't reorder the fragments, but I have not > tested that. That's bizarre. The OTR protocol specifically assumes that messages, although they may be dropped if the network flakes, will be delivered in the right order if they're delivered at all. An IM network that doesn't deliver messages in order would seem to be pretty poor for conversation, wouldn't it? Does GreenLife (or is it Yahoo?) really scramble the order of messages you send? - Ian From ian at cypherpunks.ca Sun Aug 9 18:27:27 2009 From: ian at cypherpunks.ca (Ian Goldberg) Date: Sun, 9 Aug 2009 18:27:27 -0400 Subject: [OTR-dev] OTR, keyservers, MITM, etc. In-Reply-To: <20090806045041.27272B8063@smtp.hushmail.com> References: <20090806045041.27272B8063@smtp.hushmail.com> Message-ID: <20090809222727.GG10974@yoink.cs.uwaterloo.ca> On Wed, Aug 05, 2009 at 09:50:41PM -0700, chris-tuchs at hushmail.com wrote: > I would like to start a discussion of using OTR in conjunction with > some form of keyservers and/or automatic detection of MITM. I have > a particular protocol to discuss, but am interested in related > ideas. > Is this a good list to use, or can you suggest a better one? This list is fine for that. The "use GPG keys for OTR" suggestion comes up pretty regularly. But most GPG keys don't have your IM username and network in a canonical format in them, so you'd have to manually associate the GPG key to the IM buddy anyway. Is that better than manually associating the OTR key? Is it better than using the Authenticate Buddy mechanism? Note that keyservers don't help you much if at all here. Or are you suggesting one of the timing-based MITM detection protocols? - Ian From chris-tuchs at hushmail.com Sun Aug 9 23:40:18 2009 From: chris-tuchs at hushmail.com (chris-tuchs at hushmail.com) Date: Sun, 09 Aug 2009 20:40:18 -0700 Subject: [OTR-dev] Pidgin + Yahoo not support SMP? Message-ID: <20090810034018.6320C20040@smtp.hushmail.com> On Sun, 09 Aug 2009 15:23:28 -0700 Ian Goldberg >wrote: >On Wed, Aug 05, 2009 at 09:21:05PM -0700, chris-tuchs at hushmail.com >wrote: >> >> ?OTR,00002,00004,OCTiVspdIkxpqKlACVXDfCp/lFiI345aBsx60GgPF >> ?OTR,00001,00004,?OTR:AAIDAQAAAAMAAAAEAAAAwEIH2lnX+NPoHtYY >> ?OTR,00004,00004,Z+vhQwKssDnBB18z1nFURGZz3k2I2jaOqJek3U8/X >> ?OTR,00003,00004,84StZgo+6T/vqtG+9OD4x3tHO1DirnzOih3A2Zg/j That is what I received in the official Yahoo IM client when I do an SMP dialog from Pidgin. I can't say if a Yahoo server reordered the lines, or if the Yahoo client did. But it seems much more likely to me that it is a property of the Yahoo servers than a property of Pidgin, OTR, or the Yahoo client. I doubt Pidgin or OTR since it is not a 100% repeatable case. When I was testing about 1 out of 6 fragmented messages had the fragments reordered. It was not the case, for example, that the second message of the SMP protocol always was reordered. Naturally the problem will be more obvious with smaller MSS and I was working with MSS of 640 characters in this case. My experiments show that I can actually cut and paste 800 characters to the Yahoo client, but only 650 to the Yahoo web client. So I conservatively set everybody up to use 640 for that test. I have run a couple experiments of SMP from Pidgin to Pidgin over Yahoo, with no man-in-the-middle. I was unable to get SMP to work with MSS set to either 800 or 640 characters. >That's bizarre. The OTR protocol specifically assumes that >messages, although they may be dropped if the network flakes, >will be delivered in the right order if they're delivered at >all. An IM network that doesn't deliver messages in order >would seem to be pretty poor for conversation, wouldn't it? >Does GreenLife (or is it Yahoo?) really scramble the order of >messages you send? It does *seem* like a safe assumption that IM systems will deliver messages in the order they are queued. But my observations of both Second Life and of Yahoo show that for whatever reason it is not a valid assumption. In Second Life under high server load, in a group chat I sometimes see something like you said: it's at the usual place you said: I'll see you at the next meeting Although I typed the lines in the opposite order. The time between my sending "I'll see..." and "it's at..." can vary depending on the load. The higher the load the longer I can wait to send the second message but still have it arrive first. I haven't checked the Pidgin source closely, but the GreenLife client adds no delay between injecting the message fragments. The good news is this is a well understood problem with very standard solutions. The cheap quick fix is to make otrl_proto_fragment_accumulate() tell the other end that the message was messed up, and request a retransmission. Currently otrl_proto_fragment_accumulate() just silently fails. This simple fix will fail horribly when messages become large compared to the MSS. The 'right' fix seems to me to be, as much as I hate the suggestion, something much fancier. Something along the lines of TCP's windowing, ACK, and retransmission algorithm. Yuck. (GreenLife is to Second Life as Pidgin is to Yahoo; OTR is to GreenLife as OTR is to Pidgin.) > - Ian Chris From chris-tuchs at hushmail.com Mon Aug 10 04:47:01 2009 From: chris-tuchs at hushmail.com (chris-tuchs at hushmail.com) Date: Mon, 10 Aug 2009 01:47:01 -0700 Subject: [OTR-dev] OTR, keyservers, MITM, etc. Message-ID: <20090810084701.A7FA1B8044@smtp.hushmail.com> Ok, so first off, I apologize that I, a non-cryptographer, am going to suggest a cryptographic protocol. It probably stinks, and I hope you can help me make it better. In fact I hope you can say, "Oh yeah, they solved that problem already, go read Crypto 04 pages xxx-yyy." I would very much prefer to throw away my proposal and use something that's had some real review by qualified cryptographers. The Problem: In Second Life it is not uncommon to meet someone for the first time and want to IM with them. I am not as familiar with other IM systems, but I can imagine it could happen that two people meet on some other IM system. Since there is no shared history neither of the SMP based authentication systems seem useful when given a cursory glance. But we still want to eliminate the possibility of a man in the middle, or in fact any third party to the conversation. Manual fingerprint verification seems the only solution. The real world user: But my experience with Second Life users of OTR is that of the few who understand what is expected of them most aren't willing to actually do the work. Instead of exchanging key fingerprints, most users will just mark their buddy authenticated to make the warning go away. In actuality, in Second Life, even the question "What color shirt am I wearing" can be used with SMP to eliminate most automated man-in-the-middle (MITM) attacks. On other IM systems even the laughable "How many letters are in the word 'four'?" has some value for eliminating automated MITM. One obvious solution is to use the pgp keyservers along with some trust computation. After all, DSA is DSA and there is no reason we couldn't settle on a canonical notation for usernames and IM systems. Then it is just a small matter of writing some code to get OTR keys and signatures into a format that the PGP keyservers will be happy with. But... Remember the user I am dealing with. They aren't likely to take the time to do a SMP based authentication in the first place. So even if I cleverly put in stuff to generate and post signatures the quality of the signatures will be very low. I discussed this with another GreenLife developer and we cooked up this protocol to lower the probability of undetected MITM attacks. I would like feedback about this proposal. As you will see there is nothing specific to Second Life in the proposal and it could be added to all OTR implementations. It essentially automatically does fingerprint verification over multiple untrusted communication channels. I use the word "keyserver" below, but I would prefer a better term. Feel free to sugest one. The Proposal: Imagine a small set of, untrusted, OTR keyservers. When Alice establishes an unverified conversation with Bob on protocol P her software picks a random number R, then posts to the keyservers a message consisting of where name-hash is HASH(Alice-user-name | P-protocol-name | Bob-user-name); key-hash is HASH(Alice-key-fingerprint | Bob-key-fingerprint); random-number is a nonce with no special meaning; and | means the concatenation of utf8 encoded character strings. I assume there are canonical user names, and a canonical order to the names. The first name given to HASH is the earlier in the sort order. For example, "Alice Avatar" comes before "Bob Avatar" so HASH("Alice Avatar" | "SecondLife" | "Bob Avatar") would be used by both Alice and Bob. The same order is used for the key fingerprints. In this case HASH(Alice-key-fingerprint | Bob-key-fingerprint). In response to a message of the form a keyserver replies with all the messages posted recently that have N' == N. If Alice's software finds that her post is present, all the key hashes match the one her software computed, and at least one other post is present, then the odds of a MITM attack are lowered. The man in the middle attacker would have to be between Alice and Bob as well as between Alice and all the keyservers. (I will consider a keyserver controlled by an attacker to be the same as an attacker between a user and the keyserver.) With a few independently operated keyservers this becomes impractical. Naturally Alice's software may beat Bob's to the keyserver, so not finding a post from Bob just means Alice's software has to post again after a short pause. And since there are actually three parties to this protocol, including the man in the middle, Alice's software would do well to check back even if everything looks good on the first check. I have a few concerns about the proposal. It can confirm that Alice had a conversation with Bob, though presumably this information can be found in the logs of the IM system's servers. Either Alice or Bob can collude with a keyserver to reveal the IP address used by the other to post, though using an http proxy should help mitigate this privacy threat. It is open to the obvious denial of service attack of posting messages with valid name-hashes and multiple different values in the place of key-hashes. Most importantly, I am not a 'real cryptographer' and am not really competent to create and analyze protocols. I am sure a real cryptographer can generate a better proposal which takes advantage of multiple untrusted communication channels. Never the less, I feel compelled to do something to help protect the users in Second Life from their ignorance and apathy. Chris Post scripts: I can make DOS harder by including time in name-hash, and forcing some property of the posts such as r === HASH(r | k | n) mod 256. This just makes it expensive to compute false entries, though still reasonably fast to check if an entry 'paid the computational tax.' This would prevent 'blanket' DOS but not a pinpoint DOS on a particular pair of OTR users. I considered a number of other things to post to the keyservers, and turned them down. This is an abbreviated list. I considered the pgp keyserver and trust computation, but rejected it since I don't think our users will invest the time and effort to properly use and understand such a system. If Alice posts , the keyservers can build lists of . The keyservers can build lists of who likely talked to whom since Alice's query must return Bob's post of . DOS attacks would wipe out one user's ability to use the system rather than just blocking one pair from communicating. If Alice posts , the keyservers can still build weak lists of who talked to whom since Alice's post includes Bob's name and her query must return his post of her key. DOS attacks would wipe out one user's ability to use the system. If Alice posts or the servers just have longer identifiers to use when building lists of who talks to whom, and which IP goes with which person. If Alice posts , Alice will be unable to see if Bob is posting or not. For the protocol to work, at least two parties must be posting under the same name-hash at about the same time. If Alice's post include a signature of anything, the servers can build even stronger evidence of who talks to whom and/or who uses which IP. Philosophy -- is it MITM or not? If the owner of the IM system wanted to pretend to be Bob and communicate with Alice, and if Bob were not trying to communicate with Alice at the time, using this protocol Alice could only determine that there is no third party to the conversation. Since Alice has no way of distinguishing Bob from any other person, she has no way to detect that "Bob" is an imposter. This isn't actually a problem with the MITM detection; it is inherent in meeting a new person, you don't know who they are. Later if Alice did talk to the real Bob she would detect that Bob's key had changed or that there was a MITM attack underway. From chris-tuchs at hushmail.com Mon Aug 10 20:52:43 2009 From: chris-tuchs at hushmail.com (chris-tuchs at hushmail.com) Date: Mon, 10 Aug 2009 17:52:43 -0700 Subject: [OTR-dev] OTR, keyservers, MITM, etc. Message-ID: <20090811005243.B5A24B0048@smtp.hushmail.com> Naturally after posting I see ways to improve the protocol. I want to limit the DOS problem to only those who know Alice and Bob are trying to use OTR on protocol P. So I change the definition to Where N is HASH1(user1-name | protocol | user2-name); E is an encryption of HASH2(key1-fingerprint | key2-fingerprint) under a key determined by HASH3(user-name1 | protocol | user-name2); M is a HMAC of E using key determined by HASH4(user-name1 | protocol | user-name2) and a hashing function HASH5; R is a nonce as before. HASH1, HASH2, HASH3, HASH4, and HASH5 are hashing functions derived from a suitable function such as SHA256. This allows Alice, Bob, and the hypothetical MITM to test if a post has a valid HMAC for E and that E is the encryption of the hash of the key fingerprints. Since no information about the HMAC key is revealed in N, eavesdroppers who can only see traffic to the keyservers are unlikely to be able to generate well formed posts in a timely enough manner to deny service to Alice and Bob. A little bit more concrete design details: HASHT(x) = High 180 bits of SHA256(x) HASHK(x) = High 128 bits of SHA256(x) HASH1(x) = HASHT("User names" | x | "HASH1") HASH2(x) = HASHT("Fingerprints" | x | "HASH2") HASH3(x) = HASHK("Encryption key" | x | "HASH3") HASH4(x) = HASHK("HMAC key" | x | "HASH4") HASH5(x) = SHA256(x) HMAC(k,x) = High 180 bits of HMAC-SHA256(k,x) E(k,x) = AES in counter mode with 128 bit key K, initial count 0 R = a 24 bit number The keyservers are http servers which respond to urls like http://host.tld/otrkey?v1&N=&E=&M=&R= with lines like N=&E=&M=&R= N=&E=&M=&R= N=&E=&M=&R= Where is a URL safe variant of a base 64 encoded number. And it's the reason I picked 168 bits and 24 bits above since they are evenly divisible by 24, which is the base 64 "blocksize", and thus eliminates the need for any padding algorithm. Chris Postscript: Please tell me someone has already done this better, let me use their protocol. From chris-tuchs at hushmail.com Wed Aug 12 05:16:54 2009 From: chris-tuchs at hushmail.com (chris-tuchs at hushmail.com) Date: Wed, 12 Aug 2009 02:16:54 -0700 Subject: [OTR-dev] OTR, keyservers, MITM, etc. Message-ID: <20090812091654.3F17BB004B@smtp.hushmail.com> Here's version 3. I added time to the name hash to increase the work required to build a log of who talks to whom. I added R as part of the key used to encrypt E. This prevents a kind of replay attack. In particular, if is a valid post, then is very unlikely to be a valid post unless R' == R. In response to a message like , a keyserver responds with all the messages it received in the last 256 seconds where N' == N. Where N = HASH1(npnt) R = a 24 bit nonce chosen at random E = AESC(HASH3(npnt | R), HASH2(kfp)) M = HMAC(HASH4(npnt), E) npnt = user1-name | protocol-name | user2-name | time kfp = key1-fingerprint | key2-fingerprint fingerprints are human readable utf8 strings produced by otrl_privkey_hash_to_human() time = number of seconds since 1970 UTC right shifted 7 bits expressed as a utf8 encoded string, i.e. "123" not 0x7b HASH1(x) = TRUNC(168, SHA256("User names" | x | "HASH1")) HASH2(x) = TRUNC(168, SHA256("Fingerprints" | x | "HASH2") HASH3(x) = TRUNC(128, SHA256("Encryption key" | x | "HASH3") HASH4(x) = SHA256("HMAC key" | x | "HASH4") HMAC(k,x) = TRUNC(168, HMAC-SHA256(k, x)) AESC(k,x) = The encryption of x by AES in counter mode with 128 bit key k and initial count 0 TRUNC(L,n) = the L left most bits of n The keyservers are http servers which respond to urls like http://host.tld/otrkey?v=1&N=&E=&M=&R= with lines like N=&E=&M=&R= N=&E=&M=&R= N=&E=&M=&R= Where is a URL safe variant of a base 64 encoded number. And it's the reason I picked 168 bits and 24 bits above since they are evenly divisible by 24, which is the base 64 "blocksize", and thus eliminates the need for any padding algorithm. The N, E, and M values are all 28 characters long, and the R value is 4 characters long. Chris Postscript: Please tell me someone has already done this better, let me use their protocol. From campbell at mumble.net Fri Aug 14 11:53:18 2009 From: campbell at mumble.net (Taylor R Campbell) Date: Fri, 14 Aug 2009 11:53:18 -0400 Subject: [OTR-dev] semantics of MSGSTATE_FINISHED Message-ID: <20090814155318.DEBAE98284@pluto.mumble.net> [I tried sending this a few days ago without subscribing to the list, but it never showed up in the archive, so I imagine I need to be subscribed. If I'm mistaken, apologies for the duplicate message.] When an OTR user receives a DISCONNECTED TLV, his message state transitions to MSGSTATE_FINISHED. Afterward, otrl_message_sending will always succeed in the sense of returning an error code indicating success, but will display a message saying `Your message was not sent. Either end your private conversation, or restart it.' This causes frustration such as what is documented in Adium ticket 6600, at . I'd like to fix this. I think that one way would be simply to omit MSGSTATE_FINISHED and to substitute MSGSTATE_PLAINTEXT for it. Then if the user wanted every message to be encrypted, and requested OTRL_POLICY_REQUIRE_ENCRYPTION, I believe that otrl_message_sending would do the right thing after a DISCONNECTED TLV and negotiate a new OTR session. Also, the notice that has frustrated me and others could be done away with. But that might surprise users who use different policies. If the user doesn't care that every message be encrypted, but would not want a DISCONNECTED TLV to cause subsequent messages to be sent in plaintext, then another way would be to apply in MSGSTATE_FINISHED the same logic in MSGSTATE_PLAINTEXT for OTRL_POLICY_REQUIRE_ENCRYPTION. The user would still be notified that the message could not be sent as it was, but the OTR library would attempt to negotiate a new OTR session, and if that failed (e.g., because the other user actually did simply go offline), then the user would be notified of the reason why the software really could not transmit the message to the other user. At the very least, it would be nice if otrl_message_sending returned an error code indicating failure whenever it failed to send a message, such as when in the MSGSTATE_FINISHED state. Right now, clients think that OTR succeeded and proceed as if it had. Adium echoes the message just like any message it has successfully sent, and puts the notice about `Your message was not sent' in a very innocuous place that I often don't see until much later. Nowhere does it indicate any reason why the message was not sent, either -- almost as though it just got lazy and didn't feel like sending the message I asked it to send! Am I missing something about the OTR protocol, or do any of these ideas sound plausible modifications to the protocol to prevent the incredibly frustrating behaviour that it currently causes? Please let me know if you'd like patches -- I have not tested any of these ideas, but I'd be happy to do so and send patches. From chris-tuchs at hushmail.com Sun Aug 16 02:44:00 2009 From: chris-tuchs at hushmail.com (chris-tuchs at hushmail.com) Date: Sat, 15 Aug 2009 23:44:00 -0700 Subject: [OTR-dev] semantics of MSGSTATE_FINISHED Message-ID: <20090816064400.77F4E20042@smtp.hushmail.com> The finished state also causes a lot of complaints in the Second Life user base. However I just point out this scenario, and they grudgingly get quiet. Alice and Bob are in private conversation Alice is typing quickly because she knows Bob is about to leave Alice types her CC# and Social security number Bob ends private conversation Alice hits enter I don't think Alice would be happy if her message got sent un-encrypted. I don't think Alice would be happy if her message was lost. The current behavior of GreenLife is to leave the message in the text entry box, but not to send it. Instead Alice sees this message: [23:22] BobOTR Emerald has ended the private conversation, so your message was not sent. You should restart the private conversation, or end the private conversation. I had to write code specially to catch and handle that case. Note I don't even call into libotr if I detect that the conversation is in the finished state: bool was_finished = false; if (gOTR && context && (context->msgstate == OTRL_MSGSTATE_FINISHED)) { was_finished = true; } else if (gOTR && (IM_NOTHING_SPECIAL == mDialog)) { // only try OTR for 1 on 1 IM's err = otrl_message_sending( gOTR->get_userstate(), gOTR->get_uistate(), &mSessionUUID, my_uuid, gOTR->get_protocolid(), their_uuid, &(utf8_text[0]), NULL, &newmessage, NULL, NULL); } context = getOtrContext(); if (err) { otrLogMessageGetstring("otr_err_failed_sending"); return; // leave the unsent message in the edit box } if (was_finished) { otrLogMessageGetstringName("otr_err_send_in_finished"); return; // leave the unsent message in the edit box } The best suggestion for an alternate behavior I have seen is that Alice's OTR client should automatically try to restart the private conversation, and then send the message. I have decided not to implement this behavior because Bob may have a good reason to end the conversation. Perhaps people, with whom he doesn't wish to share his private conversation, had just arrived at his location. Chris From chris-tuchs at hushmail.com Sun Aug 16 03:20:30 2009 From: chris-tuchs at hushmail.com (chris-tuchs at hushmail.com) Date: Sun, 16 Aug 2009 00:20:30 -0700 Subject: [OTR-dev] AES Key and DH group sizes Message-ID: <20090816072030.A7590B8040@smtp.hushmail.com> Recently I've been seeing recommendations to avoid AES-128, and DH group #5. Will the next release of libotr be using aes256 and/or a larger DH group? I have seen #14 from http://www.faqs.org/rfcs/rfc3526.html recommended. Chris From Werner.Dittmann at t-online.de Sun Aug 16 11:07:59 2009 From: Werner.Dittmann at t-online.de (Werner Dittmann) Date: Sun, 16 Aug 2009 17:07:59 +0200 Subject: [OTR-dev] AES Key and DH group sizes In-Reply-To: <20090816072030.A7590B8040@smtp.hushmail.com> References: <20090816072030.A7590B8040@smtp.hushmail.com> Message-ID: <4A8820CF.5020402@t-online.de> Hmm, why this. Just recently I read some info on Bruce Schneiers blog that AES-256 has a poor key distribution. AES-128 is good enough for all practical reasons. Regards, Werner chris-tuchs at hushmail.com schrieb: > Recently I've been seeing recommendations to avoid AES-128, and DH > group #5. Will the next release of libotr be using aes256 and/or a > larger DH group? I have seen #14 from > http://www.faqs.org/rfcs/rfc3526.html recommended. > > Chris > > _______________________________________________ > OTR-dev mailing list > OTR-dev at lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > From Werner.Dittmann at t-online.de Sun Aug 16 11:42:52 2009 From: Werner.Dittmann at t-online.de (Werner Dittmann) Date: Sun, 16 Aug 2009 17:42:52 +0200 Subject: [OTR-dev] AES Key and DH group sizes In-Reply-To: <4A8820CF.5020402@t-online.de> References: <20090816072030.A7590B8040@smtp.hushmail.com> <4A8820CF.5020402@t-online.de> Message-ID: <4A8828FC.10602@t-online.de> Forgot the link to the blog: Werner Werner Dittmann schrieb: > Hmm, why this. Just recently I read some info on Bruce Schneiers > blog that AES-256 has a poor key distribution. AES-128 is good > enough for all practical reasons. > > Regards, > Werner > > chris-tuchs at hushmail.com schrieb: >> Recently I've been seeing recommendations to avoid AES-128, and DH >> group #5. Will the next release of libotr be using aes256 and/or a >> larger DH group? I have seen #14 from >> http://www.faqs.org/rfcs/rfc3526.html recommended. >> >> Chris >> >> _______________________________________________ >> OTR-dev mailing list >> OTR-dev at lists.cypherpunks.ca >> http://lists.cypherpunks.ca/mailman/listinfo/otr-dev >> > > _______________________________________________ > OTR-dev mailing list > OTR-dev at lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > From govnototalitarizm at gmail.com Sun Aug 16 12:54:17 2009 From: govnototalitarizm at gmail.com (M) Date: Sun, 16 Aug 2009 18:54:17 +0200 Subject: [OTR-dev] AES Key and DH group sizes In-Reply-To: <4A8820CF.5020402@t-online.de> References: <20090816072030.A7590B8040@smtp.hushmail.com> <4A8820CF.5020402@t-online.de> Message-ID: <4A8839B9.10905@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Werner Dittmann ?????: > Hmm, why this. Just recently I read some info on Bruce Schneiers > blog that AES-256 has a poor key distribution. AES-128 is good > enough for all practical reasons. I'm not the person behind these decision but I guess it's because standard-compliant version of AES-256 (14 rounds) still looks more secure than AES-128. Thank you for interesting link anyway, Max. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqIObkACgkQe1oVzc159G+GdACfS+g0A2zf9MeyOIul3bvSleiR f00AmgPWfUMElMKjILRxpS+FJBwX6fk/ =p4Qz -----END PGP SIGNATURE----- From ian at cypherpunks.ca Mon Aug 17 10:58:58 2009 From: ian at cypherpunks.ca (Ian Goldberg) Date: Mon, 17 Aug 2009 10:58:58 -0400 Subject: [OTR-dev] AES Key and DH group sizes In-Reply-To: <20090816072030.A7590B8040@smtp.hushmail.com> References: <20090816072030.A7590B8040@smtp.hushmail.com> Message-ID: <20090817145858.GJ31407@thunk.cs.uwaterloo.ca> On Sun, Aug 16, 2009 at 12:20:30AM -0700, chris-tuchs at hushmail.com wrote: > Recently I've been seeing recommendations to avoid AES-128, and DH > group #5. Will the next release of libotr be using aes256 and/or a > larger DH group? I have seen #14 from > http://www.faqs.org/rfcs/rfc3526.html recommended. I know of no reason to believe that either AES-128 or DH group 5 should be deprecated at this time. Do you have a pointer to the recommendations you've been seeing? - Ian From chris-tuchs at hushmail.com Tue Aug 18 05:10:25 2009 From: chris-tuchs at hushmail.com (chris-tuchs at hushmail.com) Date: Tue, 18 Aug 2009 02:10:25 -0700 Subject: [OTR-dev] AES Key and DH group sizes Message-ID: <20090818091025.A422120042@smtp.hushmail.com> On Mon, 17 Aug 2009 07:58:58 -0700 Ian Goldberg wrote: >I know of no reason to believe that either AES-128 or DH group >5 should be deprecated at this time. Do you have a pointer to >the recommendations you've been seeing? > > - Ian I repeat my claim: I am no cryptographer. This is the post that prompted me to ask the question. Seems like a semi-credible source to me. http://www.daemonology.net/blog/2009-06-11-cryptographic-right- answers.html Chris From chris-tuchs at hushmail.com Tue Aug 18 06:35:21 2009 From: chris-tuchs at hushmail.com (chris-tuchs at hushmail.com) Date: Tue, 18 Aug 2009 03:35:21 -0700 Subject: [OTR-dev] OTR, keyservers, MITM, etc. Message-ID: <20090818103521.4310DB004C@smtp.hushmail.com> Here's version 4. The basic plan is to use multiple servers as a secondary channel to detect MITM attacks. The kernel of the protocol is just "Alice and Bob post the fingerprints of both their DSA keys to public servers, check that the fingerprints match, and that there are no conflicting claims." In response to a message like , a keyserver responds with all the messages it received in the last 256 seconds where N' == N; and with a signature Where N = HMAC(KDF1(npn), npn) R = a 168 bit nonce chosen at random E = AESC(KDF2(npn, R), HMAC(KDF3(npn, R), kfp)) M = HMAC(KDF4(npn, R), E) npn = user1-name || protocol-name || user2-name where user1-name <= user2-name using a not-yet-specified ordering function. kfp = key1-fingerprint || key2-fingerprint fingerprints are human readable utf8 strings produced by otrl_privkey_hash_to_human() KDF1(x) = KDF(x, salt) KDF2(x,r) = HMAC(r, "Encryption key" || KFD1(x) || "KDF2") KDF3(x,r) = HMAC(r, "Fingerprints" || KFD1(x) || "KDF3") KDF4(x,r) = HMAC(r, "HMAC key" || KFD1(x) || "KDF4") HMAC(k,x) = TRUNC(168, HMAC-SHA256(k, x)) AESC(k,x) = The encryption of x by AES in counter mode with 128? 256? bit key k and initial count 0 TRUNC(L,n) = the L left most bits of n salt = SHA256(time) time = number of seconds since 1970 UTC right shifted 7 bits expressed as a utf8 encoded string, i.e. "123" not 0x7b. 2^7 seconds, 128 seconds, is a little bit more than 2 minutes. KDF(x,salt) = either PBKDF2(SHA256, x, salt, 1000, 64) as defined in http://tools.ietf.org/html/rfc2898 or SCRYPT(???) http://www.tarsnap.com/scrypt/ || = the concatenation of strings. "x" || "y" is "xy". T = time Q = a 168 bit nonce chosen at random S = sign(HMAC(Q || R, posts || T)) posts = all the where N' == N posted to the keyserver in the last 256 seconds. Expressed as URL query strings, one per line. The keyservers are http servers which respond to urls like http://host.tld/otrkey?v=1&N=&R=&E=&M= with lines, reffered to as "posts", like N=&R=&E=&M= N=&R=&E=&M= N=&R=&E=&M= and a final signature line like T=&N=&S= Where is a URL safe variant of a base 64 encoded number. Base 64 encoding is the reason I picked 168 bits; it is evenly divisible by 24, which is the base 64 "blocksize", and thus eliminates the need for any padding algorithm. --- possible changes I am considering replacing E with an encryption of the actual fingerprints or just a hash of them: E = AESC(KDF2(npn, R), kfp) or E = HMAC(KDF3(npn, R), kfp) I am considering specifying that Alice makes some kind of false posts periodically so that posts cannot be used to confirm the existence of an OTR conversation. --- change log / notes Since I use time in the protocol, people who's local computer reports a time very different from the current one will have problems. I will make the keyservers tell what time it is in their response and make an internal adjustment. I changed the hashes to be dependant on a KDF, like PBKDF2 or SCRYPT. This greatly increases the time needed to "reverse" the name hash by trial hashing. I replaced the single hash of the fingerprints with two hashes, the second being a hmac of the first. I think this will make it quick to detect "forgery" posts by agents which don't actually know npn. I made the clients know the public keys of the key servers to help prevent MITM attacks on the user to keyserver channels. I considered using ssl/https instead. I don't like this part of the protocol. I added R as part of the key used to encrypt E. This prevents a kind of replay attack. In particular, if is a valid post, then is very unlikely to be a valid post unless R' == R. Chris Postscript: Please tell me someone has already done this better, let me use their protocol. From gmaxwell at gmail.com Tue Aug 18 07:34:56 2009 From: gmaxwell at gmail.com (Gregory Maxwell) Date: Tue, 18 Aug 2009 07:34:56 -0400 Subject: [OTR-dev] OTR, keyservers, MITM, etc. In-Reply-To: <20090818103521.4310DB004C@smtp.hushmail.com> References: <20090818103521.4310DB004C@smtp.hushmail.com> Message-ID: On Tue, Aug 18, 2009 at 6:35 AM, wrote: > Here's version 4. > > The basic plan is to use multiple servers as a secondary channel > to detect MITM attacks. ?The kernel of the protocol is just > "Alice and Bob post the fingerprints of both their DSA keys to > public servers, check that the fingerprints match, and that > there are no conflicting claims." As you are aware? This process leaks the fact that Alice and Bob are communicating to anyone who can intercept the keyserver's traffic. Today this information may only be available to the IM server operator (esp. consider if the client<->im server link is SSL protected as is common with jabber). Passively traffic analysis is a less serious break but it is also a more common, more easily, and more safely executed attack than MTIM. The use of a separate channel for validation (especially an unsecured one!) is unlikely to foil MTIM, but it is likely to foil proxying, including attempts to run IM via TOR. I don't think that its great to trade one weakness for another. This also appears to be vulnerable to another, partially sociological, type of attack: An attacker unable to perform actual MTIMs against OTR can trigger MTIM warnings, causing users to use different transports. (*) Eve sends spoofed Alice/Bob identifiers to the keyserver (*) Alice and Bob attempt to communicate, using SMP authenticated mtim-resistant OTR, but get a nasty warning message (*) Alice and Bob switch to some other method, perhaps plantext, that eve is more able to monitor. I'm unsure about the threat model. We have Alice, and Bob who are trying to communicate via Isaac. Because Alice and Bob are concerned Isaac may be compromised they consult one or more third parties. The process dose not increase security if the MITM, Mallory, is located close to Alice or Bob and can therefore intercept communications with the third parties. Am I right? Is this really a significant threat model for second life? I think that for the general IM case we're mostly concerned with MITM who can position themselves close to Alice and/or Bob and probably modify more than just their IM traffic. From alex323 at gmail.com Tue Aug 18 10:28:46 2009 From: alex323 at gmail.com (Alex) Date: Tue, 18 Aug 2009 10:28:46 -0400 Subject: [OTR-dev] OTR, keyservers, MITM, etc. In-Reply-To: <20090818103521.4310DB004C@smtp.hushmail.com> References: <20090818103521.4310DB004C@smtp.hushmail.com> Message-ID: <20090818102846.20a968f4@gmail.com> On Tue, 18 Aug 2009 03:35:21 -0700 chris-tuchs at hushmail.com wrote: > Here's version 4. > What if we just had an SSL secured webserver and a site similar to http://keyserver.pgp.com -- Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From donny.viszneki at gmail.com Tue Aug 18 10:56:33 2009 From: donny.viszneki at gmail.com (Donny Viszneki) Date: Tue, 18 Aug 2009 10:56:33 -0400 Subject: [OTR-dev] OTR, keyservers, MITM, etc. In-Reply-To: <20090809222727.GG10974@yoink.cs.uwaterloo.ca> References: <20090806045041.27272B8063@smtp.hushmail.com> <20090809222727.GG10974@yoink.cs.uwaterloo.ca> Message-ID: <44acbb800908180756u213c66c5s8ea9252ee6eec8fa@mail.gmail.com> On Sun, Aug 9, 2009 at 6:27 PM, Ian Goldberg wrote: > The "use GPG keys for OTR" suggestion comes up pretty regularly. ?But > most GPG keys don't have your IM username and network in a canonical > format in them, so you'd have to manually associate the GPG key to the > IM buddy anyway. ?Is that better than manually associating the OTR key? > Is it better than using the Authenticate Buddy mechanism? ?Note that > keyservers don't help you much if at all here. "Manually associate?" We're talking about computers, here. For reasons orthogonal to the greater discussion going on in this thread, it would be nice to have greater interoperability with other authentication mechanisms. For all those reasons, then, for the OTR community to define some document format whereby a PGP key can be used authenticate any kind of statement of authenticity for OTR keys, that would be great. With the definition in place, it would be easy for most OTR plugins to associate a new program with that type of document. That program would probably just show a dialog showing who/whatkey authenticates the OTR key therein, and present an "Install" button that would fiddle with whatever OTR plugin settings are necessary to implement the verification (or anti-verification -- another feature OTR plugins need) of the new user/key combo. -- http://codebad.com/ From ian at cypherpunks.ca Tue Aug 18 11:00:23 2009 From: ian at cypherpunks.ca (Ian Goldberg) Date: Tue, 18 Aug 2009 11:00:23 -0400 Subject: [OTR-dev] AES Key and DH group sizes In-Reply-To: <20090818091025.A422120042@smtp.hushmail.com> References: <20090818091025.A422120042@smtp.hushmail.com> Message-ID: <20090818150023.GD2339@thunk.cs.uwaterloo.ca> On Tue, Aug 18, 2009 at 02:10:25AM -0700, chris-tuchs at hushmail.com wrote: > On Mon, 17 Aug 2009 07:58:58 -0700 Ian Goldberg > wrote: > >I know of no reason to believe that either AES-128 or DH group > >5 should be deprecated at this time. Do you have a pointer to > >the recommendations you've been seeing? > > > > - Ian > > I repeat my claim: I am no cryptographer. This is the post > that prompted me to ask the question. Seems like a > semi-credible source to me. > > http://www.daemonology.net/blog/2009-06-11-cryptographic-right- > answers.html He's being way more conservative than needed, and it comes at a nontrivial cost: the DH that's performed approx. every message in OTR would be ~2x as expensive in group 14. It also turns out (recent result, linked to upthread) that AES-256 has a flaw which makes it weaker than AES-128 in certain circumstances. So I'll be staying away from AES-256 for now, thankyouverymuch. ;-) But in any event, there's no reason to use AES-256. (Pretty much(*)) ever. (*) Mumble quantum mumble, but then you can't use DH to generate the key in the first place. I'm perfectly comfortable with a 128-bit security level for the foreseeable future. - Ian From donny.viszneki at gmail.com Tue Aug 18 11:01:25 2009 From: donny.viszneki at gmail.com (Donny Viszneki) Date: Tue, 18 Aug 2009 11:01:25 -0400 Subject: [OTR-dev] OTR, keyservers, MITM, etc. In-Reply-To: <20090818102846.20a968f4@gmail.com> References: <20090818103521.4310DB004C@smtp.hushmail.com> <20090818102846.20a968f4@gmail.com> Message-ID: <44acbb800908180801v12da4ac9l19dab38368916978@mail.gmail.com> On Tue, Aug 18, 2009 at 7:34 AM, Gregory Maxwell wrote: > On Tue, Aug 18, 2009 at 6:35 AM, wrote: >> The basic plan is to use multiple servers as a secondary channel >> to detect MITM attacks. The kernel of the protocol is just >> "Alice and Bob post the fingerprints of both their DSA keys to >> public servers, check that the fingerprints match, and that >> there are no conflicting claims." > > An attacker unable to perform actual MTIMs against OTR can trigger > MTIM warnings, causing users to use different transports. There would be no "MITM warnings." Without a conflicting claim about OTR keys, there can be no MITM, unless he already has your keys. -- http://codebad.com/ From govnototalitarizm at gmail.com Sun Aug 23 08:58:24 2009 From: govnototalitarizm at gmail.com (M) Date: Sun, 23 Aug 2009 14:58:24 +0200 Subject: [OTR-dev] OTR & pidgin 2.6.1 Message-ID: <4A913CF0.3000308@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello. I tried to compile pidgin-otr with latest pidgin release. Compilation and loading went fine, module seems to be ok, but OTR conversation do not start at all - both automatically and manually. I haven't tried to look into details yet. cheers, Max. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqRPPAACgkQe1oVzc159G9ufACfaRTGLVwUC7Ro16ze4KWwg93e VEAAn0+XLi0mP/ZuqgsKKQUWUBSg6jnl =Gs6U -----END PGP SIGNATURE----- From ian at cypherpunks.ca Mon Aug 24 09:05:20 2009 From: ian at cypherpunks.ca (Ian Goldberg) Date: Mon, 24 Aug 2009 09:05:20 -0400 Subject: [OTR-dev] OTR & pidgin 2.6.1 In-Reply-To: <4A913CF0.3000308@gmail.com> References: <4A913CF0.3000308@gmail.com> Message-ID: <20090824130520.GA7492@thunk.cs.uwaterloo.ca> On Sun, Aug 23, 2009 at 02:58:24PM +0200, M wrote: > I tried to compile pidgin-otr with latest pidgin release. > Compilation and loading went fine, module seems to be ok, but OTR conversation do not > start at all - both automatically and manually. > I haven't tried to look into details yet. So the OTR button and menus show up, but choosing "Start private conversation" does nothing? - Ian From bigfoot at killerhippy.de Wed Aug 26 00:12:19 2009 From: bigfoot at killerhippy.de (=?ISO-8859-1?Q?Sascha_W=FCstemann?=) Date: Wed, 26 Aug 2009 12:12:19 +0800 Subject: [OTR-dev] pidgin v2.6.1 can't load otr plugin Message-ID: <4A94B623.3000602@killerhippy.de> Hi, I have compiled pidgin v2.6.1 from source for puppy v4.2.1, see http://www.puppylinux.org, and the otr plugin does not load. I previously compiled pidgin v2.5.8, libotr v3.2.0 with dependencies nescessary for the puppy environment successfully - there otr plugin was loaded automatically and worked fully functionally. As the otr plugin simply does not load, I copied ibotr.la and libotr.so to /usr/local/lib/pidgin and got this at the pidgin debug window concerning otr: plugins: /usr/local/lib/pidgin/libotr.so is not usable because the 'purple_init_plugin' symbol could not be found. Does the plugin call the PURPLE_INIT_PLUGIN() macro? For pidgin v2.6.1, I use the following configure options: --program-transform-name='s,^i486-t2-linux-gnu-,,' --build=i486-t2-linux-gnu --host=i486-t2-linux-gnu --target=i486-t2-linux-gnu --prefix=/usr/local --localstatedir=/var --disable-screensaver --disable-gtkspell --disable-gstreamer --disable-meanwhile --disable-avahi --disable-fortify --disable-dbus --disable-nm --enable-gnutls=no --enable-nss=yes --with-nspr-includes=/opt/mozilla.org/include/firefox-2.0.0.7/nspr --with-nspr-libs=/usr/lib/seamonkey --with-nss-includes=/opt/mozilla.org/include/firefox-2.0.0.7/nss --with-nss-libs=/usr/lib/seamonkey --with-dynamic-prpls=gg,qq,irc,jabber,msn,myspace,oscar,sametime,simple,yahoo --disable-consoleui --disable-gestures --disable-schemas-install --disable-tcl --disable-tk --disable-nls --disable-doxygen --disable-dot --disable-devhelp --disable-idn For libotr v3.2.0, I use these configure options: --program-transform-name='s,^i486-t2-linux-gnu-,,' --build=i486-t2-linux-gnu --host=i486-t2-linux-gnu --target=i486-t2-linux-gnu --prefix=/usr/local --with-gnu-ld (the same as for compiling for pidgin v2.5.8) Do you see any chances to help me investigating the source of the problem, why the otr plugin cannot be loaded at pidgin v2.6.1? Greetings from Braunschweig, Germany Sascha W?stemann From ian at cypherpunks.ca Wed Aug 26 08:54:54 2009 From: ian at cypherpunks.ca (Ian Goldberg) Date: Wed, 26 Aug 2009 08:54:54 -0400 Subject: [OTR-dev] pidgin v2.6.1 can't load otr plugin In-Reply-To: <4A94B623.3000602@killerhippy.de> References: <4A94B623.3000602@killerhippy.de> Message-ID: <20090826125454.GF8835@yoink.cs.uwaterloo.ca> On Wed, Aug 26, 2009 at 12:12:19PM +0800, Sascha W?stemann wrote: > Hi, > > I have compiled pidgin v2.6.1 from source for puppy v4.2.1, see > http://www.puppylinux.org, and the otr plugin does not load. > I previously compiled pidgin v2.5.8, libotr v3.2.0 with dependencies > nescessary for the puppy environment successfully - there otr plugin was > loaded automatically and worked fully functionally. > > As the otr plugin simply does not load, I copied ibotr.la and libotr.so > to /usr/local/lib/pidgin and got this at the pidgin debug window > concerning otr: That's weird; govnototalitarizm recently reported that the plugin loads, and the OTR button/menus show up, but clicking "Start private conversation" doesn't actually start one. It looks like the API for 2.6.1 changed in a non-backwards-compatible way to 2.{0,2,4}.x, which it's not supposed to do (they're supposed to change to 3.0.0 if a non-backwards-compatible API change is made). With classes just around the corner (and me travelling at the moment), I unfortunately won't personally have a chance to look at this for several weeks. Can someone else take a look? Thanks, - Ian