From a.sporto+bee at gmail.com  Mon Dec  1 06:43:30 2008
From: a.sporto+bee at gmail.com (Uli M)
Date: Mon, 1 Dec 2008 12:43:30 +0100
Subject: [OTR-users] Initiating OTR from an irssi client to pidgin
In-Reply-To: <20081129235350.GA13711@lenny.local>
References: <20081129235350.GA13711@lenny.local>
Message-ID: <20081201114329.GA8316@gmail.com>

On Sun 30.11.08 00:53, cognitive.libertarian+ml at gmail.com wrote:
> When an irssi client initiates OTR (user issues the /otr auth
> command), pidgin doesn't engage.
> The irssi user sees "OTR: Initiated
> authentication...", but the pidgin user sees no indication of an
> attempt to establish an OTR session.
> 
> If a Pidgin user initiates OTR, then it works.
> 
> Anyone know what the issue might be?

You are mixing two things up here...one thing being OTR initiation and OTR
authentication the other.  irssi-otr's "/otr auth" command is NOT used to
initiate OTR but to initiate authentication over an already established OTR
session. The way irssi-otr currently operates (policy opportunistic) you can
just write "hello" and an OTR session should be initiated. This might take some
time though, e.g. if you use ICQ via bitlbee. Once a secure session is
established you can start authentication via "/otr auth <secret>" or from
pidgin, should work both ways.

Uli


From cognitive.libertarian+ml at gmail.com  Mon Dec  1 13:42:35 2008
From: cognitive.libertarian+ml at gmail.com (cognitive.libertarian+ml at gmail.com)
Date: Mon, 1 Dec 2008 19:42:35 +0100
Subject: [OTR-users] Initiating OTR from an irssi client to pidgin
In-Reply-To: <20081201114329.GA8316@gmail.com>
References: <20081129235350.GA13711@lenny.local>
	<20081201114329.GA8316@gmail.com>
Message-ID: <20081201184235.GA4855@lenny.local>

* Uli M <a.sporto+bee at gmail.com> [2008-12-01 18:04]:
> 
> The way irssi-otr currently operates (policy opportunistic) you can
> just write "hello" and an OTR session should be initiated. This
> might take some time though, e.g. if you use ICQ via bitlbee.

Thanks for the feedback.  Bitlbee and the ICQ network are in fact
being used.  However, the first thing attempted was to simply start
chatting.  It didn't work.  The Pidgin side gets plaintext.  

We also tried generating a key in advance on the irssi side: 

  /otr genkey <UID>@login.icq.com


From a.sporto+bee at gmail.com  Tue Dec  2 05:02:23 2008
From: a.sporto+bee at gmail.com (Uli M)
Date: Tue, 2 Dec 2008 11:02:23 +0100
Subject: [OTR-users] Initiating OTR from an irssi client to pidgin
In-Reply-To: <20081201184235.GA4855@lenny.local>
References: <20081129235350.GA13711@lenny.local>
	<20081201114329.GA8316@gmail.com>
	<20081201184235.GA4855@lenny.local>
Message-ID: <20081202100222.GA7784@gmail.com>

On Mon 01.12.08 19:42, cognitive.libertarian+ml at gmail.com wrote:
> * Uli M <a.sporto+bee at gmail.com> [2008-12-01 18:04]:
> > 
> > The way irssi-otr currently operates (policy opportunistic) you can
> > just write "hello" and an OTR session should be initiated. This
> > might take some time though, e.g. if you use ICQ via bitlbee.
> 
> Thanks for the feedback.  Bitlbee and the ICQ network are in fact
> being used.  However, the first thing attempted was to simply start
> chatting.  It didn't work.  The Pidgin side gets plaintext.  

The first message is indeed always plaintext. Usually, you'll just have to wait
a few seconds after that until the OTR session starts. However, if no key exists
then this first message will trigger key generation (check the status window)
which takes some time and will also make another plaintext message neccessary.
Just wait till generation finishes, write another message and wait a few
seconds. Then you should go secure.

> We also tried generating a key in advance on the irssi side: 
> 
>   /otr genkey <UID>@login.icq.com

irssi-otr itself has no idea about ICQ stuff, that's made transparent by
bitlbee. You'll have to use <irc-nick>@<irc-server> as accountname for
generation, also see the README or "/otr help" or just let irssi-otr do the
right thing.

Uli


From paul at cypherpunks.ca  Fri Dec  5 18:40:24 2008
From: paul at cypherpunks.ca (Paul Wouters)
Date: Fri, 5 Dec 2008 18:40:24 -0500 (EST)
Subject: [OTR-users] Interesting MITM with otr conversation log
Message-ID: <alpine.LFD.1.10.0812051832070.29934@newtla.xelerance.com>


Hey,

I got some strange IM from someone. Halfway through  figure out we've been setup
somehow with a relay in the middle and both of us see the other as some other
identity. When the person says he is using adium, I thought it was a perfect
chance to fire up OTR to see what would happen with this MITM scenario....
Funny enough, it revealed the identity of the other user to me :)

(My AIM identity is letoams)

(06:17:38 PM) SensitiveCoho: Hey.
(06:18:16 PM) letoams: bot?
(06:18:36 PM) SensitiveCoho: are you a bot?
(06:18:53 PM) letoams: are you are you are you a bot?
(06:19:14 PM) SensitiveCoho: no
(06:19:17 PM) SensitiveCoho: i'm human
(06:19:28 PM) letoams: ok then
(06:19:57 PM) SensitiveCoho: who are you?
(06:20:13 PM) letoams: if you dont know why are you talking to me?
(06:20:26 PM) SensitiveCoho: i want to know why you're talking to me
(06:20:48 PM) letoams: you started?
(06:20:52 PM) letoams: (06:17:38 PM) SensitiveCoho: Hey.
(06:21:12 PM) SensitiveCoho: i'm not SensitiveCoho
(06:21:30 PM) letoams: that's what i see
(06:21:31 PM) SensitiveCoho: embarrassedcoho
6:17

Hi!
(06:21:40 PM) SensitiveCoho: i see you as "embarrassedcoho"
(06:21:48 PM) letoams: that's not my name :)
(06:22:00 PM) letoams: funny. must be some bot connecting two random im identities
(06:22:06 PM) SensitiveCoho: maybe
(06:22:20 PM) SensitiveCoho: you on mac/pc?
(06:22:27 PM) letoams: linux
(06:22:32 PM) SensitiveCoho: i'm on mac
(06:22:33 PM) letoams: not infected here :P
(06:22:37 PM) SensitiveCoho: using adium
(06:22:57 PM) SensitiveCoho: adium's been weird today ... bugging me that yahoo messenger network is down for mainenance
(06:23:00 PM) letoams: really? let's try otr then. that would defeat a man in the middle attack
(06:23:02 PM) SensitiveCoho: it just keeps telling me this over and over
(06:23:03 PM) Attempting to start a private conversation with SensitiveCoho...
(06:23:12 PM) SensitiveCoho: otr?
(06:23:14 PM) sensitivecoho has not been authenticated yet.  You should authenticate this buddy.
[Image] (06:23:14 PM) Unverified conversation with SensitiveCoho started.
(06:23:26 PM) The following message received from sensitivecoho was not encrypted: [error]
(06:23:29 PM) The following message received from sensitivecoho was not encrypted: [hmm]
(06:23:30 PM) letoams: its privacy crypto built into adium and pidgin
(06:23:33 PM) OTR Error: You sent encrypted data to logicbus, who wasn't expecting it.
(06:23:45 PM) Successfully refreshed the unverified conversation with SensitiveCoho.
(06:23:45 PM) The last message to sensitivecoho was resent.
(06:23:47 PM) letoams: haha
(06:23:47 PM) The following message received from sensitivecoho was not encrypted: [could this be due to a compromised password?]
[Image] (06:23:53 PM) Private conversation with SensitiveCoho lost.
(06:23:56 PM) OTR Error: You sent encrypted data to logicbus, who wasn't expecting it.
(06:23:59 PM) SensitiveCoho: i can't read what you're saying
(06:24:02 PM) OTR Error: You sent encrypted data to logicbus, who wasn't expecting it.
(06:24:03 PM) letoams: awesome. the MITM does otr too
(06:24:20 PM) sensitivecoho is contacting you from an unrecognized computer.  You should authenticate this buddy.
[Image] (06:24:21 PM) Unverified conversation with SensitiveCoho started.
(06:24:23 PM) The following message received from sensitivecoho was not encrypted: [i read that]
[Image] (06:24:29 PM) Private conversation with SensitiveCoho lost.
(06:24:38 PM) SensitiveCoho: very strange
(06:24:40 PM) letoams: i think we blew up the mitm thing.
(06:25:06 PM) letoams: you know anyone in Toronto?
(06:29:13 PM) The encrypted message received from sensitivecoho is unreadable, as you are not currently communicating privately.
[Image] (06:29:34 PM) Unverified conversation with SensitiveCoho started.
[Image] (06:29:34 PM) Unverified conversation with SensitiveCoho started.
[Image] (06:32:21 PM) Private conversation with SensitiveCoho lost.
(06:32:27 PM) letoams: is your handle logicbus ?
(06:32:41 PM) The encrypted message received from sensitivecoho is unreadable, as you are not currently communicating privately.
(06:33:02 PM) SensitiveCoho: how did you figure that out
(06:33:11 PM) letoams: (06:23:33 PM) OTR Error: You sent encrypted data to logicbus, who wasn't expecting it.
(06:33:15 PM) letoams: otr told me
(06:33:26 PM) SensitiveCoho: hmm
(06:33:34 PM) SensitiveCoho: i just see "embarrassedcoho" for those msgs
(06:33:44 PM) SensitiveCoho: i suppose that could be a client thing
(06:33:49 PM) SensitiveCoho: i guess you have an advantage over me
(06:34:08 PM) letoams: still curious what is going on here. (my AIM is letoams)
(06:34:16 PM) SensitiveCoho: yeah
(06:34:41 PM) SensitiveCoho: i googled embarrassedcoho
(06:34:48 PM) SensitiveCoho: didn't come up with anything helpful
(06:35:42 PM) letoams: me neither
(06:36:22 PM) letoams: anyway. gotta go. have a nice life :)
(06:36:35 PM) SensitiveCoho: peace



From paul at cypherpunks.ca  Fri Dec  5 18:48:39 2008
From: paul at cypherpunks.ca (Paul Wouters)
Date: Fri, 5 Dec 2008 18:48:39 -0500 (EST)
Subject: [OTR-users] Interesting MITM with otr conversation log
In-Reply-To: <alpine.LFD.1.10.0812051832070.29934@newtla.xelerance.com>
References: <alpine.LFD.1.10.0812051832070.29934@newtla.xelerance.com>
Message-ID: <alpine.LFD.1.10.0812051847380.30731@newtla.xelerance.com>

> I got some strange IM from someone. Halfway through  figure out we've been 
> setup
> somehow with a relay in the middle and both of us see the other as some other
> identity. When the person says he is using adium, I thought it was a perfect
> chance to fire up OTR to see what would happen with this MITM scenario....
> Funny enough, it revealed the identity of the other user to me :)

Seems it is some social experiment:

http://www.google.com/search?hl=en&q=aim+coho&btnG=Search

Paul


From cognitive.libertarian+ml at gmail.com  Sat Dec  6 17:28:35 2008
From: cognitive.libertarian+ml at gmail.com (cognitive.libertarian+ml at gmail.com)
Date: Sat, 6 Dec 2008 23:28:35 +0100
Subject: [OTR-users] Initiating OTR from an irssi client to pidgin
In-Reply-To: <20081202100222.GA7784@gmail.com>
References: <20081129235350.GA13711@lenny.local>
	<20081201114329.GA8316@gmail.com>
	<20081201184235.GA4855@lenny.local>
	<20081202100222.GA7784@gmail.com>
Message-ID: <20081206222835.GB4740@lenny.local>

* Uli M <a.sporto+bee at gmail.com> [2008-12-02 18:30]:
> 
> The first message is indeed always plaintext. Usually, you'll just
> have to wait a few seconds after that until the OTR session
> starts. However, if no key exists then this first message will
> trigger key generation (check the status window) which takes some
> time and will also make another plaintext message neccessary.  Just
> wait till generation finishes, write another message and wait a few
> seconds. Then you should go secure.

It doesn't work.  I waited an hour, and my modern processor should not
take too long to generate a key.

> irssi-otr itself has no idea about ICQ stuff, that's made
> transparent by bitlbee. You'll have to use <irc-nick>@<irc-server>
> as accountname for generation, also see the README or "/otr help" or
> just let irssi-otr do the right thing.

I'm not quite clear on what to use for <irc-server>.  /server shows a
list of servers, one of which is "bitlbee". So I tried:

   /otr genkey <irc nick>@bitlbee

It generated a key, but I still cannot initiate an OTR session.
Although I expect a key to already exist, because OTR has worked the
other user initiates.

These are the versions:

irssi       0.8.10
bitlbee     1.0.3
otr plugin  0.2
otr library 3.2.0


From a.sporto+bee at gmail.com  Tue Dec  9 12:48:05 2008
From: a.sporto+bee at gmail.com (Uli M)
Date: Tue, 9 Dec 2008 18:48:05 +0100
Subject: [OTR-users] Initiating OTR from an irssi client to pidgin
In-Reply-To: <20081206222835.GB4740@lenny.local>
References: <20081129235350.GA13711@lenny.local>
	<20081201114329.GA8316@gmail.com>
	<20081201184235.GA4855@lenny.local>
	<20081202100222.GA7784@gmail.com>
	<20081206222835.GB4740@lenny.local>
Message-ID: <20081209174804.GB8675@gmail.com>

On Sat 06.12.08 23:28, cognitive.libertarian+ml at gmail.com wrote:
> * Uli M <a.sporto+bee at gmail.com> [2008-12-02 18:30]:
> > 
> > The first message is indeed always plaintext. Usually, you'll just
> > have to wait a few seconds after that until the OTR session
> > starts. However, if no key exists then this first message will
> > trigger key generation (check the status window) which takes some
> > time and will also make another plaintext message neccessary.  Just
> > wait till generation finishes, write another message and wait a few
> > seconds. Then you should go secure.
> 
> It doesn't work.  I waited an hour, and my modern processor should not
> take too long to generate a key.

Did you see a message in the status window indicating that key generation is
in progress? Did you check if there is a second irssi process running as the
message suggested?

By the way the length of the time period is not so much about processing power
and more about entropy. So for example a "du /" in the background will greatly
speed up key generation.

> 
> > irssi-otr itself has no idea about ICQ stuff, that's made
> > transparent by bitlbee. You'll have to use <irc-nick>@<irc-server>
> > as accountname for generation, also see the README or "/otr help" or
> > just let irssi-otr do the right thing.
> 
> I'm not quite clear on what to use for <irc-server>.  /server shows a
> list of servers, one of which is "bitlbee". So I tried:
> 
>    /otr genkey <irc nick>@bitlbee

You should use the same hostname as you gave to /connect. /server shows the
network name first and then <server>:<port>, be careful not to mix that up. If
you're running a local bitlbee server then its hostname is most likely
localhost.

> It generated a key, but I still cannot initiate an OTR session.
> Although I expect a key to already exist, because OTR has worked the
> other user initiates.

If OTR works when the other end initiates then you definitely have a key
already. That you can't initiate an OTR session just by typing something might
also have something to do with the settings of the other guy...what you can try
is to write ?OTR?, that should force the start of a session.

> 
> These are the versions:
> 
> irssi       0.8.10
> bitlbee     1.0.3

I'd upgrade bitlbee, latest stable is 1.2.3, 1.0 is ancient.

Uli


From michael_reichenbach at freenet.de  Tue Dec  9 16:04:09 2008
From: michael_reichenbach at freenet.de (Michael Reichenbach)
Date: Tue, 09 Dec 2008 22:04:09 +0100
Subject: [OTR-users] What do you suggest for non-real-time messages?
Message-ID: <493EDD49.90500@freenet.de>

Encryption & Authentication are most important for me and Deniability &
Perfect forward secrecy are nice give-away.

To chat with my friends I prefer using OTR. For communication with
business partners OTR would be a bad choice because you need to have a
prove after conversation who had said what.

But because OTR is for non-business communications I am asking what to
use for non-real-time messages with friends.

A non-real-time message is needed when the buddy is currently not online
but I want to leave the recipient a message so the recipient reading it
the next time he goes online. (Real-time is normal instant messages,
don't know a better term for what I am talking about.)

I could use E-Mail and OpenPGP. But...
- It does not provide Deniability & Perfect forward secrecy, only
Encryption & Authentication.
- And the even more worse reason not to use it: it's very uncomfortable.
In my generation we prefer to talk to each other to use instant
messengers because them are more fast and practical, as soon you go
online you see who's online and who's not and you maybe get some
messages from your "mailbox" (messages send as you where offline). It's
really preferred over E-Mail. (Yes, it's arguable and a matter of task.)
- It's very impractical to chat over to systems (for example, Pidgin &
OTR + E-Mail & OpenPGP), two conversation lines and bad integration into
each other (history) and two needs to authenticate.

That's the big derivation why I want to use OTR also for non-real-time
communication.

Can you tell me this feature will ever come into OTR?

Or what else can you recommend me to use?

best regards,
-mr


From ian at cypherpunks.ca  Wed Dec 10 09:51:50 2008
From: ian at cypherpunks.ca (Ian Goldberg)
Date: Wed, 10 Dec 2008 09:51:50 -0500
Subject: [OTR-users] What do you suggest for non-real-time messages?
In-Reply-To: <493EDD49.90500@freenet.de>
References: <493EDD49.90500@freenet.de>
Message-ID: <20081210145150.GC27690@thunk.cs.uwaterloo.ca>

On Tue, Dec 09, 2008 at 10:04:09PM +0100, Michael Reichenbach wrote:
> Encryption & Authentication are most important for me and Deniability &
> Perfect forward secrecy are nice give-away.
> 
> To chat with my friends I prefer using OTR. For communication with
> business partners OTR would be a bad choice because you need to have a
> prove after conversation who had said what.
> 
> But because OTR is for non-business communications I am asking what to
> use for non-real-time messages with friends.
> 
> A non-real-time message is needed when the buddy is currently not online
> but I want to leave the recipient a message so the recipient reading it
> the next time he goes online. (Real-time is normal instant messages,
> don't know a better term for what I am talking about.)
> 
> I could use E-Mail and OpenPGP. But...
> - It does not provide Deniability & Perfect forward secrecy, only
> Encryption & Authentication.
> - And the even more worse reason not to use it: it's very uncomfortable.
> In my generation we prefer to talk to each other to use instant
> messengers because them are more fast and practical, as soon you go
> online you see who's online and who's not and you maybe get some
> messages from your "mailbox" (messages send as you where offline). It's
> really preferred over E-Mail. (Yes, it's arguable and a matter of task.)
> - It's very impractical to chat over to systems (for example, Pidgin &
> OTR + E-Mail & OpenPGP), two conversation lines and bad integration into
> each other (history) and two needs to authenticate.
> 
> That's the big derivation why I want to use OTR also for non-real-time
> communication.
> 
> Can you tell me this feature will ever come into OTR?
> 
> Or what else can you recommend me to use?

There's a fundamental problem with trying to get perfect forward secrecy
along with offline communication: if your buddy is disconnected, and
perhaps off, with no transient state, but only long-term secrets, and he
can still (later, when he comes back online) read the messages you send
him, then the long-term secret was sufficient to read the message.  This
is antithetical to perfect forward secrecy.  So at a minimum, your
long-term secrets need to change regularly, and there needs to be some
way to communicate them (in an authentic manner) to your buddies, while
you're offline.

On the other side, one can make at least some progress with offline
deniability using techniques like ring signatures (see the original OTR
paper).  But since the perfect forward secrecy issues are much greater,
this isn't implemented.

   - Ian


From michael_reichenbach at freenet.de  Thu Dec 11 11:02:34 2008
From: michael_reichenbach at freenet.de (Michael Reichenbach)
Date: Thu, 11 Dec 2008 17:02:34 +0100
Subject: [OTR-users] OTR limitations
In-Reply-To: <20081210145150.GC27690@thunk.cs.uwaterloo.ca>
References: <493EDD49.90500@freenet.de>
	<20081210145150.GC27690@thunk.cs.uwaterloo.ca>
Message-ID: <4941399A.60201@freenet.de>

I see two major problems with OTR:

1) no way to encrypt offline messages

2) And even more worse: if you connection is a bit unstable (mobile
connection) and you are offline for a short time while a buddy is
sending a message this message is simply lost in nirvana without any
warnings. Normaly the jabber server works like a mailbox, I may accept
that there will never come support for offline messages but that
messages just get dropped without notice is not acceptable.

Now I am looking for a less error prone solution.


From js-otrim at webkeks.org  Thu Dec 11 12:19:47 2008
From: js-otrim at webkeks.org (Jonathan Schleifer)
Date: Thu, 11 Dec 2008 18:19:47 +0100
Subject: [OTR-users] OTR limitations
In-Reply-To: <4941399A.60201@freenet.de>
References: <493EDD49.90500@freenet.de>
	<20081210145150.GC27690@thunk.cs.uwaterloo.ca>
	<4941399A.60201@freenet.de>
Message-ID: <15108EAF-A7B3-4B2F-969C-6548375D5BD6@webkeks.org>

Am 11.12.2008 um 17:02 schrieb Michael Reichenbach:

> 2) And even more worse: if you connection is a bit unstable (mobile
> connection) and you are offline for a short time while a buddy is
> sending a message this message is simply lost in nirvana without any
> warnings. Normaly the jabber server works like a mailbox, I may accept
> that there will never come support for offline messages but that
> messages just get dropped without notice is not acceptable.

It's not silently lost. If a single message is lost, the next message  
can't be decrypted and the session is reestablished and the old  
message resent.

--
Jonathan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <http://lists.cypherpunks.ca/pipermail/otr-users/attachments/20081211/9f158bd5/attachment.pgp>

From paul at cypherpunks.ca  Fri Dec 12 12:58:50 2008
From: paul at cypherpunks.ca (Paul Wouters)
Date: Fri, 12 Dec 2008 12:58:50 -0500 (EST)
Subject: [OTR-users] OTR limitations
In-Reply-To: <4941399A.60201@freenet.de>
References: <493EDD49.90500@freenet.de>
	<20081210145150.GC27690@thunk.cs.uwaterloo.ca>
	<4941399A.60201@freenet.de>
Message-ID: <alpine.LFD.1.10.0812121257080.17817@newtla.xelerance.com>

On Thu, 11 Dec 2008, Michael Reichenbach wrote:

> I see two major problems with OTR:
>
> 1) no way to encrypt offline messages

I don't use voice mail either :)

> 2) And even more worse: if you connection is a bit unstable (mobile
> connection) and you are offline for a short time while a buddy is
> sending a message this message is simply lost in nirvana without any
> warnings. Normaly the jabber server works like a mailbox, I may accept
> that there will never come support for offline messages but that
> messages just get dropped without notice is not acceptable.

That's not true. If your connection goes up or down, OTR still works fine.
Even if you miss a message, it will resync the crypto.

Paul


From perrin at apotheon.com  Fri Dec 12 16:27:16 2008
From: perrin at apotheon.com (Chad Perrin)
Date: Fri, 12 Dec 2008 14:27:16 -0700
Subject: [OTR-users] OTR limitations
In-Reply-To: <alpine.LFD.1.10.0812121257080.17817@newtla.xelerance.com>
References: <493EDD49.90500@freenet.de>
	<20081210145150.GC27690@thunk.cs.uwaterloo.ca>
	<4941399A.60201@freenet.de>
	<alpine.LFD.1.10.0812121257080.17817@newtla.xelerance.com>
Message-ID: <20081212212716.GG37185@kokopelli.hydra>

On Fri, Dec 12, 2008 at 12:58:50PM -0500, Paul Wouters wrote:
> On Thu, 11 Dec 2008, Michael Reichenbach wrote:
> 
> >I see two major problems with OTR:
> >
> >1) no way to encrypt offline messages
> 
> I don't use voice mail either :)
> 
> >2) And even more worse: if you connection is a bit unstable (mobile
> >connection) and you are offline for a short time while a buddy is
> >sending a message this message is simply lost in nirvana without any
> >warnings. Normaly the jabber server works like a mailbox, I may accept
> >that there will never come support for offline messages but that
> >messages just get dropped without notice is not acceptable.
> 
> That's not true. If your connection goes up or down, OTR still works fine.
> Even if you miss a message, it will resync the crypto.

To be perfectly fair, I feel I should note that while it typically does
so, there have been times it has not -- and this appears to be a problem
more often with some of my contacts than with others.

-- 
Chad Perrin [ content licensed OWL: http://owl.apotheon.org ]
Quoth Larry Wall: "What is the sound of Perl?  Is it not the sound of a
wall that people have stopped banging their heads against?"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://lists.cypherpunks.ca/pipermail/otr-users/attachments/20081212/40869a0e/attachment.pgp>

From atlanx at focx.de  Thu Dec 18 11:30:42 2008
From: atlanx at focx.de (Markus Stadler)
Date: Thu, 18 Dec 2008 17:30:42 +0100
Subject: [OTR-users] Problem with "Authenticate buddy"
Message-ID: <494A7AB2.3060401@focx.de>

Hello :)

I'm using the pidgin-otr-3.2.0 plugin with pidgin 2.5.2(Windows)

If I try to authenticate my friend with "Question and answer" where

I have to enter a "Question" and an "secret answer" but if
I hit the "Authenticate" button my friend gets only an form which
says he should input the "secret answer".

But he does not get the "Question".

What I'm making wrong?

Thank you for your help.

Markus.


From ian at cypherpunks.ca  Thu Dec 18 20:10:19 2008
From: ian at cypherpunks.ca (Ian Goldberg)
Date: Thu, 18 Dec 2008 20:10:19 -0500
Subject: [OTR-users] Problem with "Authenticate buddy"
In-Reply-To: <494A7AB2.3060401@focx.de>
References: <494A7AB2.3060401@focx.de>
Message-ID: <20081219011019.GI6251@yoink.cs.uwaterloo.ca>

On Thu, Dec 18, 2008 at 05:30:42PM +0100, Markus Stadler wrote:
> Hello :)
>
> I'm using the pidgin-otr-3.2.0 plugin with pidgin 2.5.2(Windows)
>
> If I try to authenticate my friend with "Question and answer" where
>
> I have to enter a "Question" and an "secret answer" but if
> I hit the "Authenticate" button my friend gets only an form which
> says he should input the "secret answer".
>
> But he does not get the "Question".
>
> What I'm making wrong?

Weird.  What versions of pidgin and pidgin-otr are your friend using?

   - Ian


From jwittlincohen at gmail.com  Tue Dec 23 07:08:52 2008
From: jwittlincohen at gmail.com (Jason Wittlin-Cohen)
Date: Tue, 23 Dec 2008 07:08:52 -0500
Subject: [OTR-users] Problematic OTR behavior
Message-ID: <4950D4D4.2010903@gmail.com>

Dear List,

I have been quite interested in OTR for some time and have used it off
and on for several years. I used pidgin-otr-3.2.0 over a period of three
months with my girlfriend but finally migrated to Pidgin-Encryption due
to several usability problems that led my girlfriend to consistently
complain about the software. I prefer OTR due to its deniability and
perfect forward secrecy features but OTR is simply too intrusive for the
average user. After reading "A User Study of Off-the-Record Messaging" I
have decided to share my opinions. Hopefully they will be of some use.


    *1. OTR's behavior is inconsistent and suboptimal when the following
    occur:*

1. User A and B establish a private OTR conversation.
2. User A logs off.
3. User A logs logs back on before User B logs off or manually ends the
private conversation.
4. User B sends user A a message.*
*


      *Scenario A (more likely scenario):*

1. User A and B establish a private OTR conversation
2. User A logs off (closes Pidgin). Pidgin informs User B that User A
logged off but the conversation remains in "Private" mode.
3. User A logs logs back on before User B logs off or manually ends the
private conversation.
4. User B sends A a message and receives a string of messages (see below)
  
   User B: Hello
    (5:23:01 AM) OTR Error: You sent encrypted data to User A, who
wasn't expecting it.
    (5:23:02 AM) Successfully refreshed the private conversation with
User A.
    (5:23:02 AM) Suco last message to User A was resent.

5. User B receives the following messages from OTR before receiving the
message from User A.

User B: The encrypted message received from User B is unreadable, as you
are not currently communicating  privately.
 (05:23:07 AM) Private conversation with User B started.
  (05:23:07 AM)   User B: [resent] Hello

*Expected Result:*

User B expects that when User A logs off, the private conversation will
be terminated (Not Private). When User A logs back on, User B expects
that OTR will indicate that there is no current private conversation and
that OTR's global or per-user settings will be used to decide whether or
not the message must, or simply can be encrypted. If for example, User B
set OTR to "Always Encrypt" then no messages will be sent to User A
unless encrypted. If User B automatically initiates encryption but
doesn't require it, then User B will still be able to communicate with
User A if he logs on using an IM client that doesn't  support OTR. In
addition, because the prior private conversation was terminated when
User A logged off, User B will not be sent any warning messages.

User A expects to receive messages properly when he logs back in without
receiving warnings about unreadable messages.

/There are two main problems with the current situation:/

1) The private conversation is not terminated when User B logs off.
Thus, if User A logs on with a chat client that doesn't support OTR he
will be greeted with encrypted gibberish.
2) Despite the fact that the private conversation can be re-established
without difficulty, both User A and User B are inundated with
unnecessary and bothersome messages. These messages clutter the IM box
and provide little useful information. As a regular user that expects
his IM client to "just work", why do I care that the encrypted session
had to be restarted or that the message had to be resent? There was no
fatal error. I don't want to receive any unnecessary output that I a)
don't care about and b) probably don't understand (Will the average user
know or care why the message was unreadable?). At the very least, there
ought to be a way to disable the messages. More advanced users can then
choose to continue viewing the verbose output.

*Pidgin-Encryption Behavior:
*
1. User A and B establish a secure conversation.
2. User A logs off.
3. User A logs logs back on before User B logs off or manually ends the
secure conversation. (un-checking the lock icon)
4. User B sends user A a message. User B receives a one line warning
message:
"Last message not received properly - resetting"
5. User B resends the message
6. User A receives the message and no warning.

Pidgin-Encryption is not optimal in that it doesn't automatically resend
the message, however it doesn't bother User A with unnecessary
information (he merely receives User B's message), and User B is sent a
one line message informing him that the message was not sent properly,
inducing him to resend the message. In addition, User B is not forced to
manually refresh the connection as in the Scenario B.*
*


      *Scenario B (less likely scenario):*

1. User A and B establish a private OTR conversation
2. User A logs off (closes Pidgin). Pidgin informs User B that User A
logged off and that he has ended his private conversation with User B.
User B is told to do the same. (Note: User A did not manually end the
private connection.)

*(5:54:08 AM)* User A has ended his/her private conversation with you;
you should do the same.

3. User A logs logs back on before User B logs off or manually ends the
private conversation.
4. User B sends A a message and receives a warning telling him that his
message was NOT sent and that he either should end the private
conversation or refresh it.

Your message was not sent. Either end your private conversation, or
restart it.

5. User B must manually restarts the connection before sending his message.

Private conversation with User A started.
User B: Hello
  
6. User A receives a message stating that a private conversation was
started as well as the message from user B.

(05:23:07 AM) Private conversation with User B started.
  (05:23:07 AM)   User B: Hello

*Expected Result: *Same as above

*Problems with this Result: *User A simply disconnected his chat
session. He never manually ended the private conversation. OTR should
notify him that the conversation is over but then it should rely on the
user's global or per-user OTR settings as to compulsory or optional
encryption to decide how to proceed. There is no reason that User B
should be required to manually restart the private conversation. This is
not only unnecessary; it's extremely annoying. Clicking the OTR button
isn't sufficient. The user must click the OTR button and then select
"Start Private Conversation". OTR should be a transparent solution. Once
the user authenticates his buddy, he should be informed the state of the
connection, and ought to be bothered as little as possible. The more
intrusive OTR is, the less likely regular users will be willing to use it.

The average user just wants to send a message to his friend. He
certainly doesn't want to have to manually refresh the connection.
Informing the user that the conversation is no longer private after User
A logs off should be sufficient to notify B that the connection is no
longer secure and that he shouldn't send anything sensitive without
first ensuring the conversation has been refreshed. While requiring User
B to manually restart the conversation may prevent him from
inadvertently transmitting sensitive information, it does so at a high
cost. He may be dissuaded from using OTR in the future due to its
intrusiveness.

*Pidgin-Encryption Behavior: *Same as above. This problem doesn't occur.


    *2) Repeated messages about unreadable messages.*

I believe this is a result of one user logging on in two different
locations, but it may be an unrelated issue. I was never able to pin
down the root cause. Do to the inability to solve the issue without
restarting Pidgin, this was a major reason why we moved to
Pidgin-Encryption. I have not encountered this issue with
Pidgin-Encryption. Here is what occurs:

1. User A and B establish a private OTR conversation.
2. User A logs off.
3. User A logs logs back on before User B logs off or manually ends the
private conversation.
4. User B sends user A a message.
5. User A and B are both inundated by repeated and continuous warnings
about  unreadable messages. Refreshing the conversation does not work.
The only way to resolve the problem is to restart Pidgin.

*Pidgin-Encryption Behavior: *This has never occured in
Pidgin-Encryption. I have only encountered two annoyances in
Pidgin-Encryption:

1. The "Last Outgoing Message Not Received Properly - Resetting" message
informing the user to resend the message - rather than doing so
automatically.
2. If User A logs in on a client that doesn't support pidgin-encryption,
he receives a warning that Pidgin-Encryption has been used to encrypt
the message. This is certainly better than receiving the full encrypted
output which is what happens in an analogous situation with OTR. The
solution is for User B to uncheck the lock icon.

Pidgin-Encryption isn't perfect but my girlfriend much prefers it to OTR
for the simple reason that it is unobtrusive and doesn't bother her with
annoying messages she doesn't care about. She knows that if she receives
the "resetting" warning she just has to resend the message. She prefers
this to the repeated unreadable message problem and the verbose output
spit out by OTR. Pidgin-Encryption relies solely upon the lock icons for
an indication of the security of the connection (after the user's key is
authenticated). It does not output text when a secure connection has
been established nor when a session has ended. In its minimalist
approach, Pidgin-Encryption is able to achieve far more of a transparent
encryption solution. If the lock icons are green, and the user has been
authenticated, the conversation is secure. If not, it isn't. Normally
pidgin-encryption works without outputting any warnings or informational
messages. Since such messages are in my opinion unnecessary because the
user can rely on the less obtrusive and more user-friendly icons. Since
the OTR button informs the user of the state of the connection, I feel
that there should also be a way to disable OTR's informational messages.


      Conclusion:

1. When User A disconnects, User B should be informed that the
connection has been terminated.
    - IfUser A reconnects with a client that supports OTR, a new
connection should be established as normal.
    - If User A reconnects using a client that doesn't support OTR, User
B should still be able to communicate so long as he has not enabled
mandatory encryption. User A should not receive encrypted text.
2. There should be an option to disable informational messages and
warning messages that are not necessary to the security or functionality
of OTR.
3. The user should not be prevented from sending a message unencrypted
unless he has enabled mandatory encryption. The OTR button should inform
the user of the state of the connection. Requiring the user to manually
refresh the connection (requiring two mouse clicks) is user-unfriendly
and very obtrusive.
4. OTR should support chats where one user is logged on in multiple
locations or fail gracefully without the repeated warning messages. (if
this in fact not an unrelated issue. I'm not certain on this point.)

Regards,

Jason Wittlin-Cohen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cypherpunks.ca/pipermail/otr-users/attachments/20081223/13b73f10/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 550 bytes
Desc: OpenPGP digital signature
URL: <http://lists.cypherpunks.ca/pipermail/otr-users/attachments/20081223/13b73f10/attachment.pgp>

From jwittlincohen at gmail.com  Tue Dec 23 09:43:57 2008
From: jwittlincohen at gmail.com (Jason Wittlin-Cohen)
Date: Tue, 23 Dec 2008 09:43:57 -0500
Subject: [OTR-users] Problematic OTR behavior
In-Reply-To: <4950D4D4.2010903@gmail.com>
References: <4950D4D4.2010903@gmail.com>
Message-ID: <4950F92D.7090106@gmail.com>

Jason Wittlin-Cohen wrote:
> Dear List,
>
> I have been quite interested in OTR for some time and have used it off
> and on for several years. I used pidgin-otr-3.2.0 over a period of
> three months with my girlfriend but finally migrated to
> Pidgin-Encryption due to several usability problems that led my
> girlfriend to consistently complain about the software. I prefer OTR
> due to its deniability and perfect forward secrecy features but OTR is
> simply too intrusive for the average user. After reading "A User Study
> of Off-the-Record Messaging" I have decided to share my opinions.
> Hopefully they will be of some use.
>
>
>     *1. OTR's behavior is inconsistent and suboptimal when the
>     following occur:*
>
> 1. User A and B establish a private OTR conversation.
> 2. User A logs off.
> 3. User A logs logs back on before User B logs off or manually ends
> the private conversation.
> 4. User B sends user A a message.*
> *
>
>
>       *Scenario A (more likely scenario):*
>
> 1. User A and B establish a private OTR conversation
> 2. User A logs off (closes Pidgin). Pidgin informs User B that User A
> logged off but the conversation remains in "Private" mode.
> 3. User A logs logs back on before User B logs off or manually ends
> the private conversation.
> 4. User B sends A a message and receives a string of messages (see below)
>   
>    User B: Hello
>     (5:23:01 AM) OTR Error: You sent encrypted data to User A, who
> wasn't expecting it.
>     (5:23:02 AM) Successfully refreshed the private conversation with
> User A.
>     (5:23:02 AM) Suco last message to User A was resent.
>
> 5. User B receives the following messages from OTR before receiving
> the message from User A.
>
> User B: The encrypted message received from User B is unreadable, as
> you are not currently communicating  privately.
>  (05:23:07 AM) Private conversation with User B started.
>   (05:23:07 AM)   User B: [resent] Hello
>
> *Expected Result:*
>
> User B expects that when User A logs off, the private conversation
> will be terminated (Not Private). When User A logs back on, User B
> expects that OTR will indicate that there is no current private
> conversation and that OTR's global or per-user settings will be used
> to decide whether or not the message must, or simply can be encrypted.
> If for example, User B set OTR to "Always Encrypt" then no messages
> will be sent to User A unless encrypted. If User B automatically
> initiates encryption but doesn't require it, then User B will still be
> able to communicate with User A if he logs on using an IM client that
> doesn't  support OTR. In addition, because the prior private
> conversation was terminated when User A logged off, User B will not be
> sent any warning messages.
>
> User A expects to receive messages properly when he logs back in
> without receiving warnings about unreadable messages.
>
> /There are two main problems with the current situation:/
>
> 1) The private conversation is not terminated when User B logs off.
> Thus, if User A logs on with a chat client that doesn't support OTR he
> will be greeted with encrypted gibberish.
> 2) Despite the fact that the private conversation can be
> re-established without difficulty, both User A and User B are
> inundated with unnecessary and bothersome messages. These messages
> clutter the IM box and provide little useful information. As a regular
> user that expects his IM client to "just work", why do I care that the
> encrypted session had to be restarted or that the message had to be
> resent? There was no fatal error. I don't want to receive any
> unnecessary output that I a) don't care about and b) probably don't
> understand (Will the average user know or care why the message was
> unreadable?). At the very least, there ought to be a way to disable
> the messages. More advanced users can then choose to continue viewing
> the verbose output.
>
> *Pidgin-Encryption Behavior:
> *
> 1. User A and B establish a secure conversation.
> 2. User A logs off.
> 3. User A logs logs back on before User B logs off or manually ends
> the secure conversation. (un-checking the lock icon)
> 4. User B sends user A a message. User B receives a one line warning
> message:
> "Last message not received properly - resetting"
> 5. User B resends the message
> 6. User A receives the message and no warning.
>
> Pidgin-Encryption is not optimal in that it doesn't automatically
> resend the message, however it doesn't bother User A with unnecessary
> information (he merely receives User B's message), and User B is sent
> a one line message informing him that the message was not sent
> properly, inducing him to resend the message. In addition, User B is
> not forced to manually refresh the connection as in the Scenario B.*
> *
>
>
>       *Scenario B (less likely scenario):*
>
> 1. User A and B establish a private OTR conversation
> 2. User A logs off (closes Pidgin). Pidgin informs User B that User A
> logged off and that he has ended his private conversation with User B.
> User B is told to do the same. (Note: User A did not manually end the
> private connection.)
>
> *(5:54:08 AM)* User A has ended his/her private conversation with you;
> you should do the same.
>
> 3. User A logs logs back on before User B logs off or manually ends
> the private conversation.
> 4. User B sends A a message and receives a warning telling him that
> his message was NOT sent and that he either should end the private
> conversation or refresh it.
>
> Your message was not sent. Either end your private conversation, or
> restart it.
>
> 5. User B must manually restarts the connection before sending his
> message.
>
> Private conversation with User A started.
> User B: Hello
>   
> 6. User A receives a message stating that a private conversation was
> started as well as the message from user B.
>
> (05:23:07 AM) Private conversation with User B started.
>   (05:23:07 AM)   User B: Hello
>
> *Expected Result: *Same as above
>
> *Problems with this Result: *User A simply disconnected his chat
> session. He never manually ended the private conversation. OTR should
> notify him that the conversation is over but then it should rely on
> the user's global or per-user OTR settings as to compulsory or
> optional encryption to decide how to proceed. There is no reason that
> User B should be required to manually restart the private
> conversation. This is not only unnecessary; it's extremely annoying.
> Clicking the OTR button isn't sufficient. The user must click the OTR
> button and then select "Start Private Conversation". OTR should be a
> transparent solution. Once the user authenticates his buddy, he should
> be informed the state of the connection, and ought to be bothered as
> little as possible. The more intrusive OTR is, the less likely regular
> users will be willing to use it.
>
> The average user just wants to send a message to his friend. He
> certainly doesn't want to have to manually refresh the connection.
> Informing the user that the conversation is no longer private after
> User A logs off should be sufficient to notify B that the connection
> is no longer secure and that he shouldn't send anything sensitive
> without first ensuring the conversation has been refreshed. While
> requiring User B to manually restart the conversation may prevent him
> from inadvertently transmitting sensitive information, it does so at a
> high cost. He may be dissuaded from using OTR in the future due to its
> intrusiveness.
>
> *Pidgin-Encryption Behavior: *Same as above. This problem doesn't occur.
>
>
>     *2) Repeated messages about unreadable messages.*
>
> I believe this is a result of one user logging on in two different
> locations, but it may be an unrelated issue. I was never able to pin
> down the root cause. Do to the inability to solve the issue without
> restarting Pidgin, this was a major reason why we moved to
> Pidgin-Encryption. I have not encountered this issue with
> Pidgin-Encryption. Here is what occurs:
>
> 1. User A and B establish a private OTR conversation.
> 2. User A logs off.
> 3. User A logs logs back on before User B logs off or manually ends
> the private conversation.
> 4. User B sends user A a message.
> 5. User A and B are both inundated by repeated and continuous warnings
> about  unreadable messages. Refreshing the conversation does not work.
> The only way to resolve the problem is to restart Pidgin.
>
> *Pidgin-Encryption Behavior: *This has never occured in
> Pidgin-Encryption. I have only encountered two annoyances in
> Pidgin-Encryption:
>
> 1. The "Last Outgoing Message Not Received Properly - Resetting"
> message informing the user to resend the message - rather than doing
> so automatically.
> 2. If User A logs in on a client that doesn't support
> pidgin-encryption, he receives a warning that Pidgin-Encryption has
> been used to encrypt the message. This is certainly better than
> receiving the full encrypted output which is what happens in an
> analogous situation with OTR. The solution is for User B to uncheck
> the lock icon.
>
> Pidgin-Encryption isn't perfect but my girlfriend much prefers it to
> OTR for the simple reason that it is unobtrusive and doesn't bother
> her with annoying messages she doesn't care about. She knows that if
> she receives the "resetting" warning she just has to resend the
> message. She prefers this to the repeated unreadable message problem
> and the verbose output spit out by OTR. Pidgin-Encryption relies
> solely upon the lock icons for an indication of the security of the
> connection (after the user's key is authenticated). It does not output
> text when a secure connection has been established nor when a session
> has ended. In its minimalist approach, Pidgin-Encryption is able to
> achieve far more of a transparent encryption solution. If the lock
> icons are green, and the user has been authenticated, the conversation
> is secure. If not, it isn't. Normally pidgin-encryption works without
> outputting any warnings or informational messages. Since such messages
> are in my opinion unnecessary because the user can rely on the less
> obtrusive and more user-friendly icons. Since the OTR button informs
> the user of the state of the connection, I feel that there should also
> be a way to disable OTR's informational messages.
>
>
>       Conclusion:
>
> 1. When User A disconnects, User B should be informed that the
> connection has been terminated.
>     - IfUser A reconnects with a client that supports OTR, a new
> connection should be established as normal.
>     - If User A reconnects using a client that doesn't support OTR,
> User B should still be able to communicate so long as he has not
> enabled mandatory encryption. User A should not receive encrypted text.
> 2. There should be an option to disable informational messages and
> warning messages that are not necessary to the security or
> functionality of OTR.
> 3. The user should not be prevented from sending a message unencrypted
> unless he has enabled mandatory encryption. The OTR button should
> inform the user of the state of the connection. Requiring the user to
> manually refresh the connection (requiring two mouse clicks) is
> user-unfriendly and very obtrusive.
> 4. OTR should support chats where one user is logged on in multiple
> locations or fail gracefully without the repeated warning messages.
> (if this in fact not an unrelated issue. I'm not certain on this point.)
>
> Regards,
>
> Jason Wittlin-Cohen
>From reading the documentation, it appears that the expected behavior of
OTR is to change the conversation state to "Finished" when your chat
buddy logs off. However, for me, the conversation status remains
"Private" more often than not. What would cause such inconsistency? I am
testing with Pidgin 2.5.2 and pidgin-otr 3.2.0 on Ubuntu 8.10 and Pidgin
2.5.3 and pidgin-otr 3.2.0 on Windows XP SP3.

Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cypherpunks.ca/pipermail/otr-users/attachments/20081223/2943c09b/attachment.html>

From jwittlincohen at gmail.com  Tue Dec 23 09:47:51 2008
From: jwittlincohen at gmail.com (Jason Wittlin-Cohen)
Date: Tue, 23 Dec 2008 09:47:51 -0500
Subject: [OTR-users] Problematic OTR behavior
In-Reply-To: <4950F92D.7090106@gmail.com>
References: <4950D4D4.2010903@gmail.com> <4950F92D.7090106@gmail.com>
Message-ID: <4950FA17.7080009@gmail.com>

Huh. The last e-mail I sent showed only the quoted text and omitted my
reply. Let's try that once more:

>From reading the documentation, it appears that the expected behavior of
OTR is to change the conversation state to "Finished" when your chat
buddy logs off. However, for me, the conversation status remains
"Private" more often than not. What would cause such inconsistency? I am
testing with Pidgin 2.5.2 and pidgin-otr 3.2.0 on Ubuntu 8.10 and Pidgin
2.5.3 and pidgin-otr 3.2.0 on Windows XP SP3.

Jason




From jwittlincohen at gmail.com  Tue Dec 23 09:54:12 2008
From: jwittlincohen at gmail.com (Jason Wittlin-Cohen)
Date: Tue, 23 Dec 2008 09:54:12 -0500
Subject: [OTR-users] Problematic OTR behavior
Message-ID: <d2af01610812230654r48909999w89b32d024fc3ab73@mail.gmail.com>

Huh. This is very odd. The message source in Thunderbird shows the entire
message but it's clearly getting truncated on the list archive. Perhaps
sending from GMail will work-

>From reading the documentation, it appears that the expected behavior of
OTR is to change the conversation state to "Finished" when your chat
buddy logs off. However, for me, the conversation status remains
"Private" more often than not. What would cause such inconsistency? I am
testing with Pidgin 2.5.2 and pidgin-otr 3.2.0 on Ubuntu 8.10 and Pidgin
2.5.3 and pidgin-otr 3.2.0 on Windows XP SP3.

Jason

-- 
Jason Wittlin-Cohen
Yale Law School, Class of 2010
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cypherpunks.ca/pipermail/otr-users/attachments/20081223/728f3bfd/attachment.html>

From perrin at apotheon.com  Tue Dec 23 15:57:16 2008
From: perrin at apotheon.com (Chad Perrin)
Date: Tue, 23 Dec 2008 13:57:16 -0700
Subject: [OTR-users] Problematic OTR behavior
In-Reply-To: <d2af01610812230654r48909999w89b32d024fc3ab73@mail.gmail.com>
References: <d2af01610812230654r48909999w89b32d024fc3ab73@mail.gmail.com>
Message-ID: <20081223205716.GA29341@kokopelli.hydra>

On Tue, Dec 23, 2008 at 09:54:12AM -0500, Jason Wittlin-Cohen wrote:
> Huh. This is very odd. The message source in Thunderbird shows the entire
> message but it's clearly getting truncated on the list archive. Perhaps
> sending from GMail will work-

Actually, I saw your reply text on all three, using  1.4.2.3i on FreeBSD.

Perhaps you just overlooked your reply text on the first copy because it
was lost at the end of the incredibly huge, and largely unnecessary full
quote of the preceding email.

Maybe you're viewing HTML emails, and your mail client is hiding your
response for some reason.

It may be some other reason entirely, but regardless, I saw the reply
text even if you did not.

-- 
Chad Perrin [ content licensed OWL: http://owl.apotheon.org ]
Quoth Antony Jay: "In corporate religions as in others, the heretic must
be cast out not because of the probability that he is wrong but because
of the possibility that he is right."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://lists.cypherpunks.ca/pipermail/otr-users/attachments/20081223/4da9755b/attachment.pgp>

From jwittlincohen at gmail.com  Tue Dec 23 17:21:31 2008
From: jwittlincohen at gmail.com (Jason Wittlin-Cohen)
Date: Tue, 23 Dec 2008 17:21:31 -0500
Subject: [OTR-users] Problematic OTR behavior
In-Reply-To: <20081223205716.GA29341@kokopelli.hydra>
References: <d2af01610812230654r48909999w89b32d024fc3ab73@mail.gmail.com>
	<20081223205716.GA29341@kokopelli.hydra>
Message-ID: <4951646B.8000509@gmail.com>

Chad Perrin wrote:
> On Tue, Dec 23, 2008 at 09:54:12AM -0500, Jason Wittlin-Cohen wrote:
>   
>> Huh. This is very odd. The message source in Thunderbird shows the entire
>> message but it's clearly getting truncated on the list archive. Perhaps
>> sending from GMail will work-
>>     
>
> Actually, I saw your reply text on all three, using  1.4.2.3i on FreeBSD.
>
> Perhaps you just overlooked your reply text on the first copy because it
> was lost at the end of the incredibly huge, and largely unnecessary full
> quote of the preceding email.
>   
Sorry about that. I will be more sparing in the future when I quote text.
> Maybe you're viewing HTML emails, and your mail client is hiding your
> response for some reason.he 
>   
No, I *can* see the message in Thunderbird. It's the OTR users archive
that appears to truncate the messages.
> It may be some other reason entirely, but regardless, I saw the reply
> text even if you did not.
>   
At the time I wasn't receiving messages from the mailing list. I thought
this was due to the fact that the messages were sent by me but in fact,
I simply had e-mail delivery disabled in the settings. Therefore I was
going off of the otr-users archive - not my mailbox. I was able to view
every e-mail I sent properly in Thunderbird.

For example, here's my first reply:
http://lists.cypherpunks.ca/pipermail/otr-users/2008-December/001563.html
And the second:
http://lists.cypherpunks.ca/pipermail/otr-users/2008-December/001566.html

The first cuts of all but the quoted part, and the second cuts off the
second paragraph.

> Chad 
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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: <http://lists.cypherpunks.ca/pipermail/otr-users/attachments/20081223/26363a68/attachment.html>

From perrin at apotheon.com  Tue Dec 23 18:23:53 2008
From: perrin at apotheon.com (Chad Perrin)
Date: Tue, 23 Dec 2008 16:23:53 -0700
Subject: [OTR-users] Problematic OTR behavior
In-Reply-To: <4951646B.8000509@gmail.com>
References: <d2af01610812230654r48909999w89b32d024fc3ab73@mail.gmail.com>
	<20081223205716.GA29341@kokopelli.hydra>
	<4951646B.8000509@gmail.com>
Message-ID: <20081223232353.GA10765@kokopelli.hydra>

On Tue, Dec 23, 2008 at 05:21:31PM -0500, Jason Wittlin-Cohen wrote:
> At the time I wasn't receiving messages from the mailing list. I thought
> this was due to the fact that the messages were sent by me but in fact,
> I simply had e-mail delivery disabled in the settings. Therefore I was
> going off of the otr-users archive - not my mailbox. I was able to view
> every e-mail I sent properly in Thunderbird.

Ah -- I wasn't clear on that.  I don't know if I didn't read your email
closely enough, or if you weren't entirely clear on that fact, or if it
was a combination of the two.  I'm glad you cleared it up, in any case,
and apologize for my confusion.


> 
> For example, here's my first reply:
> http://lists.cypherpunks.ca/pipermail/otr-users/2008-December/001563.html
> And the second:
> http://lists.cypherpunks.ca/pipermail/otr-users/2008-December/001566.html
> 
> The first cuts of all but the quoted part, and the second cuts off the
> second paragraph.

That's pretty weird.  I have no idea why that would be happening.  Maybe
there's some kind of spam filtering going on that's misbehaving -- but
only after the emails are sent out to the list.

-- 
Chad Perrin [ content licensed OWL: http://owl.apotheon.org ]
Quoth Henry Spencer: "Those who don't understand Unix are doomed to
reinvent it, poorly."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://lists.cypherpunks.ca/pipermail/otr-users/attachments/20081223/35f51f9a/attachment.pgp>

From bdm at fenrir.org.uk  Wed Dec 24 03:32:59 2008
From: bdm at fenrir.org.uk (Brian Morrison)
Date: Wed, 24 Dec 2008 08:32:59 +0000
Subject: [OTR-users] Problematic OTR behavior
In-Reply-To: <20081223232353.GA10765@kokopelli.hydra>
References: <d2af01610812230654r48909999w89b32d024fc3ab73@mail.gmail.com>
	<20081223205716.GA29341@kokopelli.hydra>
	<4951646B.8000509@gmail.com>
	<20081223232353.GA10765@kokopelli.hydra>
Message-ID: <20081224083259.6748b978@peterson.fenrir.org.uk>

On Tue, 23 Dec 2008 16:23:53 -0700
Chad Perrin <perrin at apotheon.com> wrote:

> I don't know if I didn't read your email closely enough,

I missed it too, probably because after I'd read the first email my
brain was busily boiling away and couldn't process any more
information.

-- 

Brian Morrison

bdm at fenrir dot org dot uk

   "Arguing with an engineer is like wrestling with a pig in the mud;
    after a while you realize you are muddy and the pig is enjoying it."
    
GnuPG key ID DE32E5C5 - http://wwwkeys.uk.pgp.net/pgpnet/wwwkeys.html


From flickrscam at rocketmail.com  Sat Dec 27 14:53:15 2008
From: flickrscam at rocketmail.com (flickr-yahoo Scam)
Date: Sat, 27 Dec 2008 11:53:15 -0800 (PST)
Subject: [OTR-users] Problematic OTR behavior
Message-ID: <920288.12738.qm@web112202.mail.gq1.yahoo.com>

Hello, 
I have exactly the same problem. I reported it a few weeks ago on the Ubuntu launchpad bugtracker [1], but seems there is no one of the developers looking at.
(Maybe a developer could even take a look over the other bugs filed there)

Actually I just wanted to second this. The actual situation is pretty bad and I would *really* like to see this fixed. I know that the first message after ending a session is not encrypted, but this is the same problem as if you begin a new session from the start.
Thanks!
(and keep good work up)

[1] https://bugs.launchpad.net/ubuntu/+source/pidgin-otr/+bug/307964




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cypherpunks.ca/pipermail/otr-users/attachments/20081227/7ffcea7a/attachment.html>