From damokles at ubuntu.com Fri Sep 12 07:55:30 2008 From: damokles at ubuntu.com (Caspar C. Mierau) Date: Fri, 12 Sep 2008 13:55:30 +0200 Subject: [OTR-dev] pidgin-otr uses old gaim icons Message-ID: <20080912115530.GB6865@lilith.spinnenwerk.de> Hi, a user reported on the Ubuntu launchpad tracker, that pidgin-otr still uses gaim icons. This should actually be counted as a bug as gaim had to be renamed to pidgin due to legal brand/copyright issues, as you might know, and the icon looks like an aim icon. See http://launchpadlibrarian.net/9289438/pidgin-otr-gaim-icon.png for the icon and https://bugs.launchpad.net/ubuntu/+source/pidgin-otr/+bug/139811 for the ticket. Could somebody replace the icon with a pidgin-styled one? Thanks in advance, ccm. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From ian at cypherpunks.ca Fri Sep 12 09:31:28 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Fri, 12 Sep 2008 09:31:28 -0400 Subject: [OTR-dev] pidgin-otr uses old gaim icons In-Reply-To: <20080912115530.GB6865@lilith.spinnenwerk.de> References: <20080912115530.GB6865@lilith.spinnenwerk.de> Message-ID: <20080912133128.GH31140@thunk.cs.uwaterloo.ca> On Fri, Sep 12, 2008 at 01:55:30PM +0200, Caspar C. Mierau wrote: > Hi, > > a user reported on the Ubuntu launchpad tracker, that pidgin-otr still > uses gaim icons. This should actually be counted as a bug as gaim had > to be renamed to pidgin due to legal brand/copyright issues, as you > might know, and the icon looks like an aim icon. > > See > > http://launchpadlibrarian.net/9289438/pidgin-otr-gaim-icon.png > > for the icon and > > https://bugs.launchpad.net/ubuntu/+source/pidgin-otr/+bug/139811 > > for the ticket. > > Could somebody replace the icon with a pidgin-styled one? This was fixed in 3.2.0, which is already in Ubuntu (intrepid). - Ian From marti at juffo.org Fri Sep 12 12:28:24 2008 From: marti at juffo.org (Marti Raudsepp) Date: Fri, 12 Sep 2008 19:28:24 +0300 Subject: [OTR-dev] Bug in libotr-3.1 / 3.2: no herthbeat message is send In-Reply-To: <20080725163212.17730@gmx.net> References: <20080725163212.17730@gmx.net> Message-ID: <54b33ccd0809120928nb0a04fdv2aec322fd0b76b55@mail.gmail.com> Bump. Still no official response from OTR developers? On Fri, Jul 25, 2008 at 7:32 PM, Georg Sievers wrote: > Hallo, > > my name is Georg Sievers and I' m just working on a diploma thesis at the university of applied sciences TFH, Berlin, Germany, which deals with possible usecases for OTR/libotr beyond Instant Messaging. > > I belive I found a remarkable bug in libotr. > In message.c, funktion "otrl_message_receiving" the field "edata.ignore_message" is initialised with "-1" (Line 747, libotr-3.2). > > In Line 1088 a check for "edata.ignore_message == 0" is performed, which will always evaluate to false, preventing the following hearthbeat-sending code from beeing executed. So no heartbeat messages are ever send. > A quick fix should be changing "edata.ignore_message == 0" to "edata.ignore_message != 1" (line 1088). > Wathsoever, I don't feel to comfortable with having "ignore_message" set to an initale state "-1" at all. As far as I understood the code, their doesn't seem to be a good reason for having a three-state flag at this point. > > I could offer to deliver a patch for this issue but first wanted to ask if there is some reason I have missed for doing it the way it is done. > > > - Georg Sievers From ian at cypherpunks.ca Fri Sep 12 13:57:57 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Fri, 12 Sep 2008 13:57:57 -0400 Subject: [OTR-dev] Bug in libotr-3.1 / 3.2: no herthbeat message is send In-Reply-To: <54b33ccd0809120928nb0a04fdv2aec322fd0b76b55@mail.gmail.com> References: <20080725163212.17730@gmx.net> <54b33ccd0809120928nb0a04fdv2aec322fd0b76b55@mail.gmail.com> Message-ID: <20080912175757.GW31140@thunk.cs.uwaterloo.ca> On Fri, Sep 12, 2008 at 07:28:24PM +0300, Marti Raudsepp wrote: > Bump. Still no official response from OTR developers? Oops; sorry about that. This message got lost in the shuffle. > On Fri, Jul 25, 2008 at 7:32 PM, Georg Sievers wrote: > > Hallo, > > > > my name is Georg Sievers and I' m just working on a diploma thesis > > at the university of applied sciences TFH, Berlin, Germany, which > > deals with possible usecases for OTR/libotr beyond Instant > > Messaging. > > > > I belive I found a remarkable bug in libotr. In message.c, funktion > > "otrl_message_receiving" the field "edata.ignore_message" is > > initialised with "-1" (Line 747, libotr-3.2). > > > > In Line 1088 a check for "edata.ignore_message == 0" is performed, > > which will always evaluate to false, preventing the following > > hearthbeat-sending code from beeing executed. So no heartbeat > > messages are ever send. A quick fix should be changing > > "edata.ignore_message == 0" to "edata.ignore_message != 1" (line > > 1088). Hmm. It looks like you're right; that seems like a reasonable fix. > > Wathsoever, I don't feel to comfortable with having > > "ignore_message" set to an initale state "-1" at all. As far as I > > understood the code, their doesn't seem to be a good reason for > > having a three-state flag at this point. The three states are "Definitely ignore", "definitely don't ignore", and "I haven't decided what to do yet". > > I could offer to deliver a patch for this issue but first wanted to > > ask if there is some reason I have missed for doing it the way it is > > done. Do you think the patch is more than changing "== 0" to "!= 1"? - Ian From evan.s at dreskin.net Fri Sep 12 14:35:22 2008 From: evan.s at dreskin.net (Evan Schoenberg) Date: Fri, 12 Sep 2008 14:35:22 -0400 Subject: [OTR-dev] Bug in libotr-3.1 / 3.2: no herthbeat message is send In-Reply-To: <20080912175757.GW31140@thunk.cs.uwaterloo.ca> References: <20080725163212.17730@gmx.net> <54b33ccd0809120928nb0a04fdv2aec322fd0b76b55@mail.gmail.com> <20080912175757.GW31140@thunk.cs.uwaterloo.ca> Message-ID: On Sep 12, 2008, at 1:57 PM, Ian Goldberg wrote: > On Fri, Sep 12, 2008 at 07:28:24PM +0300, Marti Raudsepp wrote: >> Bump. Still no official response from OTR developers? > > Oops; sorry about that. This message got lost in the shuffle. > >> On Fri, Jul 25, 2008 at 7:32 PM, Georg Sievers >> wrote: >>> Hallo, >>> >>> my name is Georg Sievers and I' m just working on a diploma thesis >>> at the university of applied sciences TFH, Berlin, Germany, which >>> deals with possible usecases for OTR/libotr beyond Instant >>> Messaging. >>> >>> I belive I found a remarkable bug in libotr. In message.c, funktion >>> "otrl_message_receiving" the field "edata.ignore_message" is >>> initialised with "-1" (Line 747, libotr-3.2). >>> >>> In Line 1088 a check for "edata.ignore_message == 0" is performed, >>> which will always evaluate to false, preventing the following >>> hearthbeat-sending code from beeing executed. So no heartbeat >>> messages are ever send. A quick fix should be changing >>> "edata.ignore_message == 0" to "edata.ignore_message != 1" (line >>> 1088). > > Hmm. It looks like you're right; that seems like a reasonable fix. > >>> Wathsoever, I don't feel to comfortable with having >>> "ignore_message" set to an initale state "-1" at all. As far as I >>> understood the code, their doesn't seem to be a good reason for >>> having a three-state flag at this point. > > The three states are "Definitely ignore", "definitely don't ignore", > and > "I haven't decided what to do yet". > >>> I could offer to deliver a patch for this issue but first wanted to >>> ask if there is some reason I have missed for doing it the way it is >>> done. > > Do you think the patch is more than changing "== 0" to "!= 1"? I think it should also change the magic numbers to values from a new enum to make their meaning clear in the future :) -Evan > > > - Ian > _______________________________________________ > OTR-dev mailing list > OTR-dev at lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > From otr at synx.us.to Wed Sep 17 01:44:09 2008 From: otr at synx.us.to (otr at synx.us.to) Date: Tue, 16 Sep 2008 22:44:09 -0700 Subject: [OTR-dev] Separate Fingerprint For Each Account? Message-ID: <48D09929.9050808@synx.us.to> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Is there any way to use just one fingerprint, and authentication key, for more than one instant messaging account? I understand the current implementation makes a separate fingerprint for each account, but my question is if it's possible to do otherwise? Or is there some essential function to having a separate key for separate accounts? It seems to me that the channel by which the messages are exchanged does not matter, as long as the authentication proceeds as expected. If I have fingerprint "XXXXX" it would not matter whether I came from "synx" or "synx001" on AIM, or even "synx at jabber.org" or some other jabber account. Perhaps a given conversation should be restricted to one channel instead of multiplexed across many accounts (sounds like a coding nightmare, and not necessary), but the same fingerprint, couldn't it show up for many different accounts? That way if I contacted someone via AIM, I would not have to re-verify my identity if contacting them via jabber or YIM, or from another AIM account. Sure it's trivial to send a message along the old channel saying "Hey this new fingerprint is me too" but that requires a lot of manual fiddling to get it to work. Additionally if my old account was destroyed without warning, say for instance my chosen jabber server closed up shop, then I would not be able to send a message along the old channel, so would have to rely on flimsy methods like calling someone on the telephone to verify my identity, all over again. If I had the same fingerprint for many accounts, the problem would never even come up, assuming I was already verified. I can see the value of having more than one authentication key: so you can have several different identities, but I cannot see the utility of requiring a separate key for each account. Even more so, I cannot see why it is necessary to have a separate key for each account, besides the fact that the current implemenation uses some kind of lookup table matching "account -> key". It could as easily be "identity -> key" where "identity" is shared between some, or all physical channels and accounts. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjQmSkACgkQB/meY5RuPPRCcACgsHx2MtieeHiPyE30IixEPF0P LDgAmwYzm7ku7IHxFBtjTOPG6FCo/QrH =it1K -----END PGP SIGNATURE----- From ian at cypherpunks.ca Wed Sep 17 08:41:03 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Wed, 17 Sep 2008 08:41:03 -0400 Subject: [OTR-dev] Separate Fingerprint For Each Account? In-Reply-To: <48D09929.9050808@synx.us.to> References: <48D09929.9050808@synx.us.to> Message-ID: <20080917124103.GD15981@thunk.cs.uwaterloo.ca> On Tue, Sep 16, 2008 at 10:44:09PM -0700, otr at synx.us.to wrote: > I can see the value of having more than one authentication key: so you > can have several different identities, This is in fact the original motivation. > but I cannot see the utility of > requiring a separate key for each account. Even more so, I cannot see > why it is necessary to have a separate key for each account, besides the > fact that the current implemenation uses some kind of lookup table > matching "account -> key". It could as easily be "identity -> key" where > "identity" is shared between some, or all physical channels and accounts. The problem is that there's no notion of "identity" that can be programatically checked. If I've verified that the AIM id "fooman" has a particular key, should OTR (technically, pidgin-otr, Adium, Kopete, Psi, etc.) automatically believe that "fooman at foo.com" on MSN and "fooman at jabber.de" on XMPP can be correctly authenticated with that same key? - Ian From otr at synx.us.to Wed Sep 17 22:45:29 2008 From: otr at synx.us.to (otr at synx.us.to) Date: Wed, 17 Sep 2008 19:45:29 -0700 Subject: [OTR-dev] Separate Fingerprint For Each Account? In-Reply-To: <20080917124103.GD15981@thunk.cs.uwaterloo.ca> References: <48D09929.9050808@synx.us.to> <20080917124103.GD15981@thunk.cs.uwaterloo.ca> Message-ID: <48D1C0C9.3020407@synx.us.to> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ian Goldberg wrote: > If I've verified that the AIM id "fooman" has > a particular key, should OTR (technically, pidgin-otr, Adium, Kopete, > Psi, etc.) automatically believe that "fooman at foo.com" on MSN > and "fooman at jabber.de" on XMPP can be correctly authenticated with > that same key? Assuming an attacker with fooman at jabber.de on XMPP is trying to impersonate "fooman" on AIM, but does not have the key that "fooman" on AIM has, how could he possibly produce the same OTR fingerprint, even if it's from an account that the real fooman does not control? It's my opinion that identity should start from within the encryption, and what account you log into outside of that is not something that can be automatically trusted. Making a distinction based on which account you log in where does not add to your security or verifiability, but it does add complexity that the user has to manually fiddle with, instead of clear transparent usability. As an example, consider if fooman was allowed to use the same key for both "fooman" on AIM, and fooman at jabber.de. The OTR plugin could simply realize that both accounts were encrypted and authenticated using the same key, and if the first is a validated key, then the second will be validated too, even though it came from a different destination. Assuming fooman's key isn't stolen, there's no way for an attacker to impersonate fooman no matter what account he comes from. With the current system you can do the same thing, but it's much more complicated. If you had a verified session with "fooman" on AIM, and you had an unverified session with fooman at jabber.de, if "fooman" on AIM typed a message saying "My fingerprint on fooman at jabber.de is 'abcdefg'", and fooman at jabber.de's fingerprint was "abcdefg", then you could safely mark fooman at jabber.de as a verified fingerprint, without fooman having to speak to you over the telephone. "fooman" on AIM is verified and in the private state, so you can trust anything he says wasn't an injection or impersonation, even if what he says is to validate a second account. Doing that requires that fooman has to eyeball his own fingerprint, likely type it in character by character, and also fooman has to manually remember which fingerprint goes with which account, in order to tell you which fingerprint to trust. It requires you to pull up OTR's authenticate fingerprint thingy, to manually eyeball the fingerprint fooman typed at you comparing it with the real fingerprint of goodfooman at jabber.de, then you have to select the statement that you have verified the fingerprint, and ignore the messages suggesting you telephone fooman. If you complete this lengthy set of steps, you can verify a second key based on the conversation of an already verified key, with no extra unsecure out of band communication needed. But if you could use the same key, then all that manual twiddling wouldn't be necessary, and in fact it might be safer since there wouldn't be an opportunity for human error, such as if the fingerprints differed by one character and your eyeball missed catching that. And one more benefit to sharing a key between two accounts, if AOL decides that fooman is banned from AIM due to his use of "terrorist weapons" like OTR, then fooman cannot establish any more verified sessions using "fooman" at AIM. You just have to trust him at his word at this point if he has a different fingerprint for his new account on fooman at jabber.de. Or call him on the telephone, if you feel for some reason that the person who answers won't be a middle man spy either. Assuming he trusts you enough to give you his telephone number which can be used by corporate background check databases to retrieve most of his identity and personal history. I've found when a jabber server dies, the users have the difficult problem of getting people to trust their new accounts, since they can't verify their new accounts via messages from the old one. But with keys not tied to server accounts, you could change your account pretty seamlessly, with no risk of identity theft at all along the way, just by using the same key for the new account. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjRwMgACgkQB/meY5RuPPS5LwCfVEkIn+L/r3MtVB7BYWb7bQjx RcQAnjxqk88GCqqI/u/nqrLz5aCSQEaW =csid -----END PGP SIGNATURE----- From ian at cypherpunks.ca Thu Sep 18 10:37:13 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Thu, 18 Sep 2008 10:37:13 -0400 Subject: [OTR-dev] Separate Fingerprint For Each Account? In-Reply-To: <48D1C0C9.3020407@synx.us.to> References: <48D09929.9050808@synx.us.to> <20080917124103.GD15981@thunk.cs.uwaterloo.ca> <48D1C0C9.3020407@synx.us.to> Message-ID: <20080918143713.GC5383@thunk.cs.uwaterloo.ca> On Wed, Sep 17, 2008 at 07:45:29PM -0700, otr at synx.us.to wrote: > Ian Goldberg wrote: > > > If I've verified that the AIM id "fooman" has > > a particular key, should OTR (technically, pidgin-otr, Adium, Kopete, > > Psi, etc.) automatically believe that "fooman at foo.com" on MSN > > and "fooman at jabber.de" on XMPP can be correctly authenticated with > > that same key? > > Assuming an attacker with fooman at jabber.de on XMPP is trying to > impersonate "fooman" on AIM, but does not have the key that "fooman" on > AIM has, how could he possibly produce the same OTR fingerprint, even if > it's from an account that the real fooman does not control? If the IM client automatically treats "similar" IM names as the same person, then if you have two friends that happen to have similar IM names, they could impersonate each other. > It's my opinion that identity should start from within the encryption, > and what account you log into outside of that is not something that can > be automatically trusted. Sure, and what you say after that is at least mostly reasonable. But that's not how IM clients treat identity today. Remember that most OTR users have no idea what a key or a fingerprint is. If the user authenticates the buddy "fooman" on AIM, that creates a binding between that fingerprint and the person he knows as "they guy who has the fooman screen name on AIM". If that same key shows up on another account, the IM client has no way to tell the user "although you're talking to fooman at jabber.de, this person is actually the guy who has the fooman screen name on AIM". On the other hand, if you *did* write an IM client with a user-centric notion of identity, I'm pretty sure you could use that identity as the binding for the fingerprint instead of the screen name (with the existing libotr). Not positive, though; it may depend on the details of your implementation. - Ian From otr at synx.us.to Thu Sep 18 16:48:20 2008 From: otr at synx.us.to (otr at synx.us.to) Date: Thu, 18 Sep 2008 13:48:20 -0700 Subject: [OTR-dev] Separate Fingerprint For Each Account? In-Reply-To: <20080918143713.GC5383@thunk.cs.uwaterloo.ca> References: <48D09929.9050808@synx.us.to> <20080917124103.GD15981@thunk.cs.uwaterloo.ca> <48D1C0C9.3020407@synx.us.to> <20080918143713.GC5383@thunk.cs.uwaterloo.ca> Message-ID: <48D2BE94.6000500@synx.us.to> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ian Goldberg wrote: > Sure, and what you say after that is at least mostly reasonable. But > that's not how IM clients treat identity today. Ah, yeah I will grant that there's no way to signify with an IM client that account A and account B are both the same person. You can however, automatically mark account B as verified, if it uses the same key as verified account A. The client will still treat them like different people, but at least OTR won't project dire warnings about it, when none are necessary. Currently however OTR doesn't have any functionality like that. I'd have it so everyone uses a single key by default for all accounts, so that the client would still display two accounts as being different people, but if they were the same person you'd only have to verify one account, and the other would just switch on its own (or display a message "this is the same person, guy" while doing so). > On the other hand, if you *did* write an IM client with a user-centric > notion of identity, I have considered something like that. I kind of got bogged down trying to figure out how to write a protocol plugin in libpurple, that itself used the jabber protocol plugin to operate. I think the "CSpace" project attempts the strategy of a user-centric notion of identity, though I'm pretty sure they don't have perfect forward secrecy. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjSvpQACgkQB/meY5RuPPS0PACfWAZPc6xdLQMBIxLMc6F6l4XN EIoAn1zGWqk45kGfLNaS+HTA9qJyJZjI =+3O0 -----END PGP SIGNATURE----- From ian at cypherpunks.ca Fri Sep 19 10:13:10 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Fri, 19 Sep 2008 10:13:10 -0400 Subject: [OTR-dev] Separate Fingerprint For Each Account? In-Reply-To: <48D2BE94.6000500@synx.us.to> References: <48D09929.9050808@synx.us.to> <20080917124103.GD15981@thunk.cs.uwaterloo.ca> <48D1C0C9.3020407@synx.us.to> <20080918143713.GC5383@thunk.cs.uwaterloo.ca> <48D2BE94.6000500@synx.us.to> Message-ID: <20080919141310.GD25908@thunk.cs.uwaterloo.ca> On Thu, Sep 18, 2008 at 01:48:20PM -0700, otr at synx.us.to wrote: > Ian Goldberg wrote: > > Sure, and what you say after that is at least mostly reasonable. But > > that's not how IM clients treat identity today. > > Ah, yeah I will grant that there's no way to signify with an IM client > that account A and account B are both the same person. You can however, > automatically mark account B as verified, if it uses the same key as > verified account A. That doesn't work. If I'm your buddy, and you've verified my key, I'd be able to impersonate any of your other buddies. > The client will still treat them like different > people, but at least OTR won't project dire warnings about it, when none > are necessary. But they are necessary, if the client has no way to know whether or not account A and account B are *supposed to* be the same person. - Ian From otr at synx.us.to Fri Sep 19 18:17:09 2008 From: otr at synx.us.to (otr at synx.us.to) Date: Fri, 19 Sep 2008 15:17:09 -0700 Subject: [OTR-dev] Separate Fingerprint For Each Account? In-Reply-To: <20080919141310.GD25908@thunk.cs.uwaterloo.ca> References: <48D09929.9050808@synx.us.to> <20080917124103.GD15981@thunk.cs.uwaterloo.ca> <48D1C0C9.3020407@synx.us.to> <20080918143713.GC5383@thunk.cs.uwaterloo.ca> <48D2BE94.6000500@synx.us.to> <20080919141310.GD25908@thunk.cs.uwaterloo.ca> Message-ID: <48D424E5.60700@synx.us.to> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ian Goldberg wrote: > That doesn't work. If I'm your buddy, and you've verified my key, I'd > be able to impersonate any of your other buddies. Not true. If I verified your key, that wouldn't give you any inherent ability to hack into my buddies's instant message accounts. If you did then sure, you could impersonate them, but that's true even without OTR involved. If my buddy himself had his own key, then even if you did hack his account, you could not duplicate his fingerprint. I guess it could be a problem now that I think of it. Nobody's going to be checking fingerprints every time they start a private conversation. But putting in a few simple caveats will prevent this sort of impersonation taking place. Supposing Joe were trying to take over Sam's account. You could: 1) Pop up a dialog when a verified key shows up on a buddy it hasn't shown on already. "This new account Sam is the same person as that old account Joe". Only need to do this the first time such a change occurs of course. Once the user's confirmed that, they have all the info they need to make a decision. 2) Pop up a dialog when a verified key shows up on a buddy that has already had a verified key associated with it, but this time ask them whether they really want to trust that the key from "Joe" now overrides the old key from "Sam" Some combination of those two strategies should be quite enough to warn when someone's account is getting hacked. (2) only would happen if Sam also used OTR and had been verified with you before. Of course if Sam never used OTR, and his account got hacked, there's no way to tell he's not an impostor regardless of the key->account mapping. But if Joe used the same key on Sam's account, even if he was hacking, you could still tell that it was Joe. If Joe used a different key you would be unable to verify it, obviously. I'm not sure if this is a misunderstanding, but I did not mean that there should be one key for all buddy accounts on your buddy list. I mean that we only need one key for all accounts that you control and accounts that you identify as. Of course I want a separate key for each buddy who isn't the same person on a different account. > But they are necessary, if the client has no way to know whether or not > account A and account B are *supposed to* be the same person. If they both can start an OTR session with the same key, with the same fingerprint, then I think the client can conclude pretty confidently that they are the same person. Whether it is supposed to happen or not is an issue for the IM servers who obviously don't want anyone hacking each other's account. But for the client, all they need is to be made aware when someone's identity changes, and the user can judge at that point whether it's kosher or not. How about this then. Suppose with the current system Joe hacks Sam's account, then sends you a message via Joe's account saying "This key on Sam's account is verifiable". If you choose to accept that confirmation from Joe, then Joe is free to use Sam's account verified. If you choose to deny that, then Joe's stuck. It's the same as if with my hypothetical system, Joe used the same key and saying "This key on Sam's account is verifiable". The fact Joe is using the same key for Joe's account and Sam's account does not make it any less of a security concern than if Joe was using a different key for Joe's account and Sam's account. You can confirm and verify that both keys belong to Joe, but it'll still be a hacked account. Thus you have to warn the user, no matter whether Joe's key is verified or not, but only for possibly hacked accounts. Normally you don't have to warn the user at all if the same key is on two accounts, whether Joe's key is verified or not. If Joe uses the same key when hacking Sam's account, he cannot lie about being Joe. The key is the same, so he is easily identified, no matter how convincingly he claims to be Sam. If Joe uses a previously unknown account specific key, he could still use some form of subterfuge or social engineering to trick you into thinking he's verifiable as Sam. There's just no reason in my mind, to require that each account you own has a separate OTR key. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjUJOUACgkQB/meY5RuPPTHtACdFUCtcaVptAgkjlUTX0uWWSRu 6zwAnR+4OMYTYLt3CuJyyRlTlowlUpHP =KOXK -----END PGP SIGNATURE----- From donny.viszneki at gmail.com Fri Sep 19 22:25:53 2008 From: donny.viszneki at gmail.com (Donny Viszneki) Date: Fri, 19 Sep 2008 22:25:53 -0400 Subject: [OTR-dev] Separate Fingerprint For Each Account? In-Reply-To: <48D424E5.60700@synx.us.to> References: <48D09929.9050808@synx.us.to> <20080917124103.GD15981@thunk.cs.uwaterloo.ca> <48D1C0C9.3020407@synx.us.to> <20080918143713.GC5383@thunk.cs.uwaterloo.ca> <48D2BE94.6000500@synx.us.to> <20080919141310.GD25908@thunk.cs.uwaterloo.ca> <48D424E5.60700@synx.us.to> Message-ID: <44acbb800809191925y36ef0145j2daaaca2ed53f71@mail.gmail.com> On Fri, Sep 19, 2008 at 6:17 PM, wrote: > Ian Goldberg wrote: >> That doesn't work. If I'm your buddy, and you've verified my key, I'd >> be able to impersonate any of your other buddies. > > Not true. If I verified your key, that wouldn't give you any inherent > ability to hack into my buddies's instant message accounts. If you did > then sure, you could impersonate them, but that's true even without OTR > involved. If my buddy himself had his own key, then even if you did hack > his account, you could not duplicate his fingerprint. One of the principal purposes of OTR is to protect against the scenario in which an attack can send your IM client forged messenger-service messages that appear to be from another user. By adding end-to-end encryption, OTR prevents this attack from working, whether the attack vector is through your buddy's network connection to the messenger service, your buddy's messenger service account, the messenger service itself, or your connection to the messenger service. Also: What you seem to want mostly out of this is auto-verification of keys where it is applicable. If that's correct, I propose a different solution: the addition of a new OTR plugin message (which need not be part of the core OTR protocol and library, but could belong only to OTR plugins, based on my understanding of how OTR and OTR plugin code is organized) which would allow one OTR plugin to tell another OTR plugin which keys it has "verified." You could even introduce multiple gradations of "verification." The usefulness of this feature would accomplish most of what you want (if I understand correctly that you mostly want automatic, painless verification of multiple accounts belonging to the same user) plus much more. It could provide even greater security and convenience at the same time. I've considered the idea for quite a while, I just haven't had time to write extensively enough about it to make a formal proposal. -- http://codebad.com/ From otr at synx.us.to Sat Sep 20 14:47:46 2008 From: otr at synx.us.to (otr at synx.us.to) Date: Sat, 20 Sep 2008 11:47:46 -0700 Subject: [OTR-dev] Separate Fingerprint For Each Account? In-Reply-To: <44acbb800809191925y36ef0145j2daaaca2ed53f71@mail.gmail.com> References: <48D09929.9050808@synx.us.to> <20080917124103.GD15981@thunk.cs.uwaterloo.ca> <48D1C0C9.3020407@synx.us.to> <20080918143713.GC5383@thunk.cs.uwaterloo.ca> <48D2BE94.6000500@synx.us.to> <20080919141310.GD25908@thunk.cs.uwaterloo.ca> <48D424E5.60700@synx.us.to> <44acbb800809191925y36ef0145j2daaaca2ed53f71@mail.gmail.com> Message-ID: <48D54552.2060404@synx.us.to> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Donny Viszneki wrote: > What you seem to want mostly out of this is auto-verification of keys > where it is applicable. Heh, it does seem like that. The complaint against my idea seems to be that we need to verify each key for each account separately. What I want isn't the applicable auto-verification though, I'm just trying to describe how such auto-verification is a non-problem. Unless I'm wrong of course, in which case I'll quietly go back to the drawing board. What I want is when a powerful attacker (like laziness for example) cuts me off from my jabber account or my AIM, or renders it so I can no longer log in somewhere, I want to be able to start up a new account at a (hopefully) more stable server, and have my identity not require re-verification. With my idea, there would be no second automatic verification, because the same key is being used, only the account is changing. The distinction is that if you use different keys and somehow try to coordinate which keys belong to who, you'll get in trouble with the situation I described. Even if there is an OTR message to verify one key via another, the key that was verified is now forever inaccessible since my original account was blocked, and I can't use the same key on a new account. My new key will be as unverifiable as if I had never talked with my friends in the first place. I see that as a problem. When the phone company has to replace the wires it uses, it doesn't require everyone to start using a new phone number. I don't see why that must be so with the already self-authorizable OTR. > (if > I understand correctly that you mostly want automatic, painless > verification of multiple accounts belonging to the same user) You're close, but what I want is for the user to be independant of which account that user is using. To have one or more identities that use the accounts, but are not bound by them. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjVRVIACgkQB/meY5RuPPT2uwCffrCkegpmeHqETGofRXHo9BgD wUUAn3MtpYGPUnz7S0brWi54MkfEZjiG =WqZI -----END PGP SIGNATURE----- From ian at cypherpunks.ca Sat Sep 20 15:07:34 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Sat, 20 Sep 2008 15:07:34 -0400 Subject: [OTR-dev] Separate Fingerprint For Each Account? In-Reply-To: <48D54552.2060404@synx.us.to> References: <48D09929.9050808@synx.us.to> <20080917124103.GD15981@thunk.cs.uwaterloo.ca> <48D1C0C9.3020407@synx.us.to> <20080918143713.GC5383@thunk.cs.uwaterloo.ca> <48D2BE94.6000500@synx.us.to> <20080919141310.GD25908@thunk.cs.uwaterloo.ca> <48D424E5.60700@synx.us.to> <44acbb800809191925y36ef0145j2daaaca2ed53f71@mail.gmail.com> <48D54552.2060404@synx.us.to> Message-ID: <20080920190734.GA28043@yoink.cs.uwaterloo.ca> On Sat, Sep 20, 2008 at 11:47:46AM -0700, otr at synx.us.to wrote: > Donny Viszneki wrote: > > What you seem to want mostly out of this is auto-verification of keys > > where it is applicable. > > Heh, it does seem like that. The complaint against my idea seems to be > that we need to verify each key for each account separately. What I want > isn't the applicable auto-verification though, I'm just trying to > describe how such auto-verification is a non-problem. Unless I'm wrong > of course, in which case I'll quietly go back to the drawing board. > > What I want is when a powerful attacker (like laziness for example) cuts > me off from my jabber account or my AIM, or renders it so I can no > longer log in somewhere, I want to be able to start up a new account at > a (hopefully) more stable server, and have my identity not require > re-verification. With my idea, there would be no second automatic > verification, because the same key is being used, only the account is > changing. That's great, so long as your IM client has the concept of "all these account's I've seen are really the same person". Then if it sees a new IM account using the same OTR key, it can automatically add that new account to the bunch. But IM clients (that I've seen, anyway) don't have that concept. All they see are account names. So if I've previously authenticated you as "Bob", and your key suddenly shows up as "alice at jabber.de", how does my IM client let me know that "alice at jabber.de" is really the person I previously knew as "Bob", and not the person I know as "alice at jabber.ca"? Worse, what if I already know (and have verified) the _real_ alice at jabber.de, and you're spoofing her account? > The distinction is that if you use different keys and somehow try to > coordinate which keys belong to who, you'll get in trouble with the > situation I described. Remember again that almost every OTR user has no idea what a key is, and so doesn't in fact coordinate which key belongs to who. > When the phone company has to replace the wires it uses, it doesn't > require everyone to start using a new phone number. I don't see why that > must be so with the already self-authorizable OTR. That's not a good analogy. A better one is that a few years back, before number portability, if you switched cell phone carriers, your number would indeed change. Then you had to let your friends know your new number. IM account names are like non-portable phone numbers: they're tied to the underlying architecture. If we had a higher-level concept of identity, that would be more like modern portable phone numbers. - Ian From donny.viszneki at gmail.com Sun Sep 21 18:04:14 2008 From: donny.viszneki at gmail.com (Donny Viszneki) Date: Sun, 21 Sep 2008 18:04:14 -0400 Subject: [OTR-dev] Separate Fingerprint For Each Account? In-Reply-To: <20080920190734.GA28043@yoink.cs.uwaterloo.ca> References: <48D09929.9050808@synx.us.to> <20080917124103.GD15981@thunk.cs.uwaterloo.ca> <48D1C0C9.3020407@synx.us.to> <20080918143713.GC5383@thunk.cs.uwaterloo.ca> <48D2BE94.6000500@synx.us.to> <20080919141310.GD25908@thunk.cs.uwaterloo.ca> <48D424E5.60700@synx.us.to> <44acbb800809191925y36ef0145j2daaaca2ed53f71@mail.gmail.com> <48D54552.2060404@synx.us.to> <20080920190734.GA28043@yoink.cs.uwaterloo.ca> Message-ID: <44acbb800809211504l78403d7di658200ceca0049da@mail.gmail.com> On Sat, Sep 20, 2008 at 3:07 PM, Ian Goldberg wrote: > That's great, so long as your IM client has the concept of "all these > account's I've seen are really the same person". Then if it sees a new > IM account using the same OTR key, it can automatically add that new > account to the bunch. I believe this is the primary point of confusion for otr at synx.us.to. I believe he assumes that this is an inherent part of the OTR protocol, because he believes that your OTR plugin has access to data during any OTR conversation which it could compare with a list of OTR users it has "talked to" in the past, thus allowing it to deduce if that person is already known. This also requires the assumption that an OTR key is not inherently tied to a specific messenger account/username/address -OR- the concession that the initiation of an OTR conversation requires the disclosure of some sort of unique identifier by which you can be identified. One or both of these may be true, I don't know which, I hope someone who knows will tell us. -- http://codebad.com/ From otr at synx.us.to Sun Sep 21 18:22:52 2008 From: otr at synx.us.to (otr at synx.us.to) Date: Sun, 21 Sep 2008 15:22:52 -0700 Subject: [OTR-dev] Separate Fingerprint For Each Account? In-Reply-To: <20080920190734.GA28043@yoink.cs.uwaterloo.ca> References: <48D09929.9050808@synx.us.to> <20080917124103.GD15981@thunk.cs.uwaterloo.ca> <48D1C0C9.3020407@synx.us.to> <20080918143713.GC5383@thunk.cs.uwaterloo.ca> <48D2BE94.6000500@synx.us.to> <20080919141310.GD25908@thunk.cs.uwaterloo.ca> <48D424E5.60700@synx.us.to> <44acbb800809191925y36ef0145j2daaaca2ed53f71@mail.gmail.com> <48D54552.2060404@synx.us.to> <20080920190734.GA28043@yoink.cs.uwaterloo.ca> Message-ID: <48D6C93C.50205@synx.us.to> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ian Goldberg wrote: > But IM clients (that I've seen, anyway) don't have that concept. All > they see are account names. So if I've previously authenticated you as > "Bob", and your key suddenly shows up as "alice at jabber.de", how does my > IM client let me know that "alice at jabber.de" is really the person I > previously knew as "Bob", and not the person I know as > "alice at jabber.ca"? So your problem is that the client would show it as Alice, even though Bob had hacked her account, which is true even without OTR. With OTR in its current state it would still show the identity as Alice, but say that she wasn't verified since Bob could not duplicate the key for Alice's account. With OTR in the way that I'm thinking, it would show Bob's key as verified, for Bob's account, but if the same key showed up on Alice's account, it would show the key was still owned by Bob, even though it had been verified. You claim it is unreasonable to pop up a notification like, "Bob's key just showed up on Alice's account" when you deliver many notifications and dialogs and warnings when the key on Alice's account is completely unverified. I'm not saying all those warnings should disappear when Bob's key appears on Alice's account. I'm only saying that the warnings should inform the user that the account has been taken over by Bob, which will usually prompt them to seek another way to contact Alice. In its current state, all you see is an unverified key, which could be Alice losing her key, or it could be an impersonator. With my method, obviously Bob would be forced to use a new unverified key, since otherwise his attempted subterfuge would be easily detected. But if Alice changed accounts, she would not have to use a new unverified key, since we aren't expecting anyone else's key from that account. What I'm saying is, if Bob's key shows up on alice at jabber.de, then just pop up a dialog saying "Bob took over this account" and then people can use that account to speak with Bob, if they so choose. That will allow Alice to change accounts to aliceHasBetterPassword at jabber.de, and when she adds her buddies to that new account, since she's using the same key it's already verified and pops up a notice saying, "This is Alice." That provides a great utility to Alice, especially if Bob changes the password and locks her out of the account, while providing Bob with no utility to nefariously impersonate Alice. Indeed if there was an account called "president at company.com" then perhaps it would be legitimate if one verified key were replaced with another, whenever the president of the company changed. > Worse, what if I already know (and have verified) > the _real_ alice at jabber.de, and you're spoofing her account? My idea was if you already verified alice at jabber.de, the notice that pops up is big and dangerous and says "Bob took over Alice's account!" whereas if you don't have any history of verifying with alice at jabber.de, the notice is more benign saying, "Alice is now using this account" or something. > IM account names are like non-portable phone numbers: they're tied to > the underlying architecture. If we had a higher-level concept of > identity, that would be more like modern portable phone numbers. Which is why I'm saying that OTR should base its keys not on non-portable phone numbers, but on a higher-level concept of identity. A name perhaps, or some kind of record of who they claim to be. Something not tied to the physical channel of distribution. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjWyTwACgkQB/meY5RuPPSGZgCfeR5L0XyG+JMUPsnBmvyUy1wl Tq0AnjfiTXtYmKFzPrIx1NFtydM80n2p =TAVf -----END PGP SIGNATURE----- From ian at cypherpunks.ca Sun Sep 21 22:43:45 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Sun, 21 Sep 2008 22:43:45 -0400 Subject: [OTR-dev] Separate Fingerprint For Each Account? In-Reply-To: <48D6C93C.50205@synx.us.to> References: <20080917124103.GD15981@thunk.cs.uwaterloo.ca> <48D1C0C9.3020407@synx.us.to> <20080918143713.GC5383@thunk.cs.uwaterloo.ca> <48D2BE94.6000500@synx.us.to> <20080919141310.GD25908@thunk.cs.uwaterloo.ca> <48D424E5.60700@synx.us.to> <44acbb800809191925y36ef0145j2daaaca2ed53f71@mail.gmail.com> <48D54552.2060404@synx.us.to> <20080920190734.GA28043@yoink.cs.uwaterloo.ca> <48D6C93C.50205@synx.us.to> Message-ID: <20080922024345.GE28043@yoink.cs.uwaterloo.ca> On Sun, Sep 21, 2008 at 03:22:52PM -0700, otr at synx.us.to wrote: > Which is why I'm saying that OTR should base its keys not on > non-portable phone numbers, but on a higher-level concept of identity. A > name perhaps, or some kind of record of who they claim to be. Something > not tied to the physical channel of distribution. We're in complete agreement. OTR is agnostic on the whole identity issue; it's up to the application to convey this notion of identity to the user, and none of them does such a thing. - Ian From otr at synx.us.to Mon Sep 22 00:37:36 2008 From: otr at synx.us.to (otr at synx.us.to) Date: Sun, 21 Sep 2008 21:37:36 -0700 Subject: [OTR-dev] Separate Fingerprint For Each Account? In-Reply-To: <20080922024345.GE28043@yoink.cs.uwaterloo.ca> References: <20080917124103.GD15981@thunk.cs.uwaterloo.ca> <48D1C0C9.3020407@synx.us.to> <20080918143713.GC5383@thunk.cs.uwaterloo.ca> <48D2BE94.6000500@synx.us.to> <20080919141310.GD25908@thunk.cs.uwaterloo.ca> <48D424E5.60700@synx.us.to> <44acbb800809191925y36ef0145j2daaaca2ed53f71@mail.gmail.com> <48D54552.2060404@synx.us.to> <20080920190734.GA28043@yoink.cs.uwaterloo.ca> <48D6C93C.50205@synx.us.to> <20080922024345.GE28043@yoink.cs.uwaterloo.ca> Message-ID: <48D72110.9020700@synx.us.to> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ian Goldberg wrote: > We're in complete agreement. OTR is agnostic on the whole identity > issue; it's up to the application to convey this notion of identity to > the user, and none of them does such a thing. If OTR were agnostic on the whole identity issue, why does it generate one key for each "identity" account? I mean, if it were agnostic it would generate one key, and not record which account that key was used on, using the key on all accounts. It would leave it up to the client to "ensure" that someone's identity is sound. Of course the clients cannot do that perfectly, which might be an argument for having OTR be slightly less agnostic. In the OTR API, there is a structure called "context". It has as its members "username" and "accountname". These are used to determine which context to encrypt with. I really can't understand how that would be agnostic of accounts, since they're so obviously required to get a context in the first place. My idea was to modify the plugin so it used some dummy for account name, and another dummy for username, and used those dummies to get a context for every IM account. I would question the utility of having those fields to lookup with in the first place, but it should be possible to fill them with an abstract identity instead of a physical IM account. Instead of keeping track of which key to use for which of your accounts I'd have to add something keeping track of which key your buddies are using, and maybe pop up some warnings if that key changes in suspicious ways. I'm thinking with the pidgin plugin, but the proxy could also pop up GUI windows if it had to. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjXIQ8ACgkQB/meY5RuPPT8nQCaA8PYGZh7wb0lmxdh1Ar2XI6x lBkAoMfiIwmECW2DLSoMjva50q3UowRg =PgPf -----END PGP SIGNATURE-----