From paddler86 at gmx.de Sun Nov 4 10:27:01 2007 From: paddler86 at gmx.de (Benjamin Wilde) Date: Sun, 4 Nov 2007 16:27:01 +0100 Subject: [OTR-users] japanese/chinese signs when beginning conversation + wrong character encoding Message-ID: <001201c81ef7$265725a0$6401a8c0@hiob> hi folks since i've upgraded to miranda 0.7 (problem stays with 0.7.1), all my friends receive different japanese or chinese signs at the beginning of a conversation. the problem occurs everytime, wether i or them start the conversation. it does not depend on the client software they use or if they use OTR or not. additionally all german umlauts (like ?,?, ....) are not encoded correctly (dr?ber = dr??ber). when i disable the otr-plugin, they are encoded correctly. all of this worked fine under miranda 0.6.8; referring to miranda 0.7 changelog (major updates concerning encoding) i'd guess the kind of handling character encoding changed in a way that produces these errors. i found no help in the forum, so can anyone offer me a solution or workaround for these problems? (further information: i'm running windows XP SP2, miranda 0.7.1, OTR version is 0.5.2.0) thanks for any help -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael_reichenbach at freenet.de Fri Nov 9 19:08:03 2007 From: michael_reichenbach at freenet.de (Michael Reichenbach) Date: Sat, 10 Nov 2007 01:08:03 +0100 Subject: [OTR-users] pidgin, jabber, otr and offline messages Message-ID: <4734F663.5020704@freenet.de> It seamed I had still an active otr session with my interlocutor. He gone offline before and he ended the private conversation. OTR Error: You sent encrypted data to jabberid, who wasn't expecting it. Many times... All messages lost. Next issues, my interlocutor is offline and I want to send him some messages he shall read next time he goes online. Each time I write something it comes Attempting to start a private conversation... jabberid: text... All messages will be also lost. Otr is working stable and well now if both are online. But if someone loses connection, goes offline or is offline it won`t work well. We also set to require private messenging and then you can`t even send a message if the other one is offline. An important feature got lost (offline messages). Isn`t it possible to make otr work also with stored messages on the server? I would love to see the offline message support a bit improved. From paul at cypherpunks.ca Sat Nov 10 11:10:30 2007 From: paul at cypherpunks.ca (Paul Wouters) Date: Sat, 10 Nov 2007 11:10:30 -0500 (EST) Subject: [OTR-users] pidgin, jabber, otr and offline messages In-Reply-To: <4734F663.5020704@freenet.de> References: <4734F663.5020704@freenet.de> Message-ID: On Sat, 10 Nov 2007, Michael Reichenbach wrote: > It seamed I had still an active otr session with my interlocutor. He > gone offline before and he ended the private conversation. > OTR Error: You sent encrypted data to jabberid, who > wasn't expecting it. Many times... All messages lost. Yes. The bug appears somewhat regularly, but it is very hard to reproduce, and we haven't caught it yet with a full packet capture to determine what is going on. > Next issues, my interlocutor is offline and I want to send him some > messages he shall read next time he goes online. Each time I write > something it comes Attempting to start a private conversation... > jabberid: text... All messages will be also lost. Yes. OTR requires state and for full functioning interactivity (doing diffie hellman key exchanges). So either 1) the computer keeps state while offline or 2) you cannot work offline. The first solution is very dangerous to support, as "offline" would be the same as "attacker filtering packets", forcing you to perhaps send all messages with the same one key. > Otr is working stable and well now if both are online. But if someone > loses connection, goes offline or is offline it won`t work well. Yes. It is the price you have to pay. > We also set to require private messenging and then you can`t even send a > message if the other one is offline. An important feature got lost > (offline messages). Isn`t it possible to make otr work also with stored > messages on the server? Require private messages requires a handshake between the two parties. Obviously you cannot do that without the other party being there. See above. > I would love to see the offline message support a bit improved. The only way I can see it, is if support is added for "short term" symmetric keys, that can be used for a limited period of time to do "multiple encryption" rounds. This could then be used for other things too, such as video/audio streams and session keys. Though at that point, you're getting dangerously close to re-implementing IPsec, so what I'd really like to see instead, is a "channel binding" of OTR with IPsec (possible in IKEv2) where you setup an anonymous IPsec tunnel between the two parties, and through that, do an OTR verification. This then gives you a "secure end to end tunnel". The danger of implementing these session keys, is that the policy to the enduser becomes much more complicated, and you want to protect the enduser from confusion. Most of them who are not CS students, already find the three state "not private, "unverified", "private" confusing. Paul From klhrevolution at yahoo.com Wed Nov 21 02:26:44 2007 From: klhrevolution at yahoo.com (Ken Hensley) Date: Tue, 20 Nov 2007 23:26:44 -0800 (PST) Subject: [OTR-users] Off The Record: Instant Messaging Message-ID: <126635.71637.qm@web45609.mail.sp1.yahoo.com> Any chance that otr will be implementing it's features into gajim http://www.gajim.org/ or possibly gnuyahoo: http://gnuyahoo.sourceforge.net/ Thanks. ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs From blackest_knight at hotmail.com Sat Nov 24 08:09:30 2007 From: blackest_knight at hotmail.com (john owen-jones) Date: Sat, 24 Nov 2007 13:09:30 +0000 Subject: [OTR-users] file transfer via OTR? Message-ID: Hi Would it be possible to modify OTR for fle transfer. through pidgin? What I was thinking would be to drag and drop a file. First it would be uuencoded to convert it to text. encoded by OTR sent as chunks over the IM network decoded by OTR to reassemble the uuencoded file and then uudecoded to recreate the original file. Possibly it could even work as a push system as long as your logged on friends and colleagues would be able to send you files direct to your desktop. any thoughts john _________________________________________________________________ Get free emoticon packs and customisation from Windows Live. http://www.pimpmylive.co.uk From alex323 at gmail.com Sat Nov 24 09:53:35 2007 From: alex323 at gmail.com (Alex) Date: Sat, 24 Nov 2007 09:53:35 -0500 Subject: [OTR-users] file transfer via OTR? In-Reply-To: References: Message-ID: <20071124095335.40ecfbea@mx.google.com> On Sat, 24 Nov 2007 13:09:30 +0000 john owen-jones wrote: > > > Hi > Would it be possible to modify OTR for fle transfer. > through pidgin? > > What I was thinking would be to drag and drop a file. > > First it would be uuencoded to convert it to text. > encoded by OTR sent as chunks over the IM network > decoded by OTR to reassemble the uuencoded file > and then uudecoded to recreate the original file. > > Possibly it could even work as a push system as long as > your logged on friends and colleagues would be able to > send you files direct to your desktop. > > any thoughts > Make sure it has MD5, RIPEMD150, and/or SHA512 verification to make sure that the file is reassembled properly. Each chunk would need to be verified and resent if decoding fails. This would require that the traffic be two way as opposed to just a blind send in one direction. Having communication in both directions would ensure that OTR is used to the best of its abilities, and would ensure the integrity of the file at the same time (for example, if there is a legit transmission error). I am not a fan of drag and drop. I would go more for a right-click menu option that says "Send file". -- Alex From alex323 at gmail.com Sat Nov 24 09:55:40 2007 From: alex323 at gmail.com (Alex) Date: Sat, 24 Nov 2007 09:55:40 -0500 Subject: [OTR-users] file transfer via OTR? In-Reply-To: <20071124095335.40ecfbea@mx.google.com> References: <20071124095335.40ecfbea@mx.google.com> Message-ID: <20071124095540.3d00476d@mx.google.com> On Sat, 24 Nov 2007 09:53:35 -0500 Alex wrote: > Make sure it has MD5, RIPEMD150, and/or SHA512 verification to make > sure that the file is reassembled properly. I did mean to say RIPEMD160. -- Alex From ian at cypherpunks.ca Sat Nov 24 15:05:10 2007 From: ian at cypherpunks.ca (Ian Goldberg) Date: Sat, 24 Nov 2007 15:05:10 -0500 Subject: [OTR-users] Off The Record: Instant Messaging In-Reply-To: <126635.71637.qm@web45609.mail.sp1.yahoo.com> References: <126635.71637.qm@web45609.mail.sp1.yahoo.com> Message-ID: <20071124200510.GD7500@yoink.cs.uwaterloo.ca> On Tue, Nov 20, 2007 at 11:26:44PM -0800, Ken Hensley wrote: > Any chance that otr will be implementing it's features > into gajim http://www.gajim.org/ or possibly gnuyahoo: > http://gnuyahoo.sourceforge.net/ OTR is a protocol; you'd have to ask the developers of those apps if they'd be willing to support the OTR protocol. We'd of course love to see more apps support OTR, and can provide integration assistance if needed. - Ian From paul at cypherpunks.ca Sat Nov 24 22:17:29 2007 From: paul at cypherpunks.ca (Paul Wouters) Date: Sat, 24 Nov 2007 22:17:29 -0500 (EST) Subject: [OTR-users] file transfer via OTR? In-Reply-To: References: Message-ID: On Sat, 24 Nov 2007, john owen-jones wrote: > Would it be possible to modify OTR for fle transfer. > through pidgin? Yes, but not like you think. OTR uses a diffie hellman exchange every message. Your CPU won't be able to do that for large streams (files, audio, video). What needs to be done is that OTR negotiates a key for a symmetric cipher (3des, aes, twofish), then uses that to encrypt the file, and send it via the "regular" sendfile method. Paul From h.iverson at gmail.com Sun Nov 25 18:20:59 2007 From: h.iverson at gmail.com (Harlan Iverson) Date: Sun, 25 Nov 2007 17:20:59 -0600 Subject: [OTR-users] new user, comments on authentication Message-ID: <25097ca30711251520sf625ed5t8d3443f63f5dfd09@mail.gmail.com> Hi, I am a new OTR user and have shared it with a few of my privacy conscious friends. Overall, getting it going using Pidgin has been an extremely smooth experience, but one hiccup has been explaining authentication. The two people I use OTR with now are 'authenticated', but only in that we have confirmed each others' keys (advanced > [I Have] ...); when I mentioned authenticating using some secret that we both know, like the name of a place that fits some description, they became confused. If privacy conscious hackers don't understand without reading a lot of documentation, I think there is a weakness in usability. For my friends, they just 'knew' at the time that they were talking to me, so authenticating using a shared secret was not something that they cared to investigate further. Confirming the key was 'good enough' to make the icon say "OTR: Private". If authentication were more streamlined and explained in the GUI (smaller learning curve), chances are we would have used a shared secret. It may seem like a pebkac issue, but really if the goal is to get people to take full advantage of OTR it needs to be addressed. My initial thoughts are to make sort of a wizard that runs each time OTR is used with an unverified client. Prompt the person initiating the conversation to enter some text that the other person can derive the shared secret from, for example "The name of the place we spilled the iced tea all over the waiter", and the receiver would then be prompted for the shared secret when they receive the message. For usability sake, I also think it would also be beneficial to give the option to ignore case/space/punctuation in the answer (convert secret to lower case, eliminate spaces and punctuation). Thoughts? -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmaxwell at gmail.com Sun Nov 25 22:07:47 2007 From: gmaxwell at gmail.com (Gregory Maxwell) Date: Sun, 25 Nov 2007 22:07:47 -0500 Subject: [OTR-users] new user, comments on authentication In-Reply-To: <25097ca30711251520sf625ed5t8d3443f63f5dfd09@mail.gmail.com> References: <25097ca30711251520sf625ed5t8d3443f63f5dfd09@mail.gmail.com> Message-ID: On Nov 25, 2007 6:20 PM, Harlan Iverson wrote: > Hi, > I am a new OTR user and have shared it with a few of my privacy conscious > friends. Overall, getting it going using Pidgin has been an extremely smooth > experience, but one hiccup has been explaining authentication. The two > people I use OTR with now are 'authenticated', but only in that we have > confirmed each others' keys (advanced > [I Have] ...); when I mentioned > authenticating using some secret that we both know, like the name of a place > that fits some description, they became confused. If privacy conscious > hackers don't understand without reading a lot of documentation, I think > there is a weakness in usability. Long time OTR user here. With the new authentication mode I took the opportunity to get some more of my contacts using OTR. I found that, as in the past, my contacts had no trouble with the general concept of authentication but getting them to understand that the match is not fuzzy and must be exact was hard. They all seemed to think that the text in the dialog would be shown to me and that I would approve it. ugh. Perhaps changing the dialog so that it asks for a "passphrase" might make it more clear that the spacing matters. If this results in people being mislead into thinking the passphrase will be used to encrypt their communication, then so be it. I think that would be better than the current state. It might also be worthwhile to explore including normalization, i.e. case-folding and whitespace removal. That would reduce security, but any secret which is weak after normalization was probably weak before normalization. All in all I'm happy to see this new authentication mode in OTR, thought I would have preferred an alternative design (http://lists.cypherpunks.ca/pipermail/otr-users/2006-March/000602.html, I prefered the idea of using a strengthened additional shared secret as an additional input to the symetric cipher to avoid DH weaknesses). On the subject of OTR usability I still frequently suffer from the "multiple client problem" with AIM users, where a user logs in multiple OTR enabled clients and all respond to my OTR messages. This especially problematic with the Mac contacts that I have who run OTR without even knowing it. While it is really good that OTR is enabled by default for these users, they get really confused when we run into a multiple client issue. This family of problems has resulted in a few of my contacts keeping OTR disabled most of the time, so at least as far as my contact go it's still a larger security problem than the authentication issue. I also still run into cases where the OTR overhead makes hitting the maximum message size in aim much easier, especially with HTML pastes. It's not obvious to users that OTR is causing their suffering, so it doesn't get turned off in response. I understand that the requirement for blind forgability pretty much rules out compression (which is too bad because algorithms like XML-WRT w/ dictionary do an amazing job averaging 6.886 bits per char on my shortest messages and 3.2 bits per char on my size-rejected IMs) ... but automatic message splitting would be really nice. Even if you had to manually set the MTU. From michael_reichenbach at freenet.de Mon Nov 26 10:11:50 2007 From: michael_reichenbach at freenet.de (Michael Reichenbach) Date: Mon, 26 Nov 2007 16:11:50 +0100 Subject: [OTR-users] new user, comments on authentication In-Reply-To: <25097ca30711251520sf625ed5t8d3443f63f5dfd09@mail.gmail.com> References: <25097ca30711251520sf625ed5t8d3443f63f5dfd09@mail.gmail.com> Message-ID: <474AE236.4010104@freenet.de> I did like the old way to authenticate. Go to plugin`s preferences and check each others fingerprint, that way it`s really secure. The new "secret" is quite confusing, yes. A "password" would make more point, but however, I find it best to check the fingerprint. From michael_reichenbach at freenet.de Mon Nov 26 10:24:32 2007 From: michael_reichenbach at freenet.de (Michael Reichenbach) Date: Mon, 26 Nov 2007 16:24:32 +0100 Subject: [OTR-users] What we can expect in future? / file transfer via OTR? In-Reply-To: References: Message-ID: <474AE530.9060900@freenet.de> john owen-jones wrote > > Hi > Would it be possible to modify OTR for fle transfer. > through pidgin? > > What I was thinking would be to drag and drop a file. > > First it would be uuencoded to convert it to text. > encoded by OTR sent as chunks over the IM network > decoded by OTR to reassemble the uuencoded file > and then uudecoded to recreate the original file. > > Possibly it could even work as a push system as long as > your logged on friends and colleagues would be able to > send you files direct to your desktop. > > any thoughts > > john Imho OTR is a protocol and it`s in final version and no good idea to change it because many clients implement it. We can`t expect the developers from this project to add real new features, just improvements for the security (if needed later), user support and an updated version of their own implementation for pidgin. But the developers may give a final verdict on this. Sure I would love to use Pidgin also for encrypted and authenticated file transfers. Because it does not have this feature yet we are currently using some complicated setup with ftp over ssl. It does not provide Deniability and Perfect forward secrecy but it`s better then no encryption and authentication at all. Because Deniability and Perfect forward secrecy are the main reasons for OTR and them won`t work well with audio/video/filesend yet I think a request for encrypted file transfers is out of scope the OTR project. Some other project would be worth, anyone who has time may make it. :) Would "just" need to "wrap" any Open Source server/client in a Pidgin plugin. Any thoughts for a well designed protocol for file transfer? I am thinking about something user friendly with nat-to-nat / proxy / socks support. Ftp won`t work so well without open ports. Is there some file transfer protocol where you can use free stun servers very well? From gmaxwell at gmail.com Mon Nov 26 10:31:47 2007 From: gmaxwell at gmail.com (Gregory Maxwell) Date: Mon, 26 Nov 2007 10:31:47 -0500 Subject: [OTR-users] new user, comments on authentication In-Reply-To: <474AE236.4010104@freenet.de> References: <25097ca30711251520sf625ed5t8d3443f63f5dfd09@mail.gmail.com> <474AE236.4010104@freenet.de> Message-ID: On Nov 26, 2007 10:11 AM, Michael Reichenbach wrote: > I did like the old way to authenticate. Go to plugin`s preferences and > check each others fingerprint, that way it`s really secure. > > The new "secret" is quite confusing, yes. A "password" would make more > point, but however, I find it best to check the fingerprint. From gmaxwell at gmail.com Mon Nov 26 10:42:27 2007 From: gmaxwell at gmail.com (Gregory Maxwell) Date: Mon, 26 Nov 2007 10:42:27 -0500 Subject: [OTR-users] What we can expect in future? / file transfer via OTR? In-Reply-To: <474AE530.9060900@freenet.de> References: <474AE530.9060900@freenet.de> Message-ID: On Nov 26, 2007 10:24 AM, Michael Reichenbach wrote: [snip] > Imho OTR is a protocol and it`s in final version and no good idea to > change it because many clients implement it. We can`t expect the > developers from this project to add real new features, just improvements > for the security (if needed later), user support and an updated version > of their own implementation for pidgin. But the developers may give a > final verdict on this. > > Sure I would love to use Pidgin also for encrypted and authenticated > file transfers. Because it does not have this feature yet we are > currently using some complicated setup with ftp over ssl. It does not > provide Deniability and Perfect forward secrecy but it`s better then no > encryption and authentication at all. It may be possible for OTR to help offer encrypted file transfer with very little change to the protocol. Simply provide an interface in OTR for OTR to send an empty message then return the encryption key and mac key used for that message. The client would then encrypt the file using those keys and send the file through the normal file transfer means. The remote client could use the same keys. Some work would need to be included to defer the release of that mac key until the file was received... but we're not talking a complete protocol overhaul. Generally the ability for OTR to act as a person to person key producer would be pretty useful. Especially now that it offers the secure millionare based real-time authentication, which is a feature not offered by anything else. Sending files as in-band OTR messages, as was suggested, is pretty much a non-starter: most IM systems rate limit messages. From ian at cypherpunks.ca Mon Nov 26 18:23:17 2007 From: ian at cypherpunks.ca (Ian Goldberg) Date: Mon, 26 Nov 2007 18:23:17 -0500 Subject: [OTR-users] What we can expect in future? / file transfer via OTR? In-Reply-To: References: <474AE530.9060900@freenet.de> Message-ID: <20071126232317.GK7500@yoink.cs.uwaterloo.ca> On Mon, Nov 26, 2007 at 10:42:27AM -0500, Gregory Maxwell wrote: > On Nov 26, 2007 10:24 AM, Michael Reichenbach > wrote: > [snip] > > Imho OTR is a protocol and it`s in final version and no good idea to > > change it because many clients implement it. In fact, it was built for extensibility, so adding a feature like this wouldn't break anything. > It may be possible for OTR to help offer encrypted file transfer with > very little change to the protocol. Simply provide an interface in > OTR for OTR to send an empty message then return the encryption key > and mac key used for that message. The client would then encrypt the > file using those keys and send the file through the normal file > transfer means. The remote client could use the same keys. > > Some work would need to be included to defer the release of that mac > key until the file was received... but we're not talking a complete > protocol overhaul. Indeed, adding a new TLV type which basically says "expect a file transfer with this specified transfer cookie, to be encrypted and MACd with keys derived from this message's encryption key" should be sufficient. > Generally the ability for OTR to act as a person to person key > producer would be pretty useful. Especially now that it offers the > secure millionare based real-time authentication, which is a feature > not offered by anything else. > > Sending files as in-band OTR messages, as was suggested, is pretty > much a non-starter: most IM systems rate limit messages. For sure. - Ian From ian at cypherpunks.ca Mon Nov 26 18:35:42 2007 From: ian at cypherpunks.ca (Ian Goldberg) Date: Mon, 26 Nov 2007 18:35:42 -0500 Subject: [OTR-users] new user, comments on authentication In-Reply-To: <25097ca30711251520sf625ed5t8d3443f63f5dfd09@mail.gmail.com> References: <25097ca30711251520sf625ed5t8d3443f63f5dfd09@mail.gmail.com> Message-ID: <20071126233542.GL7500@yoink.cs.uwaterloo.ca> On Sun, Nov 25, 2007 at 05:20:59PM -0600, Harlan Iverson wrote: > For my friends, they just 'knew' at the time that they were talking to me, > so authenticating using a shared secret was not something that they cared to > investigate further. How could they possibly know this? Without doing some kind of authentication (either the manual fingerprint check or the shared secret), there's no way to distinguish a working OTR connection and one that's going through a MITM (say, the automated OTR MITM plugin for ejabberd: http://www.ejabberd.im/mod_otr ). - Ian From ian at cypherpunks.ca Mon Nov 26 18:36:37 2007 From: ian at cypherpunks.ca (Ian Goldberg) Date: Mon, 26 Nov 2007 18:36:37 -0500 Subject: [OTR-users] new user, comments on authentication In-Reply-To: References: <25097ca30711251520sf625ed5t8d3443f63f5dfd09@mail.gmail.com> Message-ID: <20071126233637.GM7500@yoink.cs.uwaterloo.ca> On Sun, Nov 25, 2007 at 10:07:47PM -0500, Gregory Maxwell wrote: > I also still run into cases where the OTR overhead makes hitting the > maximum message size in aim much easier, especially with HTML pastes. > It's not obvious to users that OTR is causing their suffering, so it > doesn't get turned off in response. I understand that the requirement > for blind forgability pretty much rules out compression (which is too > bad because algorithms like XML-WRT w/ dictionary do an amazing job > averaging 6.886 bits per char on my shortest messages and 3.2 bits per > char on my size-rejected IMs) ... but automatic message splitting > would be really nice. Even if you had to manually set the MTU. Are you still seeing this with 3.1? Automated message splitting is indeed turned on in that version. - Ian From ian at cypherpunks.ca Mon Nov 26 18:38:32 2007 From: ian at cypherpunks.ca (Ian Goldberg) Date: Mon, 26 Nov 2007 18:38:32 -0500 Subject: [OTR-users] new user, comments on authentication In-Reply-To: <474AE236.4010104@freenet.de> References: <25097ca30711251520sf625ed5t8d3443f63f5dfd09@mail.gmail.com> <474AE236.4010104@freenet.de> Message-ID: <20071126233832.GN7500@yoink.cs.uwaterloo.ca> On Mon, Nov 26, 2007 at 04:11:50PM +0100, Michael Reichenbach wrote: > I did like the old way to authenticate. Go to plugin`s preferences and > check each others fingerprint, that way it`s really secure. > > The new "secret" is quite confusing, yes. A "password" would make more > point, but however, I find it best to check the fingerprint. But most people have no clue what a fingerprint is. They have *some* clue what a secret is. So I think we're better off. That said, we're working on an actual user study of OTR right now. - Ian From ian at cypherpunks.ca Mon Nov 26 18:41:47 2007 From: ian at cypherpunks.ca (Ian Goldberg) Date: Mon, 26 Nov 2007 18:41:47 -0500 Subject: [OTR-users] new user, comments on authentication In-Reply-To: References: <25097ca30711251520sf625ed5t8d3443f63f5dfd09@mail.gmail.com> <474AE236.4010104@freenet.de> Message-ID: <20071126234147.GO7500@yoink.cs.uwaterloo.ca> On Mon, Nov 26, 2007 at 10:31:47AM -0500, Gregory Maxwell wrote: > My past somewhat negative comments on this approach were not intended > to claim that it isn't secure. Rather I was disappointed that OTR > wouldn't also use the shared secret to increase resistance to any > possible future DH weakness. However, if DH is found to be > substantially weaker than expected OTR will probably be the last of > our problems... Indeed, if DH is weak, we're pretty much hosed all around. The other problem is that requiring the shared secret to be entered before the first DH was calculated would have been bad for UI, and prevented agreement on the secret. As for normalization: that's hard to do when you don't know what the users will be entering. But the users can say (in-band) "that restaurant we went to that time, all lowercase, no spaces". - Ian From perrin at apotheon.com Mon Nov 26 18:49:52 2007 From: perrin at apotheon.com (Chad Perrin) Date: Mon, 26 Nov 2007 16:49:52 -0700 Subject: [OTR-users] new user, comments on authentication In-Reply-To: <20071126233832.GN7500@yoink.cs.uwaterloo.ca> References: <25097ca30711251520sf625ed5t8d3443f63f5dfd09@mail.gmail.com> <474AE236.4010104@freenet.de> <20071126233832.GN7500@yoink.cs.uwaterloo.ca> Message-ID: <20071126234952.GB35227@demeter.hydra> On Mon, Nov 26, 2007 at 06:38:32PM -0500, Ian Goldberg wrote: > On Mon, Nov 26, 2007 at 04:11:50PM +0100, Michael Reichenbach wrote: > > I did like the old way to authenticate. Go to plugin`s preferences and > > check each others fingerprint, that way it`s really secure. > > > > The new "secret" is quite confusing, yes. A "password" would make more > > point, but however, I find it best to check the fingerprint. > > But most people have no clue what a fingerprint is. They have *some* > clue what a secret is. So I think we're better off. > > That said, we're working on an actual user study of OTR right now. Well . . . this user was pleasantly surprised by the inclusion of the "shared secret" functionality. I've only used it with one person thus far, but that made it a lot easier to authenticate with someone more than 1500 miles away than to contact him by telephone and use military phonetic alphabet to verify "fingerprints". We briefly discussed the idea of a shared secret, he said something about a fact nobody else would have known, and boom -- we were authenticated. If there's a "better" way to explain it so people more intuitively grasp the concept, that's great. Go for it. I didn't have any touble with it at all, and neither did my friend. For the sake of not wanting to screw up, we just agreed to a particular letter case scheme, assuming it was case sensitive. No confusion. It's just one data point, but as far as I'm concerned it works. -- CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ] Amazon.com interview candidate: "When C++ is your hammer, everything starts to look like your thumb." From h.iverson at gmail.com Mon Nov 26 20:47:36 2007 From: h.iverson at gmail.com (Harlan Iverson) Date: Mon, 26 Nov 2007 19:47:36 -0600 Subject: [OTR-users] new user, comments on authentication In-Reply-To: <20071126233542.GL7500@yoink.cs.uwaterloo.ca> References: <25097ca30711251520sf625ed5t8d3443f63f5dfd09@mail.gmail.com> <20071126233542.GL7500@yoink.cs.uwaterloo.ca> Message-ID: <25097ca30711261747q3f7cd8b3hddb25ea3a576594c@mail.gmail.com> Ian, We didn't 'know' for sure, hence the quotes. When you chat with a person regularly you pick up on their grammar, slang usage, punctuation, etc. It's not scientific, but it's certainly relevant to my experience with the authentication process and I'll explain. They already 'know' they're talking to me, and I already 'know' I'm talking to them based on those factors, combined with the minuscule probability that we are targets of covert surveillance or subject to a MITM attack. Others might not be so safe in those assumptions. You are correct that we certainly do not know with 100% certainty, and this is the reason I would like authentication to be more accessible. As it stands right now, authenticating properly feels like an extra, unnecessary step because 1) There is the aforementioned assumption that the person is who you think it is, and 2) the "OTR: Private" icon can easily be displayed without going through that step, by blindly confirming the other party's fingerprint. I realize in theory there is some chance that is not correct, but the average user doesn't think that way. If a way can be found to make it easier, why not explore it? The conversations have all gone something like this: Me: Hey, have you heard about Off The Record? Them: No, what's that? Me: [explanation of encryption, authentication, deniability, perfect forward secrecy, link to website with gaim plugin] Them: Cool [download and enable] OTR Started, make sure to verify and authenticate Me: Alright, lets authentication with the ____ of _____ Them: Alright, it says Private. cool Me: Did you use the pass phrase? Them: I don't know, but it says private. Me: Did you get any kind of dialog or anything? It says it's waiting. Them: It says it's private, so it must have worked. Me: Here, I'll cancel it. Try going to Authenticate and typing in the answer to that question Them: I don't know, it says it's private though. [by this time I'm feeling like a pain in the ass and drop it, because I have my false sense of certainty that it's them anyway] Nobody wants to feel like a pain in the ass, and by having felt that way three times now it's seeming like a usability issue. I'm not trying to insult your work or be a pebkac, I do honestly want to see *everyone *adopt secure and private messaging. You can write it off as me and everyone I've shared it with being clueless if you wish, I just thought I'd try to help out. Best regards, Harlan On Nov 26, 2007 5:35 PM, Ian Goldberg wrote: > On Sun, Nov 25, 2007 at 05:20:59PM -0600, Harlan Iverson wrote: > > For my friends, they just 'knew' at the time that they were talking to > me, > > so authenticating using a shared secret was not something that they > cared to > > investigate further. > > How could they possibly know this? Without doing some kind of > authentication (either the manual fingerprint check or the shared > secret), there's no way to distinguish a working OTR connection and one > that's going through a MITM (say, the automated OTR MITM plugin for > ejabberd: http://www.ejabberd.im/mod_otr ). > > - Ian > _______________________________________________ > OTR-users mailing list > OTR-users at lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ian at cypherpunks.ca Mon Nov 26 21:15:26 2007 From: ian at cypherpunks.ca (Ian Goldberg) Date: Mon, 26 Nov 2007 21:15:26 -0500 Subject: [OTR-users] new user, comments on authentication In-Reply-To: <25097ca30711261747q3f7cd8b3hddb25ea3a576594c@mail.gmail.com> References: <25097ca30711251520sf625ed5t8d3443f63f5dfd09@mail.gmail.com> <20071126233542.GL7500@yoink.cs.uwaterloo.ca> <25097ca30711261747q3f7cd8b3hddb25ea3a576594c@mail.gmail.com> Message-ID: <20071127021526.GP7500@yoink.cs.uwaterloo.ca> On Mon, Nov 26, 2007 at 07:47:36PM -0600, Harlan Iverson wrote: > Ian, > > We didn't 'know' for sure, hence the quotes. When you chat with a person > regularly you pick up on their grammar, slang usage, punctuation, etc. It's > not scientific, but it's certainly relevant to my experience with the > authentication process and I'll explain. They already 'know' they're talking > to me, and I already 'know' I'm talking to them based on those factors, > combined with the minuscule probability that we are targets of covert > surveillance or subject to a MITM attack. Others might not be so safe in > those assumptions. But that's just it: with a MITM attack, you *really are* talking to your friend. You'll get all the grammar, slang, etc. that you expect from your friend. But the IM server operator is also logging your supposedly private conversation. > You are correct that we certainly do not know with 100% certainty, and this > is the reason I would like authentication to be more accessible. As it > stands right now, authenticating properly feels like an extra, unnecessary > step because 1) There is the aforementioned assumption that the person is > who you think it is, and 2) the "OTR: Private" icon can easily be displayed > without going through that step, by blindly confirming the other party's > fingerprint. I realize in theory there is some chance that is not correct, > but the average user doesn't think that way. If a way can be found to make > it easier, why not explore it? Indeed, you're right. As I mentioned in another post, we're currently doing user studies in order to see where the user issues with OTR are, so we can improve them. > The conversations have all gone something like this: > > Me: Hey, have you heard about Off The Record? > Them: No, what's that? > Me: [explanation of encryption, authentication, deniability, perfect forward > secrecy, link to website with gaim plugin] > Them: Cool [download and enable] > OTR Started, make sure to verify and authenticate > Me: Alright, lets authentication with the ____ of _____ > Them: Alright, it says Private. cool If it says "Private" (as opposed to "Unverified"), then he must have successfully authenticated. Unless he somehow found the "Authenticate Buddy" > "Advanced" > "I have" sequence? > Nobody wants to feel like a pain in the ass, and by having felt that way > three times now it's seeming like a usability issue. I'm not trying to > insult your work or be a pebkac, I do honestly want to see *everyone *adopt > secure and private messaging. You can write it off as me and everyone I've > shared it with being clueless if you wish, I just thought I'd try to help > out. We're really happy with your user reports, for sure! We also want to see all messaging be secure and private. Ideally, it'll be that way by default, and without the user even knowing it. [Of course, the user won't be able to defend against MITM in that situation, but they'd be no worse off than they are now.] Thanks, - Ian From klhrevolution at yahoo.com Mon Nov 26 22:13:04 2007 From: klhrevolution at yahoo.com (Ken Hensley) Date: Mon, 26 Nov 2007 19:13:04 -0800 (PST) Subject: [OTR-users] another supported Messenger Message-ID: <657271.64252.qm@web45613.mail.sp1.yahoo.com> Yeah, in my quest to find a simple client I found that mcabber supports OTR. and along with the server at jabber.no I can use otr through jabber w/ otr! http://www.lilotux.net/~mikael/mcabber/ little FYI not advertising... ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs From paul at cypherpunks.ca Tue Nov 27 11:55:46 2007 From: paul at cypherpunks.ca (Paul Wouters) Date: Tue, 27 Nov 2007 11:55:46 -0500 (EST) Subject: [OTR-users] new user, comments on authentication In-Reply-To: <20071126234147.GO7500@yoink.cs.uwaterloo.ca> References: <25097ca30711251520sf625ed5t8d3443f63f5dfd09@mail.gmail.com> <474AE236.4010104@freenet.de> <20071126234147.GO7500@yoink.cs.uwaterloo.ca> Message-ID: On Mon, 26 Nov 2007, Ian Goldberg wrote: > As for normalization: that's hard to do when you don't know what the > users will be entering. But the users can say (in-band) "that > restaurant we went to that time, all lowercase, no spaces". That's opening a dangerous door. If you have geo tagged flickr photos of that dinner that was memorable enough. I found in general, people do not understand what a man in the middle is. Numerous of my (not really dumb) friends, tend to believe that you can do something like the above, but with the answer supplied in-band as well. I would much rather suggest the user to pick up the phone. Paul From paul at cypherpunks.ca Tue Nov 27 12:03:30 2007 From: paul at cypherpunks.ca (Paul Wouters) Date: Tue, 27 Nov 2007 12:03:30 -0500 (EST) Subject: [OTR-users] new user, comments on authentication In-Reply-To: <20071126234952.GB35227@demeter.hydra> References: <25097ca30711251520sf625ed5t8d3443f63f5dfd09@mail.gmail.com> <474AE236.4010104@freenet.de> <20071126233832.GN7500@yoink.cs.uwaterloo.ca> <20071126234952.GB35227@demeter.hydra> Message-ID: On Mon, 26 Nov 2007, Chad Perrin wrote: > > Well . . . this user was pleasantly surprised by the inclusion of the > "shared secret" functionality. It's important to upgrade all clients though. We now run into the issue where older clients cannot do this to newer clients, and it is even more confusing to the enduser. (add to that we only do this new authentication on pidgin, not gaim, and some distros are stuck with gaim) Paul From paul at cypherpunks.ca Tue Nov 27 12:40:46 2007 From: paul at cypherpunks.ca (Paul Wouters) Date: Tue, 27 Nov 2007 12:40:46 -0500 (EST) Subject: [OTR-users] another supported Messenger In-Reply-To: <657271.64252.qm@web45613.mail.sp1.yahoo.com> References: <657271.64252.qm@web45613.mail.sp1.yahoo.com> Message-ID: On Mon, 26 Nov 2007, Ken Hensley wrote: > http://www.lilotux.net/~mikael/mcabber/ I just tested it. OTR is not autodetected, you need to ./configure --enable-otr then you need to add "set otr = 1" to your ~/.mcabberrc file and create the directory ~/.mcabber/otr/ It failed to read my generated OTR key because my alias had spaces in them, creating spaces in the filename, which didnt get handled properly. (I mixed up login name with nick name) After fiddling with a command line only client. I managed to invite myself and send my other self an OTR request. However, I got: 11-27 12:27 --> test ???11-27 12:27 <== ?OTR?v2? ??? PaulWouters at jabber.org/Gaim has ??? requested an Off-the-Record private ??? conversation ??? . However, ??? you do not have a plugin to support ??? that. ??? See http://otr.cypherpunks.ca/ for more ??? information. Trying to start OTR failed: /otr smpr paulwouters at jabber.org mysecret [12:34:39] /otr smpr [jid] secret [12:34:39] Respond to the Initiation of the jid with the secret [12:34:39] /otr smpa [jid] [12:34:39] Abort the running Socialist Millionaires Protocol [12:34:54] You have to start an OTR channel with paulwouters at jabber.org before you can use SMP. It took me a little bit to figure out [jid] are not 3 options, but one (the jabber id) I think some of the help text might also be scrolling out of my 4 line status window. Man, command line cliens are hard :P Paul From ian at cypherpunks.ca Wed Nov 28 11:42:43 2007 From: ian at cypherpunks.ca (Ian Goldberg) Date: Wed, 28 Nov 2007 11:42:43 -0500 Subject: [OTR-users] new user, comments on authentication In-Reply-To: References: <25097ca30711251520sf625ed5t8d3443f63f5dfd09@mail.gmail.com> <474AE236.4010104@freenet.de> <20071126234147.GO7500@yoink.cs.uwaterloo.ca> Message-ID: <20071128164243.GM24383@thunk.cs.uwaterloo.ca> On Tue, Nov 27, 2007 at 11:55:46AM -0500, Paul Wouters wrote: > On Mon, 26 Nov 2007, Ian Goldberg wrote: > > > As for normalization: that's hard to do when you don't know what the > > users will be entering. But the users can say (in-band) "that > > restaurant we went to that time, all lowercase, no spaces". > > That's opening a dangerous door. If you have geo tagged flickr > photos of that dinner that was memorable enough. > > I found in general, people do not understand what a man in the middle > is. Numerous of my (not really dumb) friends, tend to believe that > you can do something like the above, but with the answer supplied > in-band as well. > > I would much rather suggest the user to pick up the phone. I would much rather the users actually pick up the phone. But they won't, and there's nothing we can do about that. So we need to provide them a method that's at least plausible for them to use securely. We're definitely open to ideas of ways to make it as easy to use securely as possible. - Ian From gmaxwell at gmail.com Wed Nov 28 13:02:04 2007 From: gmaxwell at gmail.com (Gregory Maxwell) Date: Wed, 28 Nov 2007 13:02:04 -0500 Subject: [OTR-users] new user, comments on authentication In-Reply-To: <20071126234147.GO7500@yoink.cs.uwaterloo.ca> References: <25097ca30711251520sf625ed5t8d3443f63f5dfd09@mail.gmail.com> <474AE236.4010104@freenet.de> <20071126234147.GO7500@yoink.cs.uwaterloo.ca> Message-ID: On Nov 26, 2007 6:41 PM, Ian Goldberg wrote: > Indeed, if DH is weak, we're pretty much hosed all around. The other > problem is that requiring the shared secret to be entered before the > first DH was calculated would have been bad for UI, and prevented > agreement on the secret. Eh, once the secret is agreed on (as it now does now, though perhaps agreeing on a strengthened hash of the secret instead), compute secretID=PBKDF2('id' +lowerfingerprint+upperfingerprint+ secret) savedsecret=PBKDF2('otr'+lowerfingerprint+upperfingerprint+ secret) save the savedsecret along with the remote parties fingerprint. Now, for all future times DH is run, also exchange secret ID (in the clear or with the encryption established the last time DH was run). If both sides have matching secret IDs, they both XOR the savedsecret into the DH derived key before using it. Thus even if DH is weak, someone would need the secret or the savedsecret from one of the computers to recover the messages. Obviously the savedsecrets are a target for theft... but so are logs and otr private keys. I'd really like it if my client could use the gnome-keyring stuff to store an encryption key that protects my logs, otr private keys, etc but thats outside of the scope of OTR. Perhaps the additional DH weakness resistance is of too little value to make this interesting, on the other hand it might be easier to explain to people that they should authenticate so their conversations are secured with a password than it is to explain that they should authenticate to avoid MITM. > As for normalization: that's hard to do when you don't know what the > users will be entering. But the users can say (in-band) "that > restaurant we went to that time, all lowercase, no spaces". Eh, the software could still apply a default normalization with the assumption that they are writing text. For example: s/(\s\s+)/ /g //Fold all whitespace into a single space. s/(^\s+)//g //Squash all leading whitespace. S/(\s+$)//g //Squash all trailing whitespace. Removing trailing punctuation, Folding case, Reducing repeated characters to a single character.. all these might be reasonable. Of course, doing this will lower the key entropy... but it would mostly be reducing bad entropy that humans aren't likely to use. If users keys differ by only these factors it's really really unlikely that the users choose a really clever password like "Thedogjumped" and there is a MITM who is right except for the spaces, but it is really likely that someone just mistyped something. It could probably go as far as running double metaphone on every contiguous span of five or more ascii characters and still not really reduce security. Paul Wouters wrote: >> As for normalization: that's hard to do when you don't know what the >> users will be entering. But the users can say (in-band) "that >> restaurant we went to that time, all lowercase, no spaces". >That's opening a dangerous door. If you have geo tagged flickr >photos of that dinner that was memorable enough. A MITM with the determination and resources to pull off monitoring the conversation and conduct a quick real-time flickr search for the involved parties, could probably find a pair of people to impersonate the voices of the folks on the phone. The phone is probably better than a weak secret, but probably not better than a strong one. Ian Goldberg wrote: On Sun, Nov 25, 2007 at 10:07:47PM -0500, Gregory Maxwell wrote: >> I also still run into cases where the OTR overhead makes hitting the >> maximum message size in aim much easier, especially with HTML pastes. >Are you still seeing this with 3.1? Automated message splitting is >indeed turned on in that version. oh.. now that you mention it. Not on any 3.1 clients. THANKS! Ian Goldberg wrote: [snip] > I would much rather the users actually pick up the phone. But they > won't, and there's nothing we can do about that. So we need to provide > them a method that's at least plausible for them to use securely. > We're definitely open to ideas of ways to make it as easy to use > securely as possible. Bonus prize if you can invent a web-of-trust authentication system that uses common members on the users buddy-list without disclosing a users social network to the whole world... ;) [snip] > We also want to see all messaging be secure and private. Ideally, it'll be that way by > default, and without the user even knowing it. To really get there OTR needs to be included and enabled in quality clients *by* *default*. Half my AIM contacts have OTR ... but this is only because 1/4 are Mac users with a client that has OTR by default. Asking windows contacts to switch clients is a tall request, but pidgin has a lot of advantages over the default stuff. ... but to also ask them to install OTR, oy.. thats starting to ask too much in some cases. From paul at cypherpunks.ca Wed Nov 28 15:39:28 2007 From: paul at cypherpunks.ca (Paul Wouters) Date: Wed, 28 Nov 2007 15:39:28 -0500 (EST) Subject: [OTR-users] new user, comments on authentication In-Reply-To: References: <25097ca30711251520sf625ed5t8d3443f63f5dfd09@mail.gmail.com> <474AE236.4010104@freenet.de> <20071126234147.GO7500@yoink.cs.uwaterloo.ca> Message-ID: On Wed, 28 Nov 2007, Gregory Maxwell wrote: > Bonus prize if you can invent a web-of-trust authentication system > that uses common members on the users buddy-list without disclosing a > users social network to the whole world... ;) And eternal fame if you can build in a reputation system too (user X always clicks "verified" even if they didn't, but user H will always call before verifying) Paul > To really get there OTR needs to be included and enabled in quality > clients *by* *default*. Half my AIM contacts have OTR ... but this is > only because 1/4 are Mac users with a client that has OTR by default. > Asking windows contacts to switch clients is a tall request, but > pidgin has a lot of advantages over the default stuff. ... but to also > ask them to install OTR, oy.. thats starting to ask too much in some > cases. I think we are seeing a clear momentum grow. Without having hard statistics, it seems that OTR is being used much more then other IM encryptions. And broken alternatives like Scatterchat have died out. A lot of opensource IM clients are using it, the closed source ones will follow I think (in so far they have a large market left at all) Paul From gmaxwell at gmail.com Wed Nov 28 22:55:34 2007 From: gmaxwell at gmail.com (Gregory Maxwell) Date: Wed, 28 Nov 2007 22:55:34 -0500 Subject: [OTR-users] new user, comments on authentication In-Reply-To: <20071126233637.GM7500@yoink.cs.uwaterloo.ca> References: <25097ca30711251520sf625ed5t8d3443f63f5dfd09@mail.gmail.com> <20071126233637.GM7500@yoink.cs.uwaterloo.ca> Message-ID: On Nov 26, 2007 6:36 PM, Ian Goldberg wrote: > Are you still seeing this with 3.1? Automated message splitting is > indeed turned on in that version. After some more testing it seems that this isn't quite perfect .. at least not with pidgin-2.2.2-1.fc8 and libotr-3.1.0-1.fc8 (in Fedora 8). Pastes of HTML IMs that span multiple messages lose their HTMLness. Still better than a rejection, but there is room for improvement. ;) From michael_reichenbach at freenet.de Thu Nov 29 02:57:32 2007 From: michael_reichenbach at freenet.de (Michael Reichenbach) Date: Thu, 29 Nov 2007 08:57:32 +0100 Subject: [OTR-users] new user, comments on authentication In-Reply-To: References: <25097ca30711251520sf625ed5t8d3443f63f5dfd09@mail.gmail.com> <20071126233637.GM7500@yoink.cs.uwaterloo.ca> Message-ID: <474E70EC.7020507@freenet.de> 1) Well, if the shared secret is weak against mitm (because of dh) then you should drop it. 2) I think otr is about chatting secure with friends. In this case there can be not trusted third party like a web of trust. With a web of trust there is always the risk these days that some authority uses legal power to compromise that system. Web of trust can be only useful in commercial use (like ssl for communicating with bank. A web of trust has a point in this situation, but can be broken by authority with power over the web of trust / or even more simply the bank). 3) As long checking the fingerprint is secure (even if there is an active mitm from beginning from the first time for all times) I am happy. 4) This fingerprint needs to be checked either over a pre-secure channel or in a real life meeting. While saying "pre-secure" channel we are also back at complicated encryption and pgp. Phone is not that good for checking fingerprint (ok, voice synthetic attack is only in very little cases these days but it`s no real secure solution). I wish there would be a more easy solution, but I am afraid there isn`t. 5) The otr team did their job. Secure encryption between friends always need confirmation anything (fingerprint or public key) within a meeting in real life. Only if you suspect there are no logs / mitm for the first time of communication, then also dh and trusting the fingeprint without checking it might work but this is much less secure because you better should not suspect that. From gmaxwell at gmail.com Thu Nov 29 11:52:19 2007 From: gmaxwell at gmail.com (Gregory Maxwell) Date: Thu, 29 Nov 2007 11:52:19 -0500 Subject: [OTR-users] new user, comments on authentication In-Reply-To: <474E70EC.7020507@freenet.de> References: <25097ca30711251520sf625ed5t8d3443f63f5dfd09@mail.gmail.com> <20071126233637.GM7500@yoink.cs.uwaterloo.ca> <474E70EC.7020507@freenet.de> Message-ID: On Nov 29, 2007 2:57 AM, Michael Reichenbach wrote: > 1) Well, if the shared secret is weak against mitm (because of dh) then > you should drop it. It's not. Thats the *whole point*. Shared secret is only weak against MTIM if you give away the secret first: "lets authenticate, the password is the type of pet you have cat or dog." or if the underlying cryptographic construct turns out to be weak, which is a risk of the same nearly unavoidable sort we get from using DH to build keys or even AES to encrypt messages. > 2) I think otr is about chatting secure with friends. In this case there > can be not trusted third party like a web of trust. With a web of trust > there is always the risk these days that some authority uses legal power > to compromise that system. > > Web of trust can be only useful in commercial use (like ssl for > communicating with bank. A web of trust has a point in this situation, > but can be broken by authority with power over the web of trust / or > even more simply the bank). SSL certs are not web of trust. (http://en.wikipedia.org/wiki/Web_of_trust#Contrast_with_typical_PKI) By definition web of trust lacks a single party to turn. Web of trust has other problems, unrelated to the points you've raised against signing authorities. > 3) As long checking the fingerprint is secure (even if there is an > active mitm from beginning from the first time for all times) I am happy. > > 4) This fingerprint needs to be checked either over a pre-secure channel > or in a real life meeting. While saying "pre-secure" channel we are also > back at complicated encryption and pgp. > > Phone is not that good for checking fingerprint (ok, voice synthetic > attack is only in very little cases these days but it`s no real secure > solution). Which is why virtually no one does it. > I wish there would be a more easy solution, but I am afraid there isn`t. There is. OTR includes it now. You can authenticate with a previously established shared secret. Using the zero-knowledge socialist millionaire protocol. > 5) The otr team did their job. Secure encryption between friends always > need confirmation anything (fingerprint or public key) within a meeting > in real life. Or a shared secret, which is easier for humans to work with... From michael_reichenbach at freenet.de Fri Nov 30 12:08:26 2007 From: michael_reichenbach at freenet.de (Michael Reichenbach) Date: Fri, 30 Nov 2007 18:08:26 +0100 Subject: [OTR-users] encryption on mobile phone? Message-ID: <4750438A.30101@freenet.de> I am interested in encrypting messages using some mobile phone. (using messengers or sms/mms or internet) Can you recommend any serious solutions in this environment? From paul at cypherpunks.ca Fri Nov 30 14:58:43 2007 From: paul at cypherpunks.ca (Paul Wouters) Date: Fri, 30 Nov 2007 14:58:43 -0500 (EST) Subject: [OTR-users] encryption on mobile phone? In-Reply-To: <4750438A.30101@freenet.de> References: <4750438A.30101@freenet.de> Message-ID: On Fri, 30 Nov 2007, Michael Reichenbach wrote: > I am interested in encrypting messages using some mobile phone. (using > messengers or sms/mms or internet) > > Can you recommend any serious solutions in this environment? I am still waiting for my Openmoko photo with GSM+Wifi. Then I will be looking into porting OTR into whatever Openmoko's IM/SMS client is. Paul -- Building and integrating Virtual Private Networks with Openswan: http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155 From michael_reichenbach at freenet.de Fri Nov 30 15:05:47 2007 From: michael_reichenbach at freenet.de (Michael Reichenbach) Date: Fri, 30 Nov 2007 21:05:47 +0100 Subject: [OTR-users] encryption on mobile phone? In-Reply-To: <4750438A.30101@freenet.de> References: <4750438A.30101@freenet.de> Message-ID: <47506D1B.1010500@freenet.de> I don`t think it`s needed until any 100% Open Source mobile device is done. Afaik the most used common platform is java j2me, followed by symbian C++, followed by windows mobile. Are there any Open Source messengers out for any of this well used platforms? Also any Open Source solution which is packing sms / using internet (to write longer messages for same money) are interesting for that. From sven.lug-dorsten at gmx.de Fri Nov 30 17:28:44 2007 From: sven.lug-dorsten at gmx.de (Sven) Date: Fri, 30 Nov 2007 23:28:44 +0100 Subject: [OTR-users] encryption on mobile phone? In-Reply-To: <47506D1B.1010500@freenet.de> References: <4750438A.30101@freenet.de> <47506D1B.1010500@freenet.de> Message-ID: <1196461724.6375.5.camel@bluebox> I use the Nokia N800. It has no GSM, but WLAN and Bluetooth. It runs a debian-like system. Search for maemo if you want to dive into nokia's open plattform. It is shipped with a jabber messenger, which is the one i use at the moment. There are pidgin packages available allready, but i dont think otr is already available. br, Sven